[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 May 2023 16:57:21 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: Joakim Sindholt <opensource@...sha.com>, musl@...ts.openwall.com
Subject: Re: [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 <dalias@...c.org>)
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
