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: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 26 Aug 2015 17:54:09 -0400
- Subject: Re: [PATCH RFC] explicit_bzero, again
- Authentication-results: sourceware.org; auth=none
- References: <55C7E246 dot 3000006 at panix dot com> <55D0BDA7 dot 40402 at panix dot com> <55D653AF dot 8000107 at linaro dot org> <CAKCAbMhW4WrGYdaqiFBRYh8Vxt+5kmDb5fv7XiJ0ps1_4PA1jw at mail dot gmail dot com> <55DE2A73 dot 3060202 at linaro dot org> <CAKCAbMiaevQiDhXeJbAPNRSd7VAneQdbLZs7Ggai-Zr4oBTaHw at mail dot gmail dot com> <55DE30D0 dot 1090602 at linaro dot org>
On Wed, Aug 26, 2015 at 5:34 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 26-08-2015 18:13, Zack Weinberg wrote:
>> The *optimization* (replacing `explicit_bzero` with `memset` + vacuous
>> use) is limited to C programs and GCC. The *API* works just fine
>> regardless of compiler. I believe this is sufficient as a starting
>> point. As and when appropriate ways to express a vacuous use become
>> available in other compilers, we can add them.
>
> Right, but do you know what kind of optimization the 'memory' cobbler avoids
> and your suggestion allows? I do understand that the 'memory' cobbler is
> indeed a more restrictive memory barrier, but for mostly targets avoids
> a function calls were is possible is a much more gain that some memory
> operations begin handle with restrictive scheduling.
That's a good question. I can tell you one general type of code that
would have a problem...
struct complicated_object {
int many, other, fields;
char sensitive[32];
}
where code temporarily fills in `sensitive` and uses explicit_bzero to
erase it when it's done; the "memory" clobber would force the compiler
to flush all the other fields of `complicated_object` to memory and
reload them afterward. They don't have to be tied together with a
`struct` even; the sensitive data could be on the stack while all the
other state being manipulated was on the heap, and it would still have
to flush everything.
What I don't know is what would make for better optimization in
practice, and unfortunately I do not have time to go digging through
existing users of secure-memory-clear functions to figure out where
the tradeoff lies. And I don't feel that picking one kludge over
another is a great use of anyone's time. Instead, I want to get
something in with known, reliable semantics (but not optimal and with
documented limits), and then move over to the compiler side to work on
optimization and more thorough sanitization. I almost didn't bother
with string[23].h optimizations at all and now I'm kind of regretting
having done them.
zw