From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 8D3AC1F5AE for ; Sun, 18 Jul 2021 19:15:16 +0000 (UTC) Received: from localhost ([::1]:41086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5CFv-00068g-Cf for normalperson@yhbt.net; Sun, 18 Jul 2021 15:15:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55158) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5CFr-00068X-5c for bug-gnulib@gnu.org; Sun, 18 Jul 2021 15:15:11 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48834) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5CFo-0007f8-GD for bug-gnulib@gnu.org; Sun, 18 Jul 2021 15:15:10 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 590FE160057; Sun, 18 Jul 2021 12:15:06 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kR-AX3HtAsSl; Sun, 18 Jul 2021 12:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 44CA416005A; Sun, 18 Jul 2021 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iOapXZTijp2j; Sun, 18 Jul 2021 12:15:03 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E1A44160057; Sun, 18 Jul 2021 12:15:02 -0700 (PDT) Subject: Re: [PATCH 1/2] explicit_bzero-tests: pacify GCC To: Bruno Haible References: <20210718045621.1058412-1-eggert@cs.ucla.edu> <1970409.cXUO0us07v@omega> From: Paul Eggert Message-ID: <3ecc5494-65ab-cb9e-19c7-8aaef7b6ff18@cs.ucla.edu> Date: Sun, 18 Jul 2021 14:14:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1970409.cXUO0us07v@omega> Content-Type: multipart/mixed; boundary="------------15D2488E848B70177F843589" Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.07, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" This is a multi-part message in MIME format. --------------15D2488E848B70177F843589 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/18/21 4:12 AM, Bruno Haible wrote: > The purpose of the test is to verify that the compiler does not eliminate > a call to explicit_bzero, even if data flow analysis reveals that the stack > area is "dead" at the end of the function. > > With this patch, it was turned into a weaker assertion: namely, that the > compiler does not eliminate a call to explicit_bzero if it cannot make > inferences about the pointer argument. Strictly speaking, neither assertion is weaker than the other. However, I take your point that the patch changes the meaning of the test in an undesirable way. I installed the attached to implement your suggestion. This new diagnostic points out a problem with the test, though. If GCC can determine that memcmp reads uninitialized storage, GCC can optimize away the memcmp and act as if memcmp returns 0 (or any other constant). So the test as it stands is problematic given recent advances in practical compilers. As an aside, I don't understand the discussion of asynchronous signal invocations in that test's commentary. There is no asynchronous signaling in that code. (These points are of course low-priority, as explicit_bzero is documented to be best-effort as opposed to being a guarantee that the information is erased.) --------------15D2488E848B70177F843589 Content-Type: text/x-patch; charset=UTF-8; name="0001-explicit_bzero-tests-pacify-GCC-better.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-explicit_bzero-tests-pacify-GCC-better.patch" >From f9803478355d038aa060d71bdd9eddf2bd43325f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 18 Jul 2021 14:08:56 -0500 Subject: [PATCH] explicit_bzero-tests: pacify GCC better Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2021-07/msg00039.html * tests/test-explicit_bzero.c: Ignore -Wmaybe-uninitialized. (stackbuf): Remove this static pointer, reverting recent change. (do_secret_stuff, test_stack): Revert these related changes too. --- ChangeLog | 9 +++++++++ tests/test-explicit_bzero.c | 16 +++++++++++----- 2 files changed, 20 insertions(+), 5 deletions(-) diff --git a/ChangeLog b/ChangeLog index c50808437..d175c39af 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2021-07-18 Paul Eggert + + explicit_bzero-tests: pacify GCC better + Problem reported by Bruno Haible in: + https://lists.gnu.org/r/bug-gnulib/2021-07/msg00039.html + * tests/test-explicit_bzero.c: Ignore -Wmaybe-uninitialized. + (stackbuf): Remove this static pointer, reverting recent change. + (do_secret_stuff, test_stack): Revert these related changes too. + 2021-07-17 Paul Eggert memrchr-tests: pacify GCC diff --git a/tests/test-explicit_bzero.c b/tests/test-explicit_bzero.c index c42aba93f..14f0ead2b 100644 --- a/tests/test-explicit_bzero.c +++ b/tests/test-explicit_bzero.c @@ -32,6 +32,12 @@ SIGNATURE_CHECK (explicit_bzero, void, (void *, size_t)); #include "vma-iter.h" #include "macros.h" +/* Suppress GCC warning that do_secret_stuff (2) reads uninitialized + local storage. */ +#if 4 < __GNUC__ + (3 <= __GNUC_MINOR__) +# pragma GCC diagnostic ignored "-Wmaybe-uninitialized" +#endif + #define SECRET "xyzzy1729" #define SECRET_SIZE 9 @@ -126,12 +132,14 @@ test_heap (void) /* There are two passes: 1. Put a secret in memory and invoke explicit_bzero on it. 2. Verify that the memory has been erased. - Access the memory via a volatile pointer, so the compiler - does not assume the pointer's value and optimize away accesses. */ -static char *volatile stackbuf; + Implement them in the same function, so that they access the same memory + range on the stack. That way, the test verifies that the compiler + does not eliminate a call to explicit_bzero, even if data flow analysis + reveals that the stack area is dead at the end of the function. */ static int _GL_ATTRIBUTE_NOINLINE do_secret_stuff (volatile int pass) { + char stackbuf[SECRET_SIZE]; if (pass == 1) { memcpy (stackbuf, SECRET, SECRET_SIZE); @@ -147,8 +155,6 @@ do_secret_stuff (volatile int pass) static void test_stack (void) { - char stack_buffer[SECRET_SIZE]; - stackbuf = stack_buffer; int count = 0; int repeat; -- 2.25.1 --------------15D2488E848B70177F843589--