[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240319161925.GM4163@brightrain.aerifal.cx>
Date: Tue, 19 Mar 2024 12:19:26 -0400
From: Rich Felker <dalias@...c.org>
To: Aaron Peter Bachmann <aaron_ng@...de.at>
Cc: musl@...ts.openwall.com, Jens Gustedt <jens.gustedt@...ia.fr>
Subject: Re: c23 memset_explicit()
On Tue, Mar 19, 2024 at 04:51:02PM +0100, Aaron Peter Bachmann wrote:
> 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()
This is what it means.
> 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.
It's not a tail-call except on archs with args-in-registers and no
caller-reserved space for spilling args.
> 2. Implement it like the implementation of explicit_bzero()
> That is indeed what I have done. I lean towards this 2nd interpretation.
I think this is a better approach.
> 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.
Yes.
> 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.
Yes, it's better for the compiler to use its own intrinsic so that it
can know to clear out anywhere else it may have spilled the same data.
But that's separate from the external function we need to implement in
libc.
> 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);
> }
This is a worse implementation that does not convey the semantics that
the result of the zeroing is used (and can't be optimized out), using
volatile hacks rather than an actual dependency. This approach was
rejected when explicit_bzero was proposed, IIRC.
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.
