From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8485 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.lib.glibc.alpha Subject: Re: Compiler support for erasure of sensitive data Date: Wed, 9 Sep 2015 16:05:31 -0400 Message-ID: <20150909200531.GL17773@brightrain.aerifal.cx> References: <55F05FF1.3000405@panix.com> <20150909164228.GD17773@brightrain.aerifal.cx> <20150909171337.GH17773@brightrain.aerifal.cx> <55F07EF6.8080004@panix.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441829175 16253 80.91.229.3 (9 Sep 2015 20:06:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 20:06:15 +0000 (UTC) Cc: gcc@gcc.gnu.org, GNU C Library , musl@lists.openwall.com To: Zack Weinberg Original-X-From: musl-return-8497-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 09 22:06:07 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZZld3-0000pj-OZ for gllmg-musl@m.gmane.org; Wed, 09 Sep 2015 22:06:01 +0200 Original-Received: (qmail 7808 invoked by uid 550); 9 Sep 2015 20:05:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7787 invoked from network); 9 Sep 2015 20:05:54 -0000 Content-Disposition: inline In-Reply-To: <55F07EF6.8080004@panix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8485 gmane.comp.gcc.devel:141221 gmane.comp.lib.glibc.alpha:55368 Archived-At: 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 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