This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] explicit_bzero, again
- From: Zack Weinberg <zackw at panix dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 15 Sep 2015 11:36:58 -0400
- Subject: Re: [PATCH RFC] explicit_bzero, again
- Authentication-results: sourceware.org; auth=none
- References: <55C7E246 dot 3000006 at panix dot com> <55F050D3 dot 2070403 at panix dot com> <CAKCAbMhudB3_J78haR__uw1MrJLnGYw4yH+N82G5b1Ap2gkEXg at mail dot gmail dot com> <55F83002 dot 9040906 at linaro dot org>
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.
> 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.
> 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.
> 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.
zw