[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 19 Mar 2024 16:51:02 +0100
From: Aaron Peter Bachmann <aaron_ng@...de.at>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Jens Gustedt <jens.gustedt@...ia.fr>
Subject: Re: 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
>> <aaron_ng@...de.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
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.
