Re: [PATCH RFC] explicit_bzero, again

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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.

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),
I did not see much traction on 'Compiler support for erasure of sensitive data'
thread for adding a similar feature at compiler side. 

Also, as pointed out by Szabolcs Nagy, this 'best effort' contains a set of
limitations:

* 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

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).
Also this can be enabled project by project in a very easy way if it decides
that is worth to implement. 

On 15-09-2015 11:21, Zack Weinberg wrote:
> Ping.
> 
> On Wed, Sep 9, 2015 at 11:31 AM, Zack Weinberg <zackw@panix.com> wrote:
>> This updated patchset adds to the manual discussion of the situation
>> where using explicit_bzero *creates* a copy of sensitive data in memory,
>> which would not otherwise have been created.  There are no changes to
>> the code.  Earlier discussion with Florian and Adhemerval explored some
>> possible alternative implementation strategies but reached the
>> conclusion that this really is the best we can do without compiler support.
>>
>> zw