This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]