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=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,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 D38D21F4C1 for ; Mon, 28 Nov 2022 10:33:02 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=permerror (0-bit key) header.d=josefsson.org header.i=@josefsson.org header.b="SfOe/PH1"; dkim=temperror (0-bit key; unprotected) header.d=josefsson.org header.i=@josefsson.org header.b="Yc75D0eU"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozbRL-0006jh-Fk; Mon, 28 Nov 2022 05:32:43 -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 1ozbRK-0006hR-7S for bug-gnulib@gnu.org; Mon, 28 Nov 2022 05:32:42 -0500 Received: from uggla.sjd.se ([2001:9b1:8633::107]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozbRH-0007Zj-S2 for bug-gnulib@gnu.org; Mon, 28 Nov 2022 05:32:41 -0500 DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2110; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=yCNUKpEr/4oJgA5P+XAjnqOeEGtHaWRR+YSHqGOfCGc=; t=1669631559; x=1670841159; b=SfOe/PH1v/NcPARwrIqsTLXkw9N5enBudevfx83miLEFn/qWOgf0JMQJk7m7rqJNOHKBfBzLu59 7rQTgqppxAQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2110; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=yCNUKpEr/4oJgA5P+XAjnqOeEGtHaWRR+YSHqGOfCGc=; t=1669631559; x=1670841159; b=Yc75D0eUNwjd2NLlg3Pih6pCBF3kyhspYr1vV6jjrBp+NwIeh7lgm5vc5g1C+o4jnLsKETVcCas 5+gz3Qse7YfE1eoRCkxZSBf4XDPaP1GUqXV1FVKtS7clVzmZkqSIbC5y4ilI5H6asT8Oe+00UVu50 Lc9a4PI6s79O1CCEM4fvVa4qdJvaKcnA/2nPi+p3AfUycZZkWJbEQBdDKQts62l7M5OR7XgY+Trvw +/y+3Q0+WCy0BELL62kyjexMl+7eOVLTBo57SS5XvWsZ5UU2X5m+EOIW3HJGaWCXefdKb0p4CuJkD dYeY7lZzi2wkp32pQT0Uibfya/1vjACLill0MYxOSVq1mK5nRLvUABvFHquB0PWUGhyoRW/dZLJmf MbYgDNeaCo1ag1F3liZi3HRTD71GVLEoTtorunMitZnyiN/Zb7y12O9IebsrRheD8VqlydzYq; Received: from [2001:9b1:41ac:ff00:a360:dda7:f90e:1e60] (port=54442 helo=latte) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ozbRE-006yMW-WA; Mon, 28 Nov 2022 11:32:37 +0100 X-Hashcash: 1:22:221128:eggert@cs.ucla.edu::fqsG0WI8RY+QZFeb:4Hmf To: Bruno Haible , Paul Eggert Cc: bug-gnulib@gnu.org Subject: Re: explicit_bzero and -std=c99 References: <87tu2kps44.fsf@latte> <87pmd8prhh.fsf_-_@latte> <2208312.3ZeAukHxDK@nimes> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:221128:bug-gnulib@gnu.org::QX2FiQc5TBXmwUJ6:6yPc X-Hashcash: 1:22:221128:th0ma7@gmail.com::RJxn4Qg5FsioHwgS:AD13 X-Hashcash: 1:22:221128:bruno@clisp.org::kY22ZWoRGDazkF6s:l/7/ Date: Mon, 28 Nov 2022 11:32:35 +0100 In-Reply-To: <2208312.3ZeAukHxDK@nimes> (Bruno Haible's message of "Sun, 27 Nov 2022 18:48:35 +0100") Message-ID: <874juj2wu4.fsf@latte> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:9b1:8633::107; envelope-from=simon@josefsson.org; helo=uggla.sjd.se X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, SPF_HELO_PASS=-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.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Simon Josefsson From: Simon Josefsson via Gnulib discussion list Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Eggert writes: >> 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. Further wondering: > > I hope I fixed this particular problem by installing the attached. Thank you! > Perhaps Gnulib's other uses of asm should also be changed? Yes I think we should '__asm__' instead of 'asm' for the reason explained by the gcc manual that Bruno linked to. >> 3) Is the idiom of using separate functions bzero() vs explicit_bzero() >> to avoid security-problematic compiler optimization still a good one? > > Yes If so, I would prefer a read_sensitive_file() API instead of read_file() with a flag to enable the security-sensitive functionality. I'll leave it for the future, as this the immediate problem is resolved. Bruno Haible writes: >> 1) Does gnulib support building with gcc -std=3Dc99? 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=3Dc99' is to verify that the source code is pure ISO C > without any extensions. Gnulib is not in that category. Your answer is a bit different from Paul's, and both seems like reasonable approaches to me. This may be a situation where sometimes we make a small effort of being compatible with -std=3Dc99 and sometimes decide against it. I think what could help is a bit more documentation about this problem. Building gnulib with -std=3Dc99 and fixing some of the minor issues will likely help future compatibility of code, so I think we should make small efforts to comply. I agree that there is likely some parts of gnulib that simply don't work in C99-mode -- documenting what they are would be useful. In libtasn1, we want to support C89 environments since it is such a low-level and bootstrap-relevant library. At least for the library, the command-line tool doesn't have to be C89-compatible IMHO. >> 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. > Sorry I was unclear: the reason for LIBTASN1 to have explicit_bzero is read_file. But libtasn1 never uses the sensitive flag, and thus never really excercise the explicit_bzero code path. >> 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__ Using __asm__ instead seems more elegant, and even aligned with gcc manual. >> 3) Is the idiom of using separate functions bzero() vs explicit_bzero() >> to avoid security-problematic compiler optimization still a good one? >>=20 >> 1) If yes, I think we should have read_sensitive_file() rather than >> extending read_file() with a flag for this purpose. >>=20 >> 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. Sure -- although it would be possible to implement the essence of read_file in a way where support for the sensitive flag is a compile-time option. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQSjzJyHC50xCrrUzy9RcisI/kdFogUCY4SORBQcc2ltb25Aam9z ZWZzc29uLm9yZwAKCRBRcisI/kdForNsAQCzY6ZkkSYMMOJHAam8+ECVgqYv0yYJ DlN797jYoEHB1gEAmX8u9VU7bCZOMeEBgbUKltmfMX0Xg5cFraTyV3G8Egw= =aiAp -----END PGP SIGNATURE----- --=-=-=--