This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [musl] Compiler support for erasure of sensitive data
- From: Denys Vlasenko <vda dot linux at googlemail dot com>
- To: musl <musl at lists dot openwall dot com>
- Cc: gcc at gcc dot gnu dot org, llvmdev at cs dot uiuc dot edu, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 22 Oct 2015 18:09:31 +0200
- Subject: Re: [musl] Compiler support for erasure of sensitive data
- Authentication-results: sourceware.org; auth=none
- References: <55F05FF1 dot 3000405 at panix dot com>
On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg <zackw@panix.com> wrote:
> The first, simpler problem is strictly optimization. explicit_bzero
> can be optimized to memset followed by a vacuous use of the memory
> region (generating no machine instructions, but preventing the stores
> from being deleted as dead); this is valuable because the sensitive
> data is often small and fixed-size, so the memset can in turn be
> replaced by inline code.
How valuable is that speedup due to possible inlining?
You know, call instruction is not a crime.
In fact, it is *heavily* optimized on any CPU exactly because
calls happen gazillion times every second.
In my measurement, on x86 call+ret pair is cheaper than
a single read-modify-write ALU op on L1 data item!
So, just implement explicit_bzero() as a function which
is prohibited from inlining, and which clears all call-clobbered
registers in addition to clearing memory.
This will probably also be the smallest solution code size wise.