From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8482 Path: news.gmane.org!not-for-mail From: David Edelsohn Newsgroups: gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel,gmane.linux.lib.musl.general Subject: Re: Compiler support for erasure of sensitive data Date: Wed, 9 Sep 2015 14:11:52 -0400 Message-ID: References: <55F05FF1.3000405@panix.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441822326 30782 80.91.229.3 (9 Sep 2015 18:12:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 18:12:06 +0000 (UTC) Cc: Zack Weinberg , GCC Development , GNU C Library , musl@lists.openwall.com To: Paul_Koning@dell.com Original-X-From: libc-alpha-return-63083-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 09 20:12:05 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 1ZZjqi-00035a-V7 for glibc-alpha@plane.gmane.org; Wed, 09 Sep 2015 20:12:01 +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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; q=dns; s=default; b=l7/gER/Lt+3RpOX4 jv/JDNWKtZlY046LaUEH3ppIQzJN/Af7peZKNqjZvMMzo32wKHUGt6yndoY+5VxH HKJWW1ipqaKs3UxfWc1rX2Y5jMho5YAI84wtD711SDeF1xZwOnhCJnn4hQPh3oQU gyF+ObyaQZFBweMile/ogaPJXmc= 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:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; s=default; bh=wapiQRq/CQ3C33ho6iTu+P 0tTUY=; b=bwQD/V9ao5JjeJReST+qqrYWcMoj8VIO6/UcMb2xKOupseoiUz8y2o Wm8O83sAtKsnzBBwTlAXb5KW7Gj3arQMsSBpo74C8tPBTqiA+Efbq85lmytdabxv uhJ9WcgkXrJr/z/m5PWV+wOEZqoKJj3vhhKEgC6fDsydY3fFjdmrs= Original-Received: (qmail 56977 invoked by alias); 9 Sep 2015 18:11:56 -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 56961 invoked by uid 89); 9 Sep 2015 18:11:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-io0-f176.google.com X-Received: by 10.107.160.194 with SMTP id j185mr10198697ioe.37.1441822312343; Wed, 09 Sep 2015 11:11:52 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55363 gmane.comp.gcc.devel:141215 gmane.linux.lib.musl.general:8482 Archived-At: On Wed, Sep 9, 2015 at 2:02 PM, wrote: > >> On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote: >> >> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote: >> >>> The ABI dictates basically everything you see. The call to >>> explicit_bzero has forced the compiler to *create* a second copy of >>> the variable `k` on the stack, just so it can be erased -- and the >>> copy in registers survives (at least for a short time), which is not >>> what the programmer wanted. With or without explicit_bzero, we have >>> no way of getting rid of the copy in registers. More complicated >>> scenarios of course exist. >> >>> Comments? Please note that I do not have anything like the time >>> required to implement any of this myself (and I'm ten years out of >>> practice on GCC and have no experience whatsoever with Clang, >>> anyway). I'm hoping this catches someone's interest. >> >> What level of erasure of sensitive data are you trying to ensure? >> Assuming that overwriting values in the ISA registers actually >> completely clears and destroys the values is delusionally naive. > > Could you point to some references about that? > >> Most modern hardware architectures have hardware capabilities to >> encrypt and protect sensitive data. > > I'm not sure about "most". I haven't worked on any that could do this. Intel, Power, z/Arch, and (probably) SPARC. > > I agree it would be good to specify the threat model. Reading between th= e lines, I believe it is: capture of the software-visible process state aft= er the code is finished with the sensitive data, either via a process dump = file, or a debugger. With an explicitly stated list of goals and non-goals= we can see whether a proposed solution addresses all, part, or none of the= problem space, and whether it is a small solution or one much more powerfu= l than is actually requested. > > If the threat is indeed delayed process state examination in software, th= en I think your "dangerously naive" does not apply. If you're talking exca= vating the chip and doing quantum forensics, that's a different matter. If this feature is implying / assuring that all values have been irrecoverably destroyed, and one can find the values in physical register files, then one is being dangerously naive in the assertions / expectations about the feature. One must specify the threat model. - David