[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK1hOcMx+ibdoEE95h2R5+y6Znf1S4X0cSq-s3Nv+cuRk5-DuA@mail.gmail.com>
Date: Thu, 22 Oct 2015 18:09:31 +0200
From: Denys Vlasenko <vda.linux@...glemail.com>
To: musl <musl@...ts.openwall.com>
Cc: gcc@....gnu.org, llvmdev@...uiuc.edu,
GNU C Library <libc-alpha@...rceware.org>
Subject: Re: Compiler support for erasure of sensitive data
On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg <zackw@...ix.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
