Re: [PATCH RFC] explicit_bzero, again

[Zack Weinberg <zackw at panix dot com>]

On Tue, Sep 15, 2015 at 12:08 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 15-09-2015 12:36, Zack Weinberg wrote:
>> There is clear demand from application programmers for this API.  It
>> is not a perfect API, but having it in libc is strictly better than
>> having each application reinvent it, because: [...]
>
> It boils down to the same argument to add the str{l}cpy and families that
> now and then arises in libc-alpha: applications programmers usage is only
> one factor (and imho not even the priority one) on GLIBC API design and
> extension.

To be honest, I believe strlcpy et al *should* be added to glibc,
because I believe the existence of a non-deprecated function in at
least two BSD C libraries should be taken as sufficient reason *all by
itself* to add it to glibc.

However, the case for strlcpy is much weaker than the case for
explicit_bzero.  The argument against strlcpy, as I understand it, is
that it does not solve *the problem it was designed to solve*.  The
strongest argument against explicit_bzero, by contrast, is that it
does not solve *a generalization of the problem it was designed to
solve*.

Thus, the argument against strlcpy is an argument on the merits of the
function itself, whereas the argument against explicit_bzero falls
under making the perfect the enemy of the good.

> And also based on same discussion, last time the person trying to convince
> us this would a good API to include could not really show any compelling
> reason do so. ... my view is if it is worth to add on *GLIBC* a functionality
> that has very limited usage and a lot of limitations.

It is true that it is used only under special circumstances, but these
special circumstances are common enough that the functionality exists
(under some name) in all of the BSDs, OSX, Windows, the Linux kernel,
OpenSSL, and libgcrypt. Moreover there are places *within glibc
itself* (specifically, crypt/) that *ought* to be using it.  If that
is not sufficiently compelling reason to add something, what *would*
you consider compelling?

> And as for str{l}cpy it does not really mean they are using the better
> approach to fix its issues it is proposing to fix. Or even, if using
> the API is indeed implement the security fixes they are aiming for.

Unlike strlcpy, the "ideal" data sanitization behavior would be a
*superset* of what explicit_bzero does.  Therefore explicit_bzero is
at least a step in the right direction.

> That is not really the issue, but Rich indeed remind us it is using VLA and
> although you profiling analysis showed us gain in code geration, for *strict*
> portability I do no see it the best approach (also, glibc code does not use
> VLA in any other place afaik).

I really don't think bits/string2.h is the place to quibble about
portability, but again, I will take the damn optimization out if it is
a deal-breaker.  I wasn't expecting to have nearly as much of an
argument about that bit.

> I would like to hear more comments from other GLIBC maintainers for the
> inclusion of the API.

I also.

zw