Re: About BZ#87210 [RFE] To initialize automatic stack variables

[Martin Sebor <msebor@gmail.com>]

On 3/5/19 1:36 PM, David Brown wrote:
> 
> 
> On 05/03/2019 19:37, Segher Boessenkool wrote:
>> Hi!
>>
>> On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
>>> Forcing "stolen_key" to be zero initialised does not help anyone -
>>> options for that just make code slower and hide errors that would occur
>>> with other compiler options.  The challenge is to make sure /key/ is
>>> zeroed out after use - no matter what optimisations, and whether or not
>>> the "memset" is called.
>>
>> Yup.
>>
>>> gcc already has mechanisms for handling this.
>>>
>>> First, there is a way to tell gcc that something in memory will be read,
>>> even though it doesn't look like it:
>>>
>>> void foo(void) {
>>>      char key[20];
>>>      strcpy(key, "Top secret");
>>>      usekey(key);
>>>      memset(key, 0, sizeof(key));
>>>      {
>>>          typedef struct { char x[20]; } XS;
>>>          XS *p = (XS *) key;
>>>          asm("" : "+m" (*p));
>>>      }
>>> }
>>
>> You need to use "asm volatile" here.  In principle GCC can see all the
>> outputs of the asm are dead and delete all of the asm, otherwise.  But
>> you don't need an output for *p (or inout as you wrote), just an input
>> is fine.
> 
> There are no outputs from this asm - only an input.  gcc "asm" without 
> any outputs is always treated as volatile (since otherwise the asm 
> statement would have been pointless).  But if you prefer, there is no 
> harm in writing "asm volatile" - arguably it is clearer.
> 
> <https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Extended-Asm.html#Volatile-1>
> 
> For added paranoia, you may want to include a cache flush.
> 
>>
>>> This stops information leakage where it should be stopped - once the
>>> information is no longer used.  Forcing initialisation of stack
>>> variables would put it in the wrong place, when the stack space is 
>>> reused.
>>
>> Letting one context/process/etc. handle both secret and non-secret data
>> is a recipe for disaster already.  If you do not fix that, all you can
>> hope for is some mitigation.
> 
> Certainly there are all sorts of considerations for making code secure - 
> or rather, for making the code more secure.  You can never be entirely 
> secure, all you can do is reduce the possibilities of attacks or leaks, 
> and reduce the consequences of them, until you have something that is 
> good enough for its purpose.  Carefully splitting responsibilities 
> between processes or contexts is one mechanism of many - as is ensuring 
> that secret data is properly erased.
> 
>>
>> Calling this "secure" is false advertising :-(  It is better than not
>> clearing such (stack) buffers, absolutely.
>>
> 
> I'm confident that there could be better choices of attribute name than 
> "secure".  I just can't think of any off-hand!

The SECURE project adds the function attribute stack_erase that
serves the purpose described above.  It works on stack frames by
design rather than applying to individual stack objects.
The presentation they delivered at Cauldron 2018 made it sound
like they were on track for submitting the  feature to GCC:

   https://www.youtube.com/watch?v=Lg_jJLtH7R0

Martin