From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 9CA21384F4B4 for ; Tue, 13 Dec 2022 23:16:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CA21384F4B4 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-x32f.google.com with SMTP id m19so9853109wms.5 for ; Tue, 13 Dec 2022 15:16:52 -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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wlgcvL+xlnoH1vowP4wXUHF0daYLvP5CdkNlPp77ECU=; b=esnYpOAV3bIoHsBZNJxe54LoHb7Fn5T2anXD/aNEVyaMyPCMgzpfy0mapoa7g253CW iYhbTN4GnVO/Gv4ho3/vVVhk7uF2Mpm5zbUyD18yZpD8mptamEsMQpNvSgD0ulPjCikj VDwdCPxd0nveniZ5rKQLBA17pDLQs0EHMbec5wV7dDXtli2s8Bs7O73EkmTJUEj6gp0V i3tNt/wGnNXGY3OBF+ejN5lNiYE0cdJhQEXIKz5PINzM56NfrwH1juSTj8EVuN6AWJML +QTSKV6LX9rANbkX/Q/7U9sI9wPNRngEkL1negKYEa5ySrj45eUSxtBSXhyiLkiazGlu 4DLA== 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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wlgcvL+xlnoH1vowP4wXUHF0daYLvP5CdkNlPp77ECU=; b=j2icD4jydC/4MCiXwWaZvQY6crsc5KKOUmPS24FtNhhHZI/wpNn6it8HKDT/bBftLK MTpcGkN8W348RU8Rdrp6eORlduU9r6M1lg0XZ9P5OKN0KYjqUKjIKPlsdtlnjNh6QljY 64PN/qtXzLlo0cQz92gjRxZZA004W+sw0tVKITTP6x8na20GfXXSmWovXtoGHGpiotzJ gWjIcLLdqRe2n0l0urQXK3lEHPUThLFR0ZHVEEfZfxNgT0Rm1BLNHffQ5VxiOkAvR3vx GU/xduMN264kEmx4cmgYDzNSJ09gXF1/igQ45mNWALhqn4qBwv362fhJSIf7dzzpRFXk 8Ejg== X-Gm-Message-State: ANoB5plCuQlWUQ2NThuMXtsXr3KsehONxnZly1/MjvGfBeFVCAYMCpmD 50STECwGQbHjgM2ejjqyeb+ncQ== X-Google-Smtp-Source: AA0mqf5uxcn0N42cLCqpnUZHO8HSLZjp75imab/v/yKB1Q1gDPsFwtiXujsg6SwPZ4dof2ys5pHXtQ== X-Received: by 2002:a05:600c:3b16:b0:3d2:267d:64da with SMTP id m22-20020a05600c3b1600b003d2267d64damr7427881wms.10.1670973410718; Tue, 13 Dec 2022 15:16:50 -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 q20-20020a056000137400b0024287d9d4a8sm984271wrz.74.2022.12.13.15.16.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Dec 2022 15:16:50 -0800 (PST) Message-ID: <0f01af4d-3485-1a0d-eea0-617ce6340c32@jguk.org> Date: Tue, 13 Dec 2022 23:16:49 +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 Content-Language: en-GB To: Jonathan Wakely Cc: gcc-help References: <4366aeb5-7fdb-6fa4-b0f5-ebe74c1d4fb2@jguk.org> <68c69b5a-e6e7-7021-5f98-37ba8f3c49eb@jguk.org> From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 23:13, Jonathan Wakely wrote: > On Tue, 13 Dec 2022 at 22:07, Jonny Grant wrote: >> >> >> >> 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? > > It doesn't need to know anything about the internals, only the > observable behaviour, which is entirely defined by the C standard ok thank you for clarifying. Jonny