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

[David Brown <david dot brown at hesbynett dot no>]

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!

> Segher