Re: [PATCH RFC] explicit_bzero, again

[Zack Weinberg <zackw at panix dot com>]

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