This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [musl] Compiler support for erasure of sensitive data
- From: Rich Felker <dalias at libc dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: gcc at gcc dot gnu dot org, GNU C Library <libc-alpha at sourceware dot org>, musl at lists dot openwall dot com
- Date: Wed, 9 Sep 2015 16:05:31 -0400
- Subject: Re: [musl] Compiler support for erasure of sensitive data
- Authentication-results: sourceware.org; auth=none
- References: <55F05FF1 dot 3000405 at panix dot com> <20150909164228 dot GD17773 at brightrain dot aerifal dot cx> <CAKCAbMjpOAzS-vHfy27BxHikUeaRziZ1hhmWLX_F2Gt9ajgE7g at mail dot gmail dot com> <20150909171337 dot GH17773 at brightrain dot aerifal dot cx> <55F07EF6 dot 8080004 at panix dot com>
On Wed, Sep 09, 2015 at 02:48:22PM -0400, Zack Weinberg wrote:
> On 09/09/2015 01:13 PM, Rich Felker wrote:
> > On Wed, Sep 09, 2015 at 12:47:10PM -0400, Zack Weinberg wrote:
> >> On Wed, Sep 9, 2015 at 12:42 PM, Rich Felker <dalias@libc.org> wrote:
> >>> You're making this harder than it needs to be. The "m" constraint is
> >>> the wrong thing to use here. Simply use:
> >>>
> >>> __asm__(""::"r"(ptr):"memory");
> >>
> >> Please review my earlier conversation with Adhemerval on exactly this point.
> >
> > My understanding is that you consider this a "big hammer". Does that
> > really matter if the intent is that it only be used in isolated,
> > sensitive contexts? Are you just unhappy with the performance cost, or
> > concerned that the clobber will cause more spilling of sensitive data?
>
> Please review *all* of my earlier conversation with Adhemerval, in
> particular the bit where I compiled libressl three different ways and
> analyzed the assembly dumps. I'm sure there's more to be said on the
> topic, but *starting* from there.
OK, sorry for jumping back in without the full context.
> > the hack with the "m" constraint is wrong and easily fixed
>
> It's not wrong; it is in fact the documented way to express a fixed-size
> read access to one block of memory. Look for "ten bytes of a string"
> within https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Extended-Asm.html
> (sorry, there don't appear to be anchors).
>
> It merely doesn't work in C++, with Clang, or (maybe) with a block of
> memory whose size cannot be determined at compile time.
It relies on structs containing VLAs which are not standard C nor
supported by any "GNU C" compilers except GCC. And features like this
tend to be really fragile even in GCC because nobody uses them (for
good reason -- they can't be expected to work except on certain GCC
versions). You can disagree if you like, but that's why I called it
"wrong".
Rich