From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8481 Path: news.gmane.org!not-for-mail From: 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: Wed, 9 Sep 2015 18:02:06 +0000 Message-ID: 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="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441821774 21718 80.91.229.3 (9 Sep 2015 18:02:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 18:02:54 +0000 (UTC) Cc: , , , To: Original-X-From: musl-return-8493-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 09 20:02:39 2015 Return-path: 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 ) id 1ZZjhU-0001lr-8z for gllmg-musl@m.gmane.org; Wed, 09 Sep 2015 20:02:28 +0200 Original-Received: (qmail 29703 invoked by uid 550); 9 Sep 2015 18:02:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28598 invoked from network); 9 Sep 2015 18:02:21 -0000 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=V7KE5Ug7nuT8TSz98E7eOeoL9EY8iKon3rvd+Ir3Fh8H8kcgHuKXMz/i STYBf/P9sMJ5QswFxiKgxFUHJF7RnwINd+6FiQdBwGj/mUve8wSQOgDl8 sZ40NMz/SUT6RlAb3KP/3DMyTVq/WdE/+WZIgTY7mU7qJcY1w82omsJMs I=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1441821741; x=1473357741; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cdBtNzER+4W8fqsApvjvYoS/VvonTpPcdPWHSfsp+zs=; b=ONEl9yadVDVTn8Pmqq+S3qXBabTBCHBZMS9wuav+EWBZWNdw0DX0tx+5 VdCVkp842Y49mMB9OoqGTuZG6mWvgiBiWBNyQXLQ4TzaIBjQlGfJwU+7U tpHfRL30t4c8BxdaE+HQEsnYjDnl7Q25+B/MSJBLxtoBSu7c5IVGpGHLW s=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.17,497,1437454800"; d="scan'208";a="216184451" Thread-Topic: Compiler support for erasure of sensitive data Thread-Index: AQHQ6x3FI/675Ei2eEm4ldvt+PMkyZ40zsYAgAACFgA= In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.68] Content-ID: Xref: news.gmane.org gmane.linux.lib.musl.general:8481 gmane.comp.gcc.devel:141214 gmane.comp.lib.glibc.alpha:55362 Archived-At: > On Sep 9, 2015, at 1:54 PM, David Edelsohn wrote: >=20 > On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg wrote: >=20 >> 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. >=20 >> 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. >=20 > 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. 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 fi= le, or a debugger. With an explicitly stated list of goals and non-goals w= e can see whether a proposed solution addresses all, part, or none of the p= roblem space, and whether it is a small solution or one much more powerful = than is actually requested. If the threat is indeed delayed process state examination in software, then= I think your "dangerously naive" does not apply. If you're talking excava= ting the chip and doing quantum forensics, that's a different matter. 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 switch= ing, copies of stuff in the page file or in now-freed memory pages, or thin= gs like that. =20 paul