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 31612 invoked from network); 26 May 2023 20:57:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 May 2023 20:57:38 -0000 Received: (qmail 9403 invoked by uid 550); 26 May 2023 20:57:34 -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 9297 invoked from network); 26 May 2023 20:57:33 -0000 Date: Fri, 26 May 2023 16:57:21 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: Joakim Sindholt , musl@lists.openwall.com Message-ID: <20230526205720.GP4163@brightrain.aerifal.cx> References: <20230526115236.b15f8bf97a529da07fba514f@zhasha.com> <20230526121829.4b9a9538@inria.fr> <20230526201603.GM4163@brightrain.aerifal.cx> <20230526223552.7878f5f0@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230526223552.7878f5f0@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 Fri, May 26, 2023 at 10:35:52PM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Fri, 26 May 2023 16:16:03 -0400 you (Rich Felker ) > wrote: > > > We had all of these discussions back when explicit_bzero was added, > > and it was done the way it was done because it's portable (within the > > framework of what musl already requires) and non-arch-specific, has > > zero overhead, avoids any code duplication or bad performance > > open-coding another memset variant, > > My impression is that such information is quite difficult to find, but > maybe I didn't search enough. Sometimes code comments would help ;-) It was discussed in the "thoughts on reallocarray, explicit_bzero?" thread in 2014, starting here: https://www.openwall.com/lists/musl/2014/05/19/3 > Bad performance really isn't a valid argument in this case. This is > not supposed to be efficient. Any user that uses this has to know that > they are trading it for something. I'm not sure whether performance here is a good criterion or not, but making it ~gratuitously~ slow with an extra implementation of memcpy open-coded here does not make sense. > > and avoids taking part in any security theater (pretending we can > > clear things we can't). > > It is not about taking part. For me it is just about offering to our > users the best service for this tricky question that we may, and not > less. Do you have something in mind about how the explcit_bzero implementation we have doesn't do that? Rich