From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=ZZ5x=36=gmail.com=jwakely.gcc@sourceware.org>
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534])
	by sourceware.org (Postfix) with ESMTPS id 7C33A3853D50
	for <gcc-help@gcc.gnu.org>; Wed, 30 Nov 2022 17:41:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7C33A3853D50
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-ed1-x534.google.com with SMTP id v8so25105834edi.3
        for <gcc-help@gcc.gnu.org>; Wed, 30 Nov 2022 09:41:52 -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=ELvQHyiikWCeTAoeKG1J1dYFOC/nfIoP5DIId77ie4E=;
        b=S748AtlbU9N2G7I8KBbwoeVvgcdb9brcQCLWbTr/42dsHOXAEvzxYQmPP+DEOtxrJT
         VU4SgrQSrHxW3nacew3HzSxIb1vcKNKYe6ldPHmGBQG8OUi2bDi04cXWaa6fFNQUdCl7
         qAVcnyLWcoO8DMEHupbELxl68MM/Q0NRy4d9+tppSsupmkK0EixDLm1SXhm+AzevnF73
         w0Ivm5G4KihZByXSlkTGMY9D1PF7b9aPSwvyog84heV+oHAci74u+XBLo/nn3MBQbHvt
         Bx7TD5iii7ol5REywsa3L9kcilR0Z9XQBA6cxVmvXe7CdW1u4rtO+1gu0WgDHAfND2NF
         ig7A==
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=ELvQHyiikWCeTAoeKG1J1dYFOC/nfIoP5DIId77ie4E=;
        b=zGb8OVnNOWNsRb312Tz/9tllUbp96W9UuQyAcgb/2aeYt7c8D0axLS1ydwFRDNwD5V
         wzz+jIVglb333y4TH8NaC6WIHHKvbtP71OvBVFZAj4d/MFgnd8nxBkAV69P3pqHkA+uw
         qNVBwKVbF7tbKrp/8YZiuvMMSzvDOJQOE2dKEW9kqSUr6Xw4BZVz9j71sniSkhQtA0lh
         mD27yQA2pMIKrQUuy6PA7MuhTZMOUQVmGTM76RwaCH858hWOAY1PkAZdMwHJGYumK0xH
         wYW+ioXUHCnUUF4WBEeUgueYQPoWKcGNQrbb32rwtCGC2Ns1k16O+WXtnBgeMO3xNhwx
         GI/g==
X-Gm-Message-State: ANoB5plxLFjbGfqPpHfE+5yd7d8Fmlm2S/skcmwkFihd2oEQJH+DUuqe
	LksUbwGInQxU1mJ3MsPi+xptmngUEVKtIFRl6kw=
X-Google-Smtp-Source: AA0mqf4O52rB7sa8xl3V1hAYHCVDfdROMuXoH5A+KtvJv89jYG2JEF/t9TvpUlG5ompmKajxwzzbQpDqYvS6xMvX5KA=
X-Received: by 2002:aa7:dbc7:0:b0:45f:b80f:1fe8 with SMTP id
 v7-20020aa7dbc7000000b0045fb80f1fe8mr54455703edt.118.1669830111123; Wed, 30
 Nov 2022 09:41:51 -0800 (PST)
MIME-Version: 1.0
References: <4366aeb5-7fdb-6fa4-b0f5-ebe74c1d4fb2@jguk.org> <CAH6eHdRLzrZO04axQ3ozEi=6y18p2L1ZMstq2TmKXLpCzycumw@mail.gmail.com>
In-Reply-To: <CAH6eHdRLzrZO04axQ3ozEi=6y18p2L1ZMstq2TmKXLpCzycumw@mail.gmail.com>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Wed, 30 Nov 2022 17:41:40 +0000
Message-ID: <CAH6eHdS62r_o8xrJHDgsQg_Mtx0kQRECGyL3UL=LHtx9iAgzYQ@mail.gmail.com>
Subject: Re: Avoiding stack buffer clear being optimised out
To: Jonny Grant <jg@jguk.org>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
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,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: <gcc-help.gcc.gnu.org>

On Wed, 30 Nov 2022 at 17:40, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 30 Nov 2022 at 16:27, Jonny Grant <jg@jguk.org> 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)

Oops, I meant to change that to return void, because you don't need to
jump through hoops checking its return value to ensure the side
effects aren't optimized out.

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