From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 7FF5B3858D32 for ; Thu, 1 Dec 2022 11:56:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FF5B3858D32 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-x429.google.com with SMTP id y16so2336738wrm.2 for ; Thu, 01 Dec 2022 03:56:00 -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=c3FuhyPG3EYbOUPzz7mcpGQ5l2RMmaQE7BOY8tAEEm8=; b=XzDcq49u6AjXpNhu2P0uZRUYpCzLeaTjlXygHCT1u4LjZFaGz8TAsfnV70excq1n1P JemH2REEJajidpAHc/S+KOgurq2N+0u+AoXsvm5EkLUeehxnKyZaX1vfrhuRIkERxctm rqMK2A3XOtj8aEK3zFSGx+zdqCIZRTIN35HZEptgj63WWIfqAWQ9dS3r3YxSDWi3Bmdl pU8QSFPYFR3vdY4HLCWO1mB+w0orI4fEfNsVdsrzPOxlPWk8QMyHYTc4eH6H+5OPGp1i I9/4GiIgDJrMIc6bJQHyAsMXm+fBTk9HOUkO8SHmh5RF5dDyklYEB9J3RYb/9HNAFcJz +t3g== 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=c3FuhyPG3EYbOUPzz7mcpGQ5l2RMmaQE7BOY8tAEEm8=; b=k34fz9GiZNJGdzgSPe50LkR0kiHGDT2KAYG3B5uDGc/VsnD4u3WkAkJbGgbOTYJqyq irPGnAj+yFV1xkpC8OVqVvbhucmEx6JC+U6aOEXiE+2Ou3l/hKvsw5lB/AOPm/jLGKYM iuAPrs+adWxZswjtD9cv08Gd446YgwkeZAtFwpm82jRfOcZNSrRDms5yl7biaBVK87Xl lXU78CNpptSbg3aI75FENGDoKWdV+28FU3L15hY5KTUopF77fL92AaWpdAf4zHqTQC3Q /kDosNOCZNvNKrA8+vpMDvucRXdy8zH2vFP4bcq0DXDhJC8jDg0Xd0woWACrbY/RsoU0 Ih+g== X-Gm-Message-State: ANoB5pmDiyjExfKgnRVuQNGlzJZkgRkRV4eQex1BYCW1KcYO5ZxYcX6G aXecwBtzUqUPbF0D9rpfs3YYpQ== X-Google-Smtp-Source: AA0mqf7HnUF9QvvU/5GpY/opU+79p2CrplXyhqiJ7tPQUyNuG9qNq3+0yPyuc0SQ/zJuEIXVCiHwNg== X-Received: by 2002:a5d:6206:0:b0:241:e3b8:e1a5 with SMTP id y6-20020a5d6206000000b00241e3b8e1a5mr28792853wru.651.1669895759270; Thu, 01 Dec 2022 03:55:59 -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 p14-20020adf9d8e000000b00236b2804d79sm4285897wre.2.2022.12.01.03.55.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Dec 2022 03:55:58 -0800 (PST) Message-ID: Date: Thu, 1 Dec 2022 11:55:58 +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> <178e21a7-8e34-7240-5d53-c2783451b9a9@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.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 01/12/2022 11:31, Jonathan Wakely wrote: > On Thu, 1 Dec 2022 at 10:44, Jonny Grant wrote: >> 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 already used the noinline attribute in my example above. > >> 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. > > No. > > But C2x adds a memset_explicit function that does what you want, so > that should arrive in glibc soonish. > I thought it had been added, but was searching the C2x draft for > "memset_secure" and other incorrect names. > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2631.htm was the > proposal adding it. Well, at least it is in the standard. Although now we have yet another function name doing similar. Might have been simpler to add explicit_bzero to the standard. I can see this has been discussed for two decades https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8537 So it will be like this: void *memset_explicit(void *s, int c, size_t n); I imagine it won't check the pointer is non-NULL. memset_s did do that. Seems pointless to return the pointer. Hopefully no one will use these other variations people have implemented with different parameter types. https://github.com/gsbabil/memset_explicit/blob/master/memset_explicit.h >> >> 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). > > They're not good APIs. See > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm and > https://sourceware.org/legacy-ml/libc-help/2018-01/msg00007.html Yes, I know there is a lot of disapproval of Annex K. although I don't feel those trivial memset_s style are. I liked them as they check for non-NULL and return a handy error code. Regards, Jonny