From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id A94902CC80 for ; Tue, 19 Mar 2024 17:19:20 +0100 (CET) Received: (qmail 5186 invoked by uid 550); 19 Mar 2024 16:14:50 -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 5151 invoked from network); 19 Mar 2024 16:14:49 -0000 Date: Tue, 19 Mar 2024 12:19:26 -0400 From: Rich Felker To: Aaron Peter Bachmann Cc: musl@lists.openwall.com, Jens Gustedt Message-ID: <20240319161925.GM4163@brightrain.aerifal.cx> References: <1ad1a194-f2f5-4ae1-9686-67961086e605@inode.at> <20240319145026.34c1a068@inria.fr> <20240319140213.GJ4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] c23 memset_explicit() On Tue, Mar 19, 2024 at 04:51:02PM +0100, Aaron Peter Bachmann wrote: > I have read the discussion  from 2023-05-26 to and including 2023-05-29. > > https://www.openwall.com/lists/musl/2023/05/26/8 says > "implement explicit_bzero in terms of memset_explicit" > As a non-native speaker I am not entirely sure what that is supposed > to mean. > I have two destination. > 1. Implementing  explicit_bzero () by calling  memset_explicit() This is what it means. > That would save one line of source at the cost of an additional branch, > as it is a tail-call. I do not think that is a good tradeoff. But it > is unlikely to to make a difference in practice. It's not a tail-call except on archs with args-in-registers and no caller-reserved space for spilling args. > 2. Implement it like the implementation of explicit_bzero() > That is indeed what I have done. I lean towards this 2nd interpretation. I think this is a better approach. > In > https://www.openwall.com/lists/musl/2023/05/26/8 > Joakim Sindholt has proposed THE ABSOLUTE SAME PATCH already! > Even with d for destination, as it is done in explicit_bzero(). > c23 uses s as destination, memset() in musl dest. Yes. > But Jens has a point. > In the long run I also hope for compilers recognizing > memset_explicit() and also erase other copies it has made (in > registers or on stack) without being explicitly requested to do so > in the source. > And it should NOT be by an intrinsic someone has to call, but due to > the knowledge of the semantic of memset_explicit(). > If this is inline or by a function call is an implementation detail. Yes, it's better for the compiler to use its own intrinsic so that it can know to clear out anywhere else it may have spilled the same data. But that's separate from the external function we need to implement in libc. > If I had not tried to adapt to the musl coding style I would have > accepted a few 100 cycles delay for the writes to take effect: > > static void *(*volatile lib_memset_fp)(void *restrict,int,size_t)=memset; > void *memset_explicit(void *restrict dest,int val,size_t len){ >     return (*lib_memset_fp)(dest,val,len); > } This is a worse implementation that does not convey the semantics that the result of the zeroing is used (and can't be optimized out), using volatile hacks rather than an actual dependency. This approach was rejected when explicit_bzero was proposed, IIRC. Rich