From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 7D06B3858D32 for ; Thu, 1 Dec 2022 10:44:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D06B3858D32 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-wr1-x431.google.com with SMTP id y16so2038692wrm.2 for ; Thu, 01 Dec 2022 02:44:45 -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=7rJbgGF6YWy+8BVNSeTrF8qkTb3K0Eumcq48cs2Yuac=; b=QvvOS86LmF1C0IfPwWVxc5bG7bgQEnygisDWx45cKwUw8QlvlaSRfsXy6OKXRckqP/ WuhoVO/rZcYMUbZoZLSPkvtzewFfsUF1+m4S26zi5RoLkm/s/1ir0TPV7DaucuMfP4xD +6oDV6v2iSFWnXic4lNUrIYKs8CYWsPVNkAjxeB8MB9FoFsm0KoZQbCF8y9xjASQNGv9 IyaPtNyuQCuQxGPWapoSmeQ/DNzH9ia4I5Y8JBaHQK5VVuC2l2lG/Ljcisk9+MMNCxSd mnbbyPDHw/7vspThN8z/Y6wOTAlY3WTzaVWeKYdaqD34HJsJRf7SCgMcqdeMmkQ0i7E3 EKAQ== 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=7rJbgGF6YWy+8BVNSeTrF8qkTb3K0Eumcq48cs2Yuac=; b=sxV34rJhjJppLVYUnYJ8s4bmjtrlxArx9p6UoSN2FAHlFFHltQ52QwZUnCJdZManc2 kQsH9kkw+lL3iwgkEdxMWbhmUOIZKRxr+vzUteoSN38RnJ6PJiGI7Ai46J5fNxZXqb9t oCCy/HcQEK0Yo2K6PQnMb9J0+BAwaJeGj0qKMY93yx9hE1/ghN8gLHr1vZQSwfe8rMdu Fxn664QqW32bYf3CpRNF2+QawYkWg4VEtaNLgdyrrGePbF8zXJpl+nc/E66x4ZtJifFb 5GCADK4+sZB7s7FbjsgTTZZB6Ns+cbsl0watskmt3i5IJWOYMf+SlLL0E6QHe1Pzmdn1 fD8w== X-Gm-Message-State: ANoB5pklctPG2MfI31rKN/4yf9mZdemJ5Gwe6PXKPJNLNeDHXubhhto3 mxz262wLwII6yU3AssIhtR7uuA== X-Google-Smtp-Source: AA0mqf7zWKH1zsdkECTYJp3ujnl4bERYucj24MPFfo3zZEWyGW0bC7TZYG+/9RXerd59rJTIiqtKSA== X-Received: by 2002:a05:6000:16c6:b0:236:6e66:3447 with SMTP id h6-20020a05600016c600b002366e663447mr40410117wrf.24.1669891484198; Thu, 01 Dec 2022 02:44:44 -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 l7-20020a5d4107000000b00242246c2f7csm4165835wrp.101.2022.12.01.02.44.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Dec 2022 02:44:43 -0800 (PST) Message-ID: <178e21a7-8e34-7240-5d53-c2783451b9a9@jguk.org> Date: Thu, 1 Dec 2022 10:44:43 +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> Content-Language: en-GB From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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 30/11/2022 17:41, Jonathan Wakely wrote: > On Wed, 30 Nov 2022 at 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) > > 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. Thank you Jonathan and David for your replies. That "noipa" looks to have sorted this issue https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html That page also suggests "noinline" attribute which seems to suggest I'd need to add asm (""); in each wrapper of memset() I'd much rather have memset_s - Jonathan, do you think GCC could add some built-in functions for memset_s ? __builtin_memset_s() would be great. There are quite a few similar ones that should be easy to add based on existing (memcpy_s, memmove_s, strcpy_s, strncpy_s, strcat_s, strncat_s, strtok_s, memset_s, strerror_s, strerrorlen_s, strnlen_s). I did speak to someone at LLVM who was considering adding built-ins to clang. Kind regards Jonny