This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.
- From: Rich Felker <dalias at libc dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 15 Dec 2014 16:38:47 -0500
- Subject: Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.
- Authentication-results: sourceware.org; auth=none
- References: <CAKDKvuzWYf3GcXYs4ED8XLyy58nzmvxRV84xwsKKZjPpVSFQug at mail dot gmail dot com> <20141215173527 dot GJ4574 at brightrain dot aerifal dot cx> <548F52D7 dot 2010401 at cs dot ucla dot edu>
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