From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id D4CF53839611 for ; Tue, 13 Dec 2022 20:31:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D4CF53839611 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x636.google.com with SMTP id gh17so39578527ejb.6 for ; Tue, 13 Dec 2022 12:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=P28NTZp9fjpA2sCu6aKUqRoUywvWIrsY3KdlES4HjuA=; b=iLkAZc4R/2eqVOJ78OuYF/e0k2JIKWBeWOofeQwa1duj8Kep7o0P0clMF6ftqe/26/ c3VAgdUvi2bVF0JH+e+ZTCUBMTK725grAtFUh2QMUODP4fe2yo/qEbv7tbIt1TxcdjHU tCvGbwxqJZ+2rKP3H9dFQriPZWYInUDL/Rob5rY/dWKOx/5BMwHkcG2lwq7Io4dBiMHW FVY6kOay2KqXsqEUDhyb2boR0bw7SQoiFh47XKjdROHw8Cc1tDdUneWOdUeDnciRz5J5 3jgoae/fwt+9FdeWm/Iwo/dZfpzmA9+1MfFgt+6rQLYW6eKJX04i6u0muZQOIpsBmVJi zr/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=P28NTZp9fjpA2sCu6aKUqRoUywvWIrsY3KdlES4HjuA=; b=DbgHmqi5iHOjeZ9CvYug0+iuS/zud4tDa800FpjWGuoLTevXEqlVBKO04qU41f1/QC Y7+Cq+lT4yP+yX4qN5SP49EsqXI1VQrajSK0FbuJSv6zs9v/8KK/ANR7i/m6oAK0BTtq IbRFIwLRUhrUpZjPjt7fonv6GYdhY57dreBIiyAG7Wy7goM8y8cpnrf3kPp6bY3ZPoKl NrydjETSb0GFp+nOc5ULIGwHk8D+gQv6fqB4Ckbzt509ha+a1wDsAhdYE0VUM2kggr+o VCj4SpYL8MFzFHb2uGpL325YtYBstOyBFe0NsucNAMuVbiECWJ3S2wKJZdEzEzBKzSCR sDGQ== X-Gm-Message-State: ANoB5pmJSpy7cq//vfnYUJbANRsxeVOMS/ObDrprmiN03GJi1BisBY5F 0bwo2ZsANZdtyvTCeGoLP1popmqDEJFJdI30iXA= X-Google-Smtp-Source: AA0mqf7pgyKH3Mr0NCwprVl2YJgaXK21/KJ3RUFER7K+H3nKcAKQJJAxGsfJJNkDrmqCzykAqg/ztH/9OKf5DR2BoNU= X-Received: by 2002:a17:907:77ce:b0:7c0:8225:54d with SMTP id kz14-20020a17090777ce00b007c08225054dmr36670068ejc.286.1670963472503; Tue, 13 Dec 2022 12:31:12 -0800 (PST) MIME-Version: 1.0 References: <4366aeb5-7fdb-6fa4-b0f5-ebe74c1d4fb2@jguk.org> <68c69b5a-e6e7-7021-5f98-37ba8f3c49eb@jguk.org> In-Reply-To: <68c69b5a-e6e7-7021-5f98-37ba8f3c49eb@jguk.org> From: Jonathan Wakely Date: Tue, 13 Dec 2022 20:31:01 +0000 Message-ID: Subject: Re: Avoiding stack buffer clear being optimised out To: Jonny Grant Cc: gcc-help Content-Type: multipart/alternative; boundary="0000000000003619c405efbb80bb" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000003619c405efbb80bb Content-Type: text/plain; charset="UTF-8" On Tue, 13 Dec 2022, 20:12 Jonny Grant, wrote: > > > On 30/11/2022 17:40, Jonathan Wakely wrote: > > On Wed, 30 Nov 2022 at 16:27, Jonny Grant wrote: > >> > >> Hello > >> > >> Does GCC have a clear way to avoid memset being compiled out by > optimiser? > >> > >> This article came up, so I combined the broken.c with GCC > >> gcc -Wall -O2 -o broken broken.c > >> > >> Note, I've been using gcc for many years, I'm not looking for just tips > how to compile code. I only want to discuss this optimiser issue :-) > >> > >> > https://blog.cloudflare.com/the-linux-kernel-key-retention-service-and-why-you-should-use-it-in-your-next-application/ > >> > >> If I modify to clear the buffer, it gets removed by the compiler > >> > >> The only way I could get it to not remove the memset is by adding > another printf, (propagating a return code after checking memset wasn't > enough) > > > > This is simpler and works for me, but I'm not sure if it's guaranteed > > to always work: > > > > __attribute__((noinline,noipa)) > > void wipe(void* p, size_t n) > > { > > memset(p, 0, n); > > } > > > > static int encrypt(void) > > { > > uint8_t key[] = "hunter2"; > > printf("encrypting with super secret key: %s\n", key); > > wipe(key, 8); > > } > > > > There is discussion of alternatives in > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1358.pdf (starting > > on page 6). > > > > The memset_s function was added to C in Annex K, but most > > implementations of the C library do not support Annex K. > > > Jonathan > > I wonder if you know how GCC decides to remove the memset? In the > following example, the memset even changes the bytes on the stack, which > are then not changed later on in the program, rather strange. > No it doesn't. The observable behaviour of the function is to write zero to several bytes, then check if one of them was zero. The compiler doesn't need to write anything or read anything to produce that behaviour, the read can never *not* read a zero there, so the compiler doesn't bother to write anything *or* read anything. It optimizes the whole function to simply: puts("encrypting with super secret key: hunter2"); return 0; If I modify the code to check the buffer contains key[0] as nul byte, it > still shows as 0, You asked whether something just set to zero is equal to zero. That's redundant, of course it is. There is no need to waste CPU cycles on that. but then the stack is still readable > > // gcc -Wall -O2 -o broken broken.c > > #include > #include > #include > > static int encrypt(void) > { > uint8_t key[] = "hunter2"; > printf("encrypting with super secret key: %s\n", key); > memset(key, 0, 8); > if(key[0] == '\0') return 0; > else return 1; > } > > static void log_completion(void) > { > /* oh no, we forgot to init the msg */ > char msg[8]; > printf("not important, just fyi: %s\n", msg); > } > > int main(void) > { > int ret = encrypt(); > /* notify that we're done */ > log_completion(); > printf("ret: %d\n", ret); > return ret; > } > > > --0000000000003619c405efbb80bb--