From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 49E9E3853784 for ; Tue, 13 Dec 2022 22:07:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 49E9E3853784 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wm1-x32b.google.com with SMTP id r127-20020a1c4485000000b003d1e906ca23so1650141wma.3 for ; Tue, 13 Dec 2022 14:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=2GOkrqUm+skayZQRkEc8iYVSdm0vauKteLt1zvmaz9Q=; b=jWycZvsUWkPoFf63slHbbYDPcAo+qFhjEZ0QCfBnQXN0mCuo5h58NrEC01Mmj/I/XI uFPZmOEaYMqA6JVbJupWHTJ5331rI7kQb4WHN8aeskfmdXw2Ndyagci0dYB0J3318wYu jQdnLHuM8Cj+X6IpjvewEWQyE7sftRHEQojZ1jznf/HcS3uSDAmXQKeF8kufNJuD7qJP 8voJv4CgMJfwb2w+3o8xIkbOxN0vCSq6QrMWIZk5z96D5LrnEP6wflswHwt/xTuKhogF WeA9HIsQmmf2YucPhRmSaQvIPyXK31SkHPy3kQ++KSDi3660KL7y0Y+vlRGy3d5WlQWu vODQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2GOkrqUm+skayZQRkEc8iYVSdm0vauKteLt1zvmaz9Q=; b=tHSmkivPjhrPZk2tOHSgw+9/mXp5wLGJDjomx8kC66C4pQfcd9XXZ0OtlsKPhLsALg XiOH7+2DJy3sElQVXd1hoNt67/g4M15rOR4acrvIeLMJmWBjoETEAywEq1EXPxXI5Zy2 A9RtPaZVQELjf0LVCn7OYV3EjAYImNFycDYGJU9t8fF8zlucWYg4SLIERhMbkGJRpWbM tuwMdmzN7ID2edt2xW5Ha4Wt80ZzMwGZcYw9BCAeIPC+D8fZz6ZBajK/XQTOvoZzB3SP JGgNBiDIh19x7kSd826b5U2FJ5cSn3xxJDxsB+kp6IsdofjRmo/qxqYDFZXq4Z2LYph1 7Akw== X-Gm-Message-State: ANoB5plwy5m3Em2O1bUAr7JsZQrY6+qyPqavZDz4lJkJxw16vDLBsTDS FRGX9p3pcFO4l82qTKMs0r/1EQ== X-Google-Smtp-Source: AA0mqf4WqLZWNEBdY8v2izxUsbzf4Gt/hhxI2jxnndIW03DCNGTw+84gvNo7Drzmt8dUcoftQDfFaA== X-Received: by 2002:a05:600c:795:b0:3d1:cee0:46d0 with SMTP id z21-20020a05600c079500b003d1cee046d0mr16907947wmo.25.1670969241973; Tue, 13 Dec 2022 14:07:21 -0800 (PST) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id l6-20020a05600c4f0600b003a3442f1229sm80777wmq.29.2022.12.13.14.07.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Dec 2022 14:07:21 -0800 (PST) Message-ID: Date: Tue, 13 Dec 2022 22:07:20 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: Avoiding stack buffer clear being optimised out To: Jonathan Wakely Cc: gcc-help References: <4366aeb5-7fdb-6fa4-b0f5-ebe74c1d4fb2@jguk.org> <68c69b5a-e6e7-7021-5f98-37ba8f3c49eb@jguk.org> Content-Language: en-GB From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: On 13/12/2022 20:31, Jonathan Wakely wrote: > > > 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; ok, that is what I thought, it seems to know how the internals of memset() work. Maybe because it's a builtin? > > 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. That makes sense. So if I wrote a assembler implementation I called memset_asm() I imagine gcc wouldn't be able to understand that it set those bytes to zero? so it wouldn't remove my memset_asm() call. Regards, Jonny