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 8DE502BFF7 for ; Tue, 19 Mar 2024 15:02:07 +0100 (CET) Received: (qmail 25940 invoked by uid 550); 19 Mar 2024 13:57:37 -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 25905 invoked from network); 19 Mar 2024 13:57:37 -0000 Date: Tue, 19 Mar 2024 10:02:13 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: Aaron Peter Bachmann , musl@lists.openwall.com Message-ID: <20240319140213.GJ4163@brightrain.aerifal.cx> References: <1ad1a194-f2f5-4ae1-9686-67961086e605@inode.at> <20240319145026.34c1a068@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240319145026.34c1a068@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] c23 memset_explicit() 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