From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4517 invoked from network); 29 May 2023 07:48:58 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 29 May 2023 07:48:58 -0000 Received: (qmail 29954 invoked by uid 550); 29 May 2023 07:48:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29919 invoked from network); 29 May 2023 07:48:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=ZGeG2759lhbhazeRfBFzhrLaaU9cC4xuHgyI9uR6HAc=; b=RYRqddfeUPFZlHI6zHaFh/TFJ4pfSt3pUhuMijLRJaI/YDo0pQxkiPNm guvbREvQ57H3/OImqs5eDOx2QvdLA7/7QPceLF4t5mzqmQA8HemaGC1xh tGKmpXpweccnELRiNILJT8J6uPnHUyTWkolY9NuHutmhJogcZt7sbBnJS I=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.00,200,1681164000"; d="scan'208";a="57235159" Date: Mon, 29 May 2023 09:48:42 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: NRK Cc: musl@lists.openwall.com Message-ID: <20230529094842.10a6291b@inria.fr> In-Reply-To: <20230528101318.qewkay4z7s3bdj46@gen2.localdomain> References: <20230528101318.qewkay4z7s3bdj46@gen2.localdomain> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/7r8HAQgE5UsRv7U4QGTCxKQ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] [C23 string conversion 1/3] C23: add the new memset_explicit function --Sig_/7r8HAQgE5UsRv7U4QGTCxKQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, on Sun, 28 May 2023 16:13:18 +0600 you (NRK ) wrote: > On Fri, May 26, 2023 at 11:25:43AM +0200, Jens Gustedt wrote: > > By having a slow bytewise copy, we intent also to have predictable > > timing, such that we can avoid side-channel attacks. =20 >=20 > I don't believe `volatile` provides any guarantee of emitting > constant-time operations (which can be CPU dependent). But even if it > happens to work out in practice, from a user/non-cryptographer's > perspective, I feel like claims like "avoiding side-channel attacks" > needs much more substantiation than just slapping a `volatile` on top > of a pointer. >=20 > But as I've said, not a cryptographer, I am not a cryptographer either, I wrote that code in best effort mode: doing anything that I can that doesn't harm the goals of this function. Very likely, this code will sit there unattended for the next 20 years. I personnally do not know what the future brings, what compilers will be capable of, and what the expectation of users will be. In my opinion putting `volatile` in here is worth it, even if it only might inhibit one single exploit in the next 20 years. The same holds for stronger synchronization, I don't know about the capabilities (or bugs) of future systems where an external agent from a different thread, process or outside tool might guess addresses and peek into storage, caches, whatever, before the information is erased. Closing the window for this as much as possible seems a valid strategy to me. `memset` and `memset_explicit` have quite orthogonal goals. The first is to put a buffer in a known state *before* you use it, it is used often and performance is crucial. The second is to put a buffer back into a known state *after* you use it, to remove all the traces that your application migh have left there, and avoid any unintended outflow of information. It will be used rarely, probably on small bits of data (pathwords and such) and performance is irrelevant. So I think that the arguments should go just in an opposite direction for this particular function than we usually have it. > so please *do* correct me if I'm wrong or am being unnecessarily > paranoid. In the contrary, you may not be sufficiently paranoid. Paranoia is key for this function. > P.S: even if the claim is correct, other major implementation would > also have to agree to provide such guarantee in a documented manner > for this to be useful to the users. Otherwise, users will have to > resort to hard-coded libc checks or simply not rely on this property > at all. I don't buy that argument either. This function is not there for specific guaratees that a platform gives. It is a best effort attempt by *us* to avoid information leakage. This is our responsability here, nothing else. Thanks J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/7r8HAQgE5UsRv7U4QGTCxKQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZHRY2gAKCRAP0+hp2tU3 4iczAKCOdPxSxrXcWvf9SAa1oi5V0cf7IgCfRsYFL+kEpvfiSfJc9wC0ckDSSsw= =bpRb -----END PGP SIGNATURE----- --Sig_/7r8HAQgE5UsRv7U4QGTCxKQ--