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

[Segher Boessenkool <segher@kernel.crashing.org>]

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.

> 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.

Calling this "secure" is false advertising :-(  It is better than not
clearing such (stack) buffers, absolutely.


Segher