This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: About BZ#87210 [RFE] To initialize automatic stack variables
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: David Brown <david dot brown at hesbynett dot no>
- Cc: P J P <pj dot pandit at yahoo dot co dot in>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 5 Mar 2019 12:37:20 -0600
- Subject: Re: About BZ#87210 [RFE] To initialize automatic stack variables
- References: <1225413012.1679387.1550571810991.ref@mail.yahoo.com> <1225413012.1679387.1550571810991@mail.yahoo.com> <e5e5f5b4-9e33-8833-c45d-11b117dc8e2f@hesbynett.no>
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