[Cryptography] defending against common errors

Ray Dillinger bear at sonic.net
Tue Sep 20 22:28:40 EDT 2016



On 09/20/2016 08:18 AM, Ron Garret wrote:

>> I don't think that's allowed unless the non-volatile
>> object is 'static' in the first place, like a procedure
>> or a static variable.  IME nothing can become 'volatile'
>> unless its location can be fixed at compile time.  But
>> now I have to go read the standard again because I may
>> be remembering that incorrectly.  It would be very nice
>> if it's allowed.
> 
> But then he never followed up on that, nor did anyone else.  So AFAICT, this solution is still viable.

Short version:  Don't use gcc or icc with high optimization settings, if
you want to write anything just before deallocating it.

Long version:  Compiler is allowed to elide accesses to a non-volatile
object, even if the access is via a volatile pointer or via a pointer
with type pointer-to-volatile-object. *ALMOST* all compilers treat
volatile as qualifying both the pointer and whatever gets accessed via
such a pointer, (ie, treat 'volatile' as a qualifier of the actions done
via that pointer rather than a qualifier on the allocation alone) but
our usual problem child takes -O3 as license to make the distinction.
Even so it can only seldom actually prove that it's allowed to.

Declaring a pointer to be a pointer to volatile data should
(recommendation, not requirement) produce a compile-time warning at any
assignment statement that points it at known non-volatile data, but I've
never seen that warning.

Accesses via a volatile pointer are guaranteed/required to read the
pointer from main memory, but in the event that the data pointed at was
not allocated volatile, are not required to follow it and read or write
to any non-volatile data it points at.  Accesses via a
pointer-to-volatile are not required to go to memory for the pointer
value itself, but are required to write the object if their (possibly
cached) value for the pointer is the address of something allocated
volatile.

If an object is about to be deallocated, the compiler can move the
(required) free-ing access of a volatile pointer above the write code,
and then skip the write code if the pointer on access contains the
address of a non-volatile object.

Until memset_s is widely and usefully implemented, I'm back to hacks -
XOR the buffer with /dev/urand output then write it to /dev/random
before releasing, on the grounds that I/O operations which change the
state of the pool can't be elided.

				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160920/321e74cb/attachment.sig>


More information about the cryptography mailing list