Re: [PATCH RFC] explicit_bzero, again

[Zack Weinberg <zackw at panix dot com>]

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