From: Rich Felker <dalias@libc.org>
To: Zack Weinberg <zackw@panix.com>
Cc: gcc@gcc.gnu.org, GNU C Library <libc-alpha@sourceware.org>,
musl@lists.openwall.com
Subject: Re: Compiler support for erasure of sensitive data
Date: Wed, 9 Sep 2015 16:05:31 -0400 [thread overview]
Message-ID: <20150909200531.GL17773@brightrain.aerifal.cx> (raw)
In-Reply-To: <55F07EF6.8080004@panix.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
next prev parent reply other threads:[~2015-09-09 20:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 16:36 Zack Weinberg
2015-09-09 16:39 ` Fwd: " Zack Weinberg
2015-09-09 16:41 ` Zack Weinberg
2015-09-09 16:42 ` Rich Felker
2015-09-09 16:47 ` [musl] " Zack Weinberg
2015-09-09 17:13 ` Rich Felker
2015-09-09 18:48 ` [musl] " Zack Weinberg
2015-09-09 20:05 ` Rich Felker [this message]
2015-09-09 16:52 ` Paul_Koning
2015-09-09 16:58 ` Zack Weinberg
2015-09-09 17:25 ` [musl] " Rich Felker
2015-09-09 17:54 ` David Edelsohn
2015-09-09 18:02 ` Paul_Koning
2015-09-09 18:11 ` David Edelsohn
2015-09-09 19:03 ` Zack Weinberg
2015-09-09 20:26 ` Szabolcs Nagy
2015-10-22 16:02 ` [musl] " Denys Vlasenko
2015-10-22 16:09 ` Denys Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150909200531.GL17773@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=musl@lists.openwall.com \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).