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.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5835 invoked from network); 27 May 2023 13:52:31 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 27 May 2023 13:52:31 -0000 Received: (qmail 6045 invoked by uid 550); 27 May 2023 13:52:27 -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 6011 invoked from network); 27 May 2023 13:52:27 -0000 Date: Sat, 27 May 2023 09:52:14 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: Joakim Sindholt , musl@lists.openwall.com Message-ID: <20230527135213.GR4163@brightrain.aerifal.cx> References: <20230526115236.b15f8bf97a529da07fba514f@zhasha.com> <20230526121829.4b9a9538@inria.fr> <20230526201603.GM4163@brightrain.aerifal.cx> <20230526223552.7878f5f0@inria.fr> <20230526205720.GP4163@brightrain.aerifal.cx> <20230527084947.71628791@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230527084947.71628791@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 string conversion 1/3] C23: add the new memset_explicit function On Sat, May 27, 2023 at 08:49:47AM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Fri, 26 May 2023 16:57:21 -0400 you (Rich Felker ) > wrote: > > > Do you have something in mind about how the explcit_bzero > > implementation we have doesn't do that? > > I would be more comfortable with a stronger synchronization barrier > that works for all memory models and also in the presence of threads > and signals. So maybe using `a_barrier()`? There is no distinction here with repect to signals. With respect to threads, I guess it's a distinction of whether data races in other threads could still see the value that was supposed to have been cleared. This is impossible already is there is any synchronization ordering the operation of clearing with the access from another thread. If there is not, then the operations are unordered with respect to one another and the value *could already have been seen* just by execution in a different order, before the explicit_memset. So I don't see how this is supposed to be helpful. > Also I think that relying on the compiler's `memset` is not a good > strategy. This puts us at their merci of whatever efficiency games > they are playing, now or in the future. It's not the compiler's memset. It's the external function. Because this is all built as -ffreestanding, the compiler is not able to expand calls to standard functions as the builtins. -ffreestanding implies -fno-builtin. However, I claim it would actually be better/safer if it were the compiler's memset. Consider the case where explicit_bzero is inlined in the caller (the only one in which anything significantly differs), and the caller is trying to clear a private key in a local variable whose address has not otherwise been taken (or for which all accesses through the address were already collapsed via ipa/inlining). With the compiler's memset, it can operate directly on the caller's local variable in-place in a register, just zeroing the register, *then* spill the zero to actual memory for the __asm__ barrier. With an external memset, it has to first spill the key to memory for memset to clear it. The copy in the register remains in place until the register is reused for something else. This is one aspect in which your version is preferable, but it would/will be fixed by making src/include/string.h re-enable use of builtins conditional on a configure test for them. Rich