[RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.

[Rich Felker]

On Mon, Dec 15, 2014 at 01:29:59PM -0800, Paul Eggert wrote:
> On 12/15/2014 09:35 AM, Rich Felker wrote:
> >None of these solve the problem, because the compiler is free to have
> >copied part of all of this buffer into other temporary storage on the
> >stack or registers.
> 
> Yes, this is not something that can be solved just at the C library
> level.  It's a big problem, that requires OS and compiler support
> (and maybe even hardware support).  See, for example, Anikeev et
> al's paper on secure garbage collection
> <http://dx.doi.org/10.1016/j.jisa.2014.10.001> or Chow et al's
> classic paper on shredding one's garbage <https://www.usenix.org/legacy/event/sec05/tech/full_papers/chow/chow_html/>.
> <http://dx.doi.org/10.1016/j.jisa.2014.10.001>
> 
> By the way, shouldn't one set memory to a random bitpattern rather
> than simply clearing it?
> <http://dx.doi.org/10.1016/j.jisa.2014.10.001>

Only if you also wrap your device in tinfoil. Seriously, these
measures are about preventing information disclosure in the event of
subsequent compromise of the process (or possibly even normal behavior
following setuid() to drop privs), not defending against physical
attacks to recover previous state of memory/disks. If you agree with
my assessment of the scope, it's solvable purely at the compiler level
without any special OS or hardware level support. This is because you
don't have to ensure that the information is fully destroyed, just
that the process can no longer access it, and you get to assume all
the normal kernel- and hardware-enforced access controls apply.

Rich