From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8479 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.comp.gcc.devel,gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general Subject: Re: [musl] Re: Compiler support for erasure of sensitive data Date: Wed, 9 Sep 2015 13:25:26 -0400 Message-ID: <20150909172526.GK17773@brightrain.aerifal.cx> References: <55F05FF1.3000405@panix.com> <8228C31E-7E1F-478C-9352-3908E6256B2C@dell.com> <55F0653C.9010903@panix.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441819579 17145 80.91.229.3 (9 Sep 2015 17:26:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 17:26:19 +0000 (UTC) Cc: Paul_Koning@Dell.com, gcc@gcc.gnu.org, llvmdev@cs.uiuc.edu, libc-alpha@sourceware.org, musl@lists.openwall.com To: Zack Weinberg Original-X-From: gcc-return-188706-gcg-devel-2=m.gmane.org@gcc.gnu.org Wed Sep 09 19:26:11 2015 Return-path: Envelope-to: gcg-devel-2@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 1ZZj8H-0007OR-DC for gcg-devel-2@plane.gmane.org; Wed, 09 Sep 2015 19:26:05 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe: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=oXM+vY9PzwPgqG5Cl yjdadup4wE7rwJM5oxPiReYqBgGu3OpOylL8+YCd49zCTHD0/4CkO2uaNoyNC7fB 4lLGL20NqEUc9NveEmzPu8Ub+2bxqVw5EtsQxu6EviNHze+fwc3uTh6FnrwWW1un PpsbZxiIkKrmgsi3HSi2zltfpc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe: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=3+poUBaXNwZhctWn0zYTieE Z39Y=; b=bBpq2hQaaIb0QXAGTqDt6dAXafhaKl2tLFL0pKowrnlIZJ574pStnFY ntbs4ZlwCbWnZdHHL/yyZUbTsuTsF7JP3gsilaptNuikHXJClQH9kyaVLUkZH2GA ueAOKEwAV05JJhhMU0wKR3Kd2jQaBEpmBvLs4y625XIJkg4z0Vm0= Original-Received: (qmail 97659 invoked by alias); 9 Sep 2015 17:25:35 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Original-Sender: gcc-owner@gcc.gnu.org Original-Received: (qmail 97641 invoked by uid 89); 9 Sep 2015 17:25:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Original-Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Sep 2015 17:25:34 +0000 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1ZZj7e-0007PP-00; Wed, 09 Sep 2015 17:25:26 +0000 Content-Disposition: inline In-Reply-To: <55F0653C.9010903@panix.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gcc.devel:141212 gmane.comp.lib.glibc.alpha:55360 gmane.linux.lib.musl.general:8479 Archived-At: On Wed, Sep 09, 2015 at 12:58:36PM -0400, Zack Weinberg wrote: > On 09/09/2015 12:52 PM, Paul_Koning@Dell.com wrote: > > Then again, suppose all you had is explicit_bzero, and an annotation > > on the data saying it's sensitive. Can static code analyzers take > > care of the rest? If so, this sort of thing doesn't need to be in > > the compiler. > > The thing that absolutely has to be implemented in the compiler (AFAICT) > is register clearing. I'm undecided as to how *necessary* that is. > There certainly can be a lot of sensitive data in registers (e.g. AESNI > puts an entire AES key schedule in xmm registers). I don't know of any > exploits that depended on salvaging such data from registers, but I > don't follow exploit research closely. Conceptually you can "clear all registers" by calling an external asm function that clears all non-call-saved registers internally. Hardened implementations of explicit_bzero could even do this. The caller would (or at least should) not save registers whose old contents it does not intend to use again after the call. And of course all the call-saved registers will get restored when the function returns, preventing any leak via them. I agree it's much better if the compiler can do it, but I think the approach I described is a viable hardening technique that's immediately doable. Rich