From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35469 invoked by alias); 5 Mar 2019 20:37:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 35457 invoked by uid 89); 5 Mar 2019 20:37:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=BAYES_00,KAM_SHORT,LIKELY_SPAM_BODY,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=advertising, flush, consequences, considerations X-HELO: asav21.altibox.net Received: from asav21.altibox.net (HELO asav21.altibox.net) (109.247.116.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Mar 2019 20:37:02 +0000 Received: from mail.jansenbrown.no (unknown [51.174.108.167]) by asav21.altibox.net (Postfix) with ESMTP id B40E8801F9; Tue, 5 Mar 2019 21:36:57 +0100 (CET) Received: from [192.168.4.243] (unicorn.lan [192.168.4.243]) by mail.jansenbrown.no (Postfix) with ESMTPSA id DEB6D19913E; Tue, 5 Mar 2019 21:36:56 +0100 (CET) Subject: Re: About BZ#87210 [RFE] To initialize automatic stack variables To: Segher Boessenkool Cc: P J P , "gcc@gcc.gnu.org" References: <1225413012.1679387.1550571810991.ref@mail.yahoo.com> <1225413012.1679387.1550571810991@mail.yahoo.com> <20190305183717.GQ3969@gate.crashing.org> From: David Brown Message-ID: <812a9782-8eee-90c5-ed0e-b9bd2135b602@hesbynett.no> Date: Tue, 05 Mar 2019 20:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190305183717.GQ3969@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=eagTgYMH c=1 sm=1 tr=0 a=U0L3DYRvxOwaPRbtiaGbog==:117 a=U0L3DYRvxOwaPRbtiaGbog==:17 a=IkcTkHD0fZMA:10 a=NTGMnVQrEZIA:10 a=mDV3o1hIAAAA:8 a=vYdmSbPX9TN-cwnloggA:9 a=QEXdDO2ut3YA:10 a=yUohW7vLiJkA:10 a=_FVE-zBwftR9WsbkzFJk:22 X-SW-Source: 2019-03/txt/msg00035.txt.bz2 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. 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 >