From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8707
Path: news.gmane.org!not-for-mail
From: Denys Vlasenko <vda.linux@googlemail.com>
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: Thu, 22 Oct 2015 18:09:31 +0200
Message-ID: <CAK1hOcMx+ibdoEE95h2R5+y6Znf1S4X0cSq-s3Nv+cuRk5-DuA@mail.gmail.com>
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=UTF-8
X-Trace: ger.gmane.org 1445530229 19682 80.91.229.3 (22 Oct 2015 16:10:29 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 22 Oct 2015 16:10:29 +0000 (UTC)
Cc: gcc@gcc.gnu.org, llvmdev@cs.uiuc.edu, 
	GNU C Library <libc-alpha@sourceware.org>
To: musl <musl@lists.openwall.com>
Original-X-From: musl-return-8719-gllmg-musl=m.gmane.org@lists.openwall.com Thu Oct 22 18:10:17 2015
Return-path: <musl-return-8719-gllmg-musl=m.gmane.org@lists.openwall.com>
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 <musl-return-8719-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1ZpIRJ-0005Vb-0H
	for gllmg-musl@m.gmane.org; Thu, 22 Oct 2015 18:10:05 +0200
Original-Received: (qmail 5313 invoked by uid 550); 22 Oct 2015 16:10:03 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
Original-Received: (qmail 5290 invoked from network); 22 Oct 2015 16:10:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        bh=qv2ZPqX8mLfK8YAAW1sIXjnYM9fISv6UmAdJTgVtdj0=;
        b=oC+z+8hdI0LcmKIeEAOPOb6tRGCLVqfkv94XzRE2hjdNJuYIuhlUI3eL71Hj7JQbDj
         RRlCpRXhM3IlEesR5GoTKttw2nBTqDwR0hV8t0MWmoD9nEbLPW13ZmgII9Y4ielUutNs
         QymlVjR9Bhqw9M6anpEW61PjPHW94j6RiEBMWBPy6B7jQ9f2tCZmdXzwmbVJRsLMeRdA
         82dDrsXxy49LP+QJR1oLO4I8oJbIk87WJwNK6iSo5y3mjU7gNu8wSMBG4myyh3myCCsf
         l2qo5NXbV/hZ/PGKllpdWswHrfwOPc3+/qn7js2oeYIzL+oQxhQlmRXI7G5ct6kCzka1
         IeAg==
X-Received: by 10.140.233.130 with SMTP id e124mr20566593qhc.79.1445530190685;
 Thu, 22 Oct 2015 09:09:50 -0700 (PDT)
In-Reply-To: <55F05FF1.3000405@panix.com>
Xref: news.gmane.org gmane.linux.lib.musl.general:8707 gmane.comp.gcc.devel:141628 gmane.comp.lib.glibc.alpha:56711
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/8707>

On Wed, Sep 9, 2015 at 6:36 PM, Zack Weinberg <zackw@panix.com> 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.

How valuable is that speedup due to possible inlining?

You know, call instruction is not a crime.
In fact, it is *heavily* optimized on any CPU exactly because
calls happen gazillion times every second.

In my measurement, on x86 call+ret pair is cheaper than
a single read-modify-write ALU op on L1 data item!

So, just implement explicit_bzero() as a function which
is prohibited from inlining, and which clears all call-clobbered
registers in addition to clearing memory.

This will probably also be the smallest solution code size wise.