From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8484 Path: news.gmane.org!not-for-mail From: Zack Weinberg 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 15:03:50 -0400 Message-ID: <55F08296.10003@panix.com> References: <55F05FF1.3000405@panix.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1441825479 18877 80.91.229.3 (9 Sep 2015 19:04:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 19:04:39 +0000 (UTC) Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org, musl@lists.openwall.com To: Paul_Koning@Dell.com, dje.gcc@gmail.com Original-X-From: libc-alpha-return-63085-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 09 21:04:23 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 1ZZkf4-0005fM-5d for glibc-alpha@plane.gmane.org; Wed, 09 Sep 2015 21:04:02 +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:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=XrGGnlGYtqDywmr2 Q+QIPiwXie0rODcx2/5jMSaFDc2nTyJr583FmYj+NQkjkv8UsO0imZFjJ3wE/5iw WCUUM1xf0XdsSp6/7EtRL00/7Kr7nUSoEOLORvJdVbWFHZgw62YHJtC9RUVrtXrO Rwi3Uoyvnm19eM5PdjT62s6wdn8= 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:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=ZaLdQ5L4b9RvlSM2DHT2hP RlEf4=; b=YsO/uUfKoAltsTvwgcX99wMWhWhzehVAQOQOzicEehx7j00BEKSCbT ML5ARjoJ/+LgJyO/vLiRZH/H8SfwCu8KsSoWFElfysJf1NlCEwHHNTIsrT7iG8/U ME72w0EviNSoC3wfxCrD5drYHH0V7aY6OQpT7MVi3Y1IdF52g6SBg= Original-Received: (qmail 14929 invoked by alias); 9 Sep 2015 19:03:58 -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 14905 invoked by uid 89); 9 Sep 2015 19:03:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qk0-f169.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=g0gNeLbJ0oQE4lJ6QKZMSr5o/gBeEkZaPQ/AWsu+ntk=; b=Ge1PHjcn4STRwFa6ovzvOWhpHYZRZyY+gvqdYTw6jEWf1omJ+QKR0tcFZnGP/Wumke l4SJLSQd37ZiifuEbBq5y/fC9VB0oK5T1wGBk9qMq//og0VkxYgTFSzJ++PKQX5MEMXi yVm8JL5Q1cQhBvsttAOS1OVnfRIUZY1SRf6MqOh2T7weeBcUZFzKdQ3AE/XkyILJmfsT cCpZFTgYkUxfg1rI3Yncew0ncCwdJD7ExGlcdfQc8n8cVklMMc8yVrUZZosxMVQRzG+7 nLnlYYGhtc509JnIz8LSRTD7o3PgOh74T98VNatCV0jJhScmxWQ1rTbLb78x9buwZW4Y IDOA== X-Received: by 10.55.201.198 with SMTP id m67mr46930905qkl.35.1441825433232; Wed, 09 Sep 2015 12:03:53 -0700 (PDT) X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55365 gmane.comp.gcc.devel:141218 gmane.linux.lib.musl.general:8484 Archived-At: 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... ... > I agree it would be good to specify the threat model. Reading > between the lines, I believe it is: capture of the software-visible > process state after the code is finished with the sensitive data, > either via a process dump file, or a debugger. This is correct. Other avenues for the sensitive data to leak include use-after-free or out-of-bounds memory reads within the program, and malicious code (having gained control via some other bug) scanning memory in bulk. 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 would possibly have to worry about special mechanisms that reveal the "true" register file, and the like, but I'd be plenty happy with something that was good enough for user mode.) Techniques involving direct manipulation of the hardware or the microcode, ditto. > Another threat that I don't believe is covered here is disclosure of > copies of the process state held in the OS, like saved context from > thread switching, copies of stuff in the page file or in now-freed > memory pages, or things like that. Some of that might conceivably be in-scope; jmp_buf comes to mind. (I'm not prepared to make an exhaustive list at the moment.) Normally, people programming this kind of code expect to have to lock pages in memory and so on. zw