From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8483 Path: news.gmane.org!not-for-mail From: Zack Weinberg Newsgroups: gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel,gmane.linux.lib.musl.general Subject: Re: [musl] Compiler support for erasure of sensitive data Date: Wed, 9 Sep 2015 14:48:22 -0400 Message-ID: <55F07EF6.8080004@panix.com> References: <55F05FF1.3000405@panix.com> <20150909164228.GD17773@brightrain.aerifal.cx> <20150909171337.GH17773@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1441824538 3075 80.91.229.3 (9 Sep 2015 18:48:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 18:48:58 +0000 (UTC) Cc: gcc@gcc.gnu.org, GNU C Library , musl@lists.openwall.com To: Rich Felker Original-X-From: libc-alpha-return-63084-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 09 20:48:52 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZkQ6-0006jR-K8 for glibc-alpha@plane.gmane.org; Wed, 09 Sep 2015 20:48:34 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=WD49FXt5KDUxfYwU eRHQIJSNMHGga3m/RBVFSzBNQAtZNN3vl+gllcD1TcAcO1aRk+URCo/r5BmUvA4u pHILMyFd3DMQr1Z/Dt08mjDX+kBid6mWoUdoBjAwoZYFrMTFyccAB+69nJe3eobK 3u43Bx9pziOSLNi4SDRHvYX7F9w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=IA53VsAAwGKY09FSIFZFTQ FwuQM=; b=aIU0D7k6nVsQ4nVjMgdxlI8mPbVLnogleHkSEdKyvcZNiYXcx01JyC 3copyBQgzS5HzcQtRs6Rk6RsSFa7fJaOH2qQcL6RLXF8Pz5eeXl8wX2W5ZpzHJfz 09i+8bAFTJUgRgPAurKnEm0zlx9iVhQSFw72kTBDRNvPKqG5CKFK4= Original-Received: (qmail 115027 invoked by alias); 9 Sep 2015 18:48:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 114995 invoked by uid 89); 9 Sep 2015 18:48:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_BLACK autolearn=no version=3.3.2 X-HELO: mail-qg0-f54.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=O25i99Q2r7kempmkip6tc8JLbF5bvIyTVftiB88AJYI=; b=X+fi1XK/5Hnrd80QKK3DvaS5aIpvZ7mJoXsCgB9f45jMwkek6k35q2PXRZwtkTTPc0 eWiUEV8CGbf19egE/A+UdmQA9l3GW+cAE1CINsMup4+/8Wx24Bw/8NxuHbwGH/QZ6UK2 NMsIXqmGuKPlhy6mEoCqh25F7USTY/jZ4ml0a0Pb5HS2WKPMV9q1s03AlsOFFcwGU6tb 14tDW1z29BRWta3z8I0OrKlqRU8sckUKAivxJXbOkP4gR6A0av2K3c5T2f/bDr2GcMTn lj7Hjbk7L7k2FoVVEbFILKxWk1/kJ+9sooElXA8Uz12v4un0o76cEbPRBQiNx35+g5+e Voog== X-Received: by 10.140.81.208 with SMTP id f74mr46171009qgd.69.1441824504967; Wed, 09 Sep 2015 11:48:24 -0700 (PDT) X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 In-Reply-To: <20150909171337.GH17773@brightrain.aerifal.cx> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55364 gmane.comp.gcc.devel:141217 gmane.linux.lib.musl.general:8483 Archived-At: 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. > 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. zw