From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8474 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 12:42:28 -0400 Message-ID: <20150909164228.GD17773@brightrain.aerifal.cx> References: <55F05FF1.3000405@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 1441816991 5121 80.91.229.3 (9 Sep 2015 16:43:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 16:43:11 +0000 (UTC) Cc: gcc@gcc.gnu.org, llvmdev@cs.uiuc.edu, GNU C Library , musl@lists.openwall.com To: Zack Weinberg Original-X-From: musl-return-8484-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 09 18:42:55 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 1ZZiST-0005My-Kl for gllmg-musl@m.gmane.org; Wed, 09 Sep 2015 18:42:53 +0200 Original-Received: (qmail 11976 invoked by uid 550); 9 Sep 2015 16:42:52 -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 11935 invoked from network); 9 Sep 2015 16:42:52 -0000 Content-Disposition: inline In-Reply-To: <55F05FF1.3000405@panix.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8474 gmane.comp.gcc.devel:141203 gmane.comp.lib.glibc.alpha:55353 Archived-At: On Wed, Sep 09, 2015 at 12:36:01PM -0400, Zack Weinberg wrote: > The first, simpler problem is strictly optimization. explicit_bzero > can be optimized to memset followed by a vacuous use of the memory > region (generating no machine instructions, but preventing the stores > from being deleted as dead); this is valuable because the sensitive > data is often small and fixed-size, so the memset can in turn be > replaced by inline code. (This also facilitates implementation of > -D_FORTIFY_SOURCE checks for explicit_bzero.) Again looking at > libressl, 92 of those 152 uses are improved by a crude version of this > optimization: > > void explicit_bzero(void *, size_t); > extern inline __attribute__((gnu_inline, always_inline)) > void explicit_bzero_constn(void *ptr, size_t len) > { > typedef struct {char x[len];} memblk; > memset(ptr, 0, len); > asm("" : : "m" (*(memblk __attribute__((may_alias)) *)ptr)); > } > #define explicit_bzero(s, n) \ > (__extension__(__builtin_constant_p(n) && (n) > 0 \ > ? explicit_bzero_constn(s, n) \ > : explicit_bzero(s, n))) > > I call this "crude" because it only works in GCC, when compiling C, > and when the length parameter is compile-time constant. GCC issues no > error for this code when 'len' is not compile-time constant, but it is > not documented to work reliably. When compiling C++, GCC does not > accept a structure containing an array whose size is not *lexically* > constant; even if the body of explicit_bzero_constn is moved into the > macro so that the whole thing is guarded by __builtin_constant_p, > using explicit_bzero with a non-constant size will cause a compile > error. The same is true for Clang whether compiling C or C++. > > This problem could be solved with a very simple feature addition: > > extern inline __attribute__((gnu_inline, always_inline)) > void explicit_bzero(void *ptr, size_t len) > { > memset(ptr, 0, len); > __builtin_use_memory(ptr, len); > } 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"); The memory constraint implies that the asm can read or write any memory that's reachable by it. The lack of output constraints implies __volatile__ which is also needed. Rich