Re: [musl] c23 memset_explicit()

[Rich Felker <dalias@libc.org>]

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
> <aaron_ng@inode.at>) 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