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.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 792CB2CB49 for ; Tue, 19 Mar 2024 17:00:55 +0100 (CET) Received: (qmail 1922 invoked by uid 550); 19 Mar 2024 15:56:24 -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 19890 invoked from network); 19 Mar 2024 15:47:13 -0000 X-Env-Mailfrom: aaron_ng@inode.at X-Env-Rcptto: musl@lists.openwall.com X-SourceIP: 85.127.183.170 X-CNFS-Analysis: v=2.4 cv=WLfcXWsR c=1 sm=1 tr=0 ts=65f9b483 a=EGcOpCTuptRmag7BTP1Y/Q==:117 a=EGcOpCTuptRmag7BTP1Y/Q==:17 a=IkcTkHD0fZMA:10 a=XkRKQH6RAAAA:8 a=5KEJ3k9QAAAA:8 a=-SoMvKfTAAAA:8 a=RBlStkRLJkMvznMrpdoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1gUyE30hU_ULiMxJiLUW:22 a=olg2BfGzmf2haRflzj8J:22 a=zb3qCS2OI_lOj0iQqKOG:22 X-Authenticated-Sender: aaron_ng@inode.at DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=inode.at; s=201801custpemceu; t=1710863491; bh=GSNzP3PME9AstjTqa3n1j39nJge7xKGaWgnYiUTKYCE=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=TMnZMOoN8/zVb8dUe1CesJ8LzNUEeV22dtvlJo2nxGfeIsLHebJaKtGvKv2yr1UDv 7Z1zC8XKA4nyh7Sez1PXUnBPbppvk+CnHzT4vlR1f3B94r7r0jQps0EJkw86tJu00r tALl7MVGY7AQ2eBAjMYQu5dPyXZy4iKCNKkcjYH5E1kfMh1w9gYtf9uC8yNr+fox94 blzyuIi2VruN57vEoaQDtcZdzFZi3Rq9Ftry85386gEC41yw8wNKFIlA7GChqfjbUG Qqj69UAkkP7cDKL4961JZEHOOY0E9uvQaOoY47KrkvsEcw5Q3HzrAA/i8KwZhcdfU3 8Z2ETnQkb2riQ== Message-ID: Date: Tue, 19 Mar 2024 16:51:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US, de-DE To: Rich Felker Cc: musl@lists.openwall.com, Jens Gustedt References: <1ad1a194-f2f5-4ae1-9686-67961086e605@inode.at> <20240319145026.34c1a068@inria.fr> <20240319140213.GJ4163@brightrain.aerifal.cx> From: Aaron Peter Bachmann In-Reply-To: <20240319140213.GJ4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfPylXNoN6lkwMY0LldfS0oYT/20iRGb0PXXvlNwjoYq3Zia0VabsUD5GdVdKX4785fo018qbvDwdbR/NvGXbJZNHVPUpZJe87ZeSMgfcpWweMy0aphKP 4oBh8vYGFJ09n+zVI7+uSlx3iYShbvJvcPzpKxaKOuWMw2wLWsBgDe71QcqZJMgAEWdf09NUjw+hSkCFYiHiipO2x6IWk+84wYK0eA2mL6eoM8BY7cZuOD1k 6tuJD+uHvKP0xZEW8A0yIg== Subject: Re: [musl] c23 memset_explicit() 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() 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. 2. Implement it like the implementation of explicit_bzero() That is indeed what I have done. I lean towards this 2nd interpretation. 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. 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. 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); } Regards, Aaron Peter Bachmann On 3/19/24 15:02, Rich Felker wrote: > On Tue, Mar 19, 2024 at 02:50:26PM +0100, Jₑₙₛ Gustedt wrote: >> Aaron, >> >> on Tue, 19 Mar 2024 12:18:20 +0100 you (Aaron Peter Bachmann >> ) wrote: >> >>> I recognized neither >>> https://git.musl-libc.org/cgit/musl >>> nor >>> https://forge.icube.unistra.fr/icps/musl/-/branches >>> seem to include c23 memset_explicit(). >>> Or it slipped my attention. >> There had been such an implementation, but I removed it from the set >> because there was no consensus how it should look like. I'd prefer >> that someone else does it. If you want to read things up, there has >> been a discussion on this list in May last year. >> >> Your patch looks like the minimal thing that one would expect. For me >> personally that does not seem good enough. One of the things that >> bother me is that `memset` could have varying processing times, not >> only depending on the length of the input (which is unavoidable), but >> also depending on its contents. >> >> Anyhow, Rich had elaborated a whole strategy how this feature would >> better fallback to a builtin, if such a builtin exists. So I prefer >> them doing it, whenever they are ready. > I think this implementation looks exactly like what I recall > requesting. I'm not sure what the builtin thing was. It might have > just been that I'd like (in general) to make it so musl is able to use > the builtins internally, but that only makes any distinction here if > LTO is in use (i.e. if memset_explicit is inlined into the caller). > > I don't see where constant-time was part of the intended purpose of > memset_explicit (rather it seems to be intended just as a best-effort > way to avoid leaving around sensitive data, with all the possible > pitfalls that entails) and in general we don't make any promises of > constant-time in musl, but I don't see any reason the memset > implementations we use would have time dependency on original data > being overwritten, just things like whether it's cached. Maybe with a > large (many pages) buffer, something like zram could expose > information about the old contents through time or memory utilization, > but that's not really something we can defend against (and probably > not a good idea for robustness or data privacy). > > Rich