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 159821F910 for ; Sun, 27 Nov 2022 17:49:07 +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="YmQmpJ3s"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozLm0-0006mT-N2; Sun, 27 Nov 2022 12:49:00 -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 1ozLlx-0006mB-GK for bug-gnulib@gnu.org; Sun, 27 Nov 2022 12:48:57 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozLlu-0004Pi-U4 for bug-gnulib@gnu.org; Sun, 27 Nov 2022 12:48:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1669571315; 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=eHk+30Zx3aZRB5Ru991122gA/mqqG0j+asBHEfJeQiM=; b=YmQmpJ3sJbnokVPLgwJnfZy5wseoDFI+YlpD7bVQBO+j6Vc4NQwlD4X85thgr+j6gR ea2LXDQm4SPlJ9ReVKwmSdFXTBFBKAMwR65nJ9yF7IuEd+eHXqm3kzz07bq5OHiTZLbu VYMujYmWtIHNOz9VW7NHbR/ZZybgH+MtbSXlzxStVegjaP6+UNW4i3ADS9hgwK1LSnkb t2JdvDu4v0qajwIcft5PMoXRBGjBCtHrR22UaPGZSqd+xhXA0CBLzsarfg4gvuykMDgm euG7ykzLBxf5qlmLjNGqK1E32GGaNa3sHMazK1c3h4YcX9JquAWpurpfbXEvoUkMCvYK XjYQ== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPD3qTHFHYY6IQdEi5xDMGFi0UZdg==" X-RZG-CLASS-ID: mo00 Received: from nimes.localnet by smtp.strato.de (RZmta 48.2.1 AUTH) with ESMTPSA id v9c7e6yARHmZwBI (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 27 Nov 2022 18:48:35 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Cc: Simon Josefsson , Vincent Fortier Subject: Re: explicit_bzero and -std=c99 Date: Sun, 27 Nov 2022 18:48:35 +0100 Message-ID: <2208312.3ZeAukHxDK@nimes> In-Reply-To: <87pmd8prhh.fsf_-_@latte> References: <87tu2kps44.fsf@latte> <87pmd8prhh.fsf_-_@latte> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=81.169.146.218; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 Hi Simon, > 1) Does gnulib support building with gcc -std=c99? I think we should, > but it could have documented missing functionality or breakage. No, Gnulib does not support this. We freely use GCC extensions, such as ({...}) or asm, usually conditionalized with defined __GNUC__ || defined __clang__ Only in math.in.h and xalloc-oversized.h we also test __STRICT_ANSI__. We could test __STRICT_ANSI__ also in more places, but what really is the point? So that people then complain "the asyncsafe-spin and simple-atomic tests fail for me"? The point of '-std=c99' is to verify that the source code is pure ISO C without any extensions. Gnulib is not in that category. > 2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for > GCC, which isn't working in non-GNU modes of gcc. In lib/explicit_bzero.c you see that we need to defeat compiler optimizations. 'asm' lets us formulate a memory barrier. Without 'asm' we have a fallback code that defeated compiler optimizations at the time it was written, but that will break in the long run as compilers are becoming better. > Further wondering: > > 1) The reason for having explicit_bzero is read_file, which needs it > for reading sensitive files, a feature we don't use. Uncoupling this > unnecessary dependency would have been nice. No, we have explicit_bzero because it's a glibc function that we think should be available to programs on all OSes. > 2) Is there no other way to implement explicit_bzero without 'asm'? > There is a another fallback code using volatile pointers, but I'm not > sure it really has the same semantics. That's the point, exactly: Here 'asm' is necessary. > 3) Is there a way to detect if the compiler supports 'asm'? The > current test 'defined __GNUC__ && !defined __clang__' is what is > really failing here. Probably something like (defined __GNUC__ || defined __clang__) && !defined __STRICT_ANSI__ > 3) Is the idiom of using separate functions bzero() vs explicit_bzero() > to avoid security-problematic compiler optimization still a good one? > > 1) If yes, I think we should have read_sensitive_file() rather than > extending read_file() with a flag for this purpose. > > 2) If no, what is the better idiom to use here instead of > explicit_bzero? When the code for average contexts and the code for secure contexts differ only by a few lines of code, we would like to avoid code duplication. As code duplication means twice the maintenance effort in the future. Things would be different when you want the code for secure contexts to use exactly the same instructions (just with different data), regardless of the input data.[1] Since code for average contexts is typically written to minimize the number of instructions depending on the input data, this would imply different algorithms and different code. But we are not in this case here. Bruno [1] https://en.wikipedia.org/wiki/Timing_attack