[PATCH RFC] explicit_bzero, again

Adhemerval Zanella adhemerval.zanella@linaro.org
Tue Sep 15 16:08:00 GMT 2015



On 15-09-2015 12:36, Zack Weinberg wrote:
> On Tue, Sep 15, 2015 at 10:49 AM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> At first I was convinced that adding this symbol would be a good approach,
>> but after reading comments from Rick Felker and Szabolcs Nagy I am not sure
>> any more.
> 
> I understand where you are coming from, but I must insist that the
> perfect not be allowed to be the enemy of the good.
> 
> 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: if applications have to
> reinvent it, they may get it wrong; libc is the right place to
> consolidate knowledge about what compiler support is or is not
> available; and only libc can supply _FORTIFY_SOURCE wrappers.
> 
> Moreover, if a better approach (with compiler support) ever does
> materialize, a libc-provided explicit_bzero can transparently morph
> into an invocation of that better approach.  If it is left to
> applications, each application would have to change to activate the
> better approach.

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.

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.

> 
>> Besides the '__explicit_bzero_constn' optimization that uses VLA, which is
>> not portable and source of issues in a lot of projects (llvmlinux for instance),
> 
> It is properly limited to C+actual gcc.  If this really is the
> deciding factor, I am prepared to remove the optimization altogether,
> but again, I do not see why the lack of _ideal_ compiler support for
> this should mean that we shouldn't do the best we can with what we
> have.

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 did not see much traction on 'Compiler support for erasure of sensitive data'
>> thread for adding a similar feature at compiler side.
> 
> This is, sadly, true, but in my opinion it only strengthens the case
> for the implementation in libc, because it means we may be waiting a
> very long time for the compilers to step up.
> 
>> * async signal handler copying all the register state on sigaltstack
>> * internal counters and debug features making sensitive info observable
>> * timing/cache-effect side channels that let other processes get info
>> * compiling to a highlevel language (js) with different kind of leaks
>> * running under emulator/debugger that can make secrets visible
> 
> These vulnerabilities exist regardless of whether the C library
> provides explicit_bzero; the inability to close _all_ the holes right
> now should not stop us from closing a hole we _can_ close right now.
> 
>> So I am not sure if this is a good idea do add this symbol on glibc, something
>> it will require to carry on indefinitely and that might be replaced either
>> by some compiler directive or by more correct solutions (hardware assistant).
> 
> The backward compatibility load is trivial: two exported symbols, of
> which one is an alias for a symbol that already exists, and the other
> is a thunk compiling to five instructions or less.  By way of
> comparison, the backward compatibility symbols for <regexp.h> are ~150
> bytes of code and ~12 bytes of bss.

I agree with you, but my view is if it is worth to add on *GLIBC* a functionality
that has very limited usage and a lot of limitations.  

> 
>> Also this can be enabled project by project in a very easy way if it decides
>> that is worth to implement.
> 
> This has already happened.  codesearch.debian.net reports 597 mentions
> of explicit_bzero, 645 mentions of OPENSSL_cleanse, 6 mentions of
> explicit_memset, 721 mentions of memset_s, 328 mentions of
> memzero_explicit, 216 mentions of memwipe, 295 mentions of wipememory.
> We wouldn't be having this conversation at all if there weren't a
> demonstrated demand from the application side.

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.

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

> 
> zw
> 



More information about the Libc-alpha mailing list