From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8486 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy 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 22:26:54 +0200 Message-ID: <20150909202654.GO28959@port70.net> References: <55F05FF1.3000405@panix.com> <55F08296.10003@panix.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441830449 8366 80.91.229.3 (9 Sep 2015 20:27:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 20:27:29 +0000 (UTC) Cc: Paul_Koning@Dell.com, dje.gcc@gmail.com, gcc@gcc.gnu.org, libc-alpha@sourceware.org, musl@lists.openwall.com To: Zack Weinberg Original-X-From: libc-alpha-return-63089-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 09 22:27:27 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 1ZZlxO-0005Vb-Ug for glibc-alpha@plane.gmane.org; Wed, 09 Sep 2015 22:27:03 +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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=GJpX 2/zPNz9SJPERkYvyCI55Tep0KCvM1M/dRR8gBwiYx7loyKORoFYly9Q2kHl8RZhd fw+MDdAL4axdKTeB8KgMsjieeLGuKWbc1BATTclSiFF8rVzenhxvIblIq7hnUr/m a8tz98CnoYPBda/1X4Q+Ub1RUCJX9LzjcL9MJPY= 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:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=wbrlChg0K2 sGAapFVlxy/AcdCuA=; b=yD3hcRv4CMYmY/1sayYRn/Y4CzxPLThNXeC7G62E4O oE+stlK9xpERM29CFInAI5vE5jZORmb8TAqn+zdis24XMATRbT/I3zw1lRDULvHl o/66lEd2iwyBRPP0StKaseJ5iUjUpVDwe3NIzCOb8KoHLtJVsr+NcMmsGSYnbf35 M= Original-Received: (qmail 1042 invoked by alias); 9 Sep 2015 20:26:59 -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 1031 invoked by uid 89); 9 Sep 2015 20:26:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: port70.net Mail-Followup-To: Zack Weinberg , Paul_Koning@Dell.com, dje.gcc@gmail.com, gcc@gcc.gnu.org, libc-alpha@sourceware.org, musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <55F08296.10003@panix.com> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55369 gmane.comp.gcc.devel:141222 gmane.linux.lib.musl.general:8486 Archived-At: * Zack Weinberg [2015-09-09 15:03:50 -0400]: > On 09/09/2015 02:02 PM, Paul_Koning@Dell.com wrote: > >> On Sep 9, 2015, at 1:54 PM, David Edelsohn > >> wrote: > >> > >> 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? > > I *assume* David is referring to register renaming, which is not > architecturally visible... > or async signal handler copying all the register state on sigaltstack or internal counters and debug features making sensitive info observable or timing/cache-effect side channels that let other processes get info or compiling to a highlevel language (js) with different kind of leaks or running under emulator/debugger that can make secrets visible or... > I would consider data leaks via state inaccessible to a program > executing at the same privilege level as the code to be hardened to be > out of scope. (Which does mean that *when hardening an OS kernel* one specifying the info leak at the abstract c machine level is not useful (the memset is not observable there, unless you assign meaning to undefined behaviour which is a can of worms), but you do have to specify the leak on some abstraction level (that is applicable to the targets of a compiler and gives useful security properties in practice) otherwise the attribute is not meaningful. leaks can happen for many reasons that are layers below the control of the compiler, but still observable by high level code.