Philipp Klaus Krause <p...@spth.de> wrote:
> Am 10.08.20 um 17:00 schrieb Theo de Raadt:
> > Philipp Klaus Krause <p...@spth.de> wrote:
> >
> >> OpenBSD has the explicit_bzero function to reliably (i.e. even if not
> >> observable in the C abstract machine) overwrite memory with zeroes.
> >>
> >> WG14 is currently considering adding similar functionality to C2X.
> >
> > Then perhaps in the interests of the public they should use the same
> > name, but I suspect they won't.
>
> The functionality (i.e. some way to reliably overwrite memory) already
> exists under different names: explicit_bzero in OpenBSD
This one was first.
> memzero_explicit in Linux
glibc people saw the need and followed us, but they felt compelled to
change the name. NIH.
> memset_s in the optional Annex K of the C
> standard,
Annex K is completely dead and un-adopted enough that application code
will not even look for or call it. The embedding of errno_t and
exceptions were some of the dumbest ideas ever, probably an attempt by
MSFT to undermine unix-heritage libc functions. Because of those gross
warts in the API, it will never see further adoption and noone should
pay any attention to it.
> explicit_memset in NetBSD
Followed Linux, also a couple years later, and they needed to change
the name also.
> SecureZeroMemory in Windows etc.
Which makes no attempt to be name it in a fashion that would ever gain
cross-operating system use. Camel case functions do not make it into
unix libraries.
> A problem with the explicit_bzero name is that it is not an identifier
> reserved for future extensions of the C standard, unlike identifiers
> starting with mem.
Well, the problem is we are not supposed to use the mem prefix, so WE
DID NOT. It is like are suggesting it is OK that others simply stepped
into the reserved name space? Maybe we should remember in the future,
that if you don't stomp, the commitee will eventually arrive to create
an #ifdef application horrorshow. Maybe the above mention of the ^mem
prefixed one can be understood as a blessing, and we should have ignored
the edit, and chosen such a name??
(We did ignore the edict when we created the widely deployed
strlcpy/strlcat, and are probably doing the same with
reallocarray/recallocarray/freezero which are now seeing substantial
deployment also).
> >> * A function like memclear, that overwrites the memory in an
> >> implementation-defined manner, possibly using random data.
> >
> > This option is pretty laughable, because the compiler has no way to
> > collect random data. Their is nothing portable the compiler can call
> > to get the random data. I've personally worked on making this possible
> > for more than a decade, and it is still not all there.
>
> This option under the name secure_clear apparently is the one preferred
> by WG21, the C++ comittee.
Well, I accuse the commitee of Not Invented Here.
Our base tree has 641 calls to explicit_bzero, because previous
commitees fucked the C language and created hundreds of not thousands of
security vulnerabilities by leaving data on the stack. In application
software, both explicit_memset and explicit
It is obvious the commitee has no desire to focus on improving the
ecosystem for their mistake and want to increase name confusion, but
want to look good and solve this problem, what is it.. 10 or 15 years
late? I've lost track of time.
It is very much like the posix_random fiasco:
https://www.austingroupbugs.net/view.php?id=859
So I predict it will take decades for secure_clear to come into common
use.
Sometimes a name isn't perfect. But one name may still be more perfect
than two names, or three names, or six names. *SIX NAMES*, is the situation
WG21 would create.
