From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16255 invoked by alias); 16 Dec 2016 18:26:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 16231 invoked by uid 89); 16 Dec 2016 18:26:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=feed, intend, unacceptable, sitting X-HELO: mx1.redhat.com Subject: Re: [PATCH] explicit_bzero final To: Zack Weinberg References: <20161212230622.14045-1-zackw@panix.com> <96232743-345c-5126-e526-9a8aadc4fdb7@redhat.com> <2e51eedf-874e-cb81-79a6-0a0c667371db@redhat.com> <65af2074-e961-9c4a-836a-4a736b49d6e2@panix.com> Cc: Florian Weimer , GNU C Library , Joseph Myers , Adhemerval Zanella , Wilco Dijkstra From: Jeff Law Message-ID: <6a5179d4-fe8c-a101-380a-88c3ad94684d@redhat.com> Date: Fri, 16 Dec 2016 18:26:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <65af2074-e961-9c4a-836a-4a736b49d6e2@panix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-12/txt/msg00630.txt.bz2 On 12/15/2016 04:21 PM, Zack Weinberg wrote: >> >> Right. Just to correct a bit on terminology, it's not spilled to the >> stack, but the object has to be addressable due to the call to >> explicit_bzero. That forces the object into the stack. It might still >> wind up in the stack due to other reasons (it's an aggregate and thus >> not subject to live in registers). > > Right. I suspect that sensitive data objects pretty much always wind up > in memory anyway, but people _were_ really worried about the case where > explicit_bzero is the only thing that makes one addressable. Agreed on both accounts. > > To be clear, explicit_bzero itself is not going away. It is already in > use in a wide variety of applications, and substitutes (such as the > hypothetical __attribute__((sensitive))) will not become widespread > quickly enough to avoid adding it to glibc. I've been working on this > patch off and on for _two years_, and I picked it up from someone else > who'd given up on the process after roughly that long himself. I fully > intend to commit it in some form tomorrow evening; I consider missing > 2.25 unacceptable. Understood. And my position is that explicit_bzero is inherently flawed. You really need direct compiler support. So while it's not going away and it's an incremental improvement over nothing, it comes with a cost. Namely that some objects which previously weren't addressable become addressable and are now sitting in memory waiting to be extracted. > > What I'd hope we could do with compiler-side smarts is _convert_ > explicit_bzero to __attribute__((sensitive)) or a clobbering assignment > or whatever the most convenient compiler-side representation winds up > being, so that artifacts of glibc's implementation become irrelevant. We can likely infer something passed to explicit_bzero is sensitive and build a web to capture whatever DECLs potentially feed the explicit_bzero. So we convert the fence to the CONSTRUCTOR assignment. That's fine. Then we'd want DSE to eliminate the memset, then recompute addressability. > >> Then you just have to find a way to deal with the argument passing and >> register allocation artifacts, and that's going to be hard I suspect. > > Yeah. But hey, at least it won't involve reload, right? Depends on your target :-) You've also got things like setjmp, caller saves, etc which can stuff registers into memory that you'll want to deal with. But at least the surface is getting smaller. jeff