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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,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 6E3BA1F4C1 for ; Mon, 28 Nov 2022 16:04:46 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.b="JL6UMVdq"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozgcL-0005J3-05; Mon, 28 Nov 2022 11:04:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozgcE-0005IQ-8k for bug-gnulib@gnu.org; Mon, 28 Nov 2022 11:04:23 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozgcB-000755-Ud for bug-gnulib@gnu.org; Mon, 28 Nov 2022 11:04:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1669651452; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=3uX63LqO1LbqzNgWDpxfjjRxUqUDZ/Y55f6h31ttNKs=; b=JL6UMVdqf/HspOPdl+iIySBDlAfRW3wxPZy+6pSTSd7NZNvj/B6rIMFrYlWoDYgthc PnWDEIIvALbONQ2QvOMUxV2cWBZKCEV9L8z8Z8bEGlJRifM6IWQLF96lOBFm81PckavS ef4fuZKpJ92Yrnq2I1jrzH7tvhckpKiJi5u9fnd0gKOIz4OOZJkmWX4U3T8QlsqCe2zH v+rH8eBkvLsUZfrlLjKME3LGmzqzJxNipUO3RwIgvKM2A4AFL3Gszk4Ezgqi6Sm1tiNY /jLV9IzqUsx2Gjob4yAs7w3ciDkRFC59QsRmpIYnRq4bJH+7fxtzTJT9lXsMNbnIeslE cE/w== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPAj/KLK0wyfsdMn5+9afOheWekxQ==" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6yASG4B2WT (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 28 Nov 2022 17:04:11 +0100 (CET) From: Bruno Haible To: Simon Josefsson Cc: Paul Eggert , bug-gnulib@gnu.org Subject: Re: [PROPOSED 0/4] memset_explicit patches Date: Mon, 28 Nov 2022 17:04:11 +0100 Message-ID: <12846274.EVyyLHbfrO@nimes> In-Reply-To: <87edtn2xn8.fsf@latte> References: <20221128045543.1355731-1-eggert@cs.ucla.edu> <87edtn2xn8.fsf@latte> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.22; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Simon Josefsson wrote: > A general observation is that I'm mixed about offering replacement of > security-relevant APIs which do not offer the same guarantees as a > secure implementation. In these situations, it may actually be > preferrably to crash or to refuse to build the application, at least by > default. I disagree. IMO, security is always done on a best-effort basis. There is no 100% security. In the case of memset_explicit, the secret may be present in memory - with a working memset_explicit: for 5 microseconds, - with a dysfunctional memset_explicit: for 5 seconds. So, a working memset_explicit provides a 99.9999% protection, at most. Even with a working memset_explicit, the attacker can halt the CPU at a particular instruction before the erase (e.g. set a breakpoint at memset_explicit :-) ), make a dump of the RAM of the process, and analyze it. Therefore I don't think that an FTBFS or an abort() are justified if the security guarantees cannot be met. Bruno