From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74801-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 46010 invoked by alias); 16 Nov 2016 14:56:37 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 45991 invoked by uid 89); 16 Nov 2016 14:56:36 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=won
X-HELO: mail-qk0-f196.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:to:references:cc:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-transfer-encoding;
        bh=WDKWHF/14vxVcLKlkdmr70T9lYLOF8Nvet78/kC3ZCw=;
        b=F+488D3dy2d84Esp+Xd3PXMf4Pi+MXVmFNXT9jj699GhmtLsN/HgyZCrrgDsVJRPS/
         5O1pT/HVksEFvpnyApMQJTBwAgLC69aqOJmu5Kmm87YbVaRze8e9pBL6zwuOEIkF1zFU
         kmtDJGZ+ylk6bWskcvDkCrp5R7IXxX4X8d5CE8y0/PK/w7WOk3aBfFdT3+7ccx7P5cpn
         GVH3PbqenTyi696xqtuHwJQsGdtAxnMy5kbkDiYXx91KfUKkst5r+0O6IeHh245llaH2
         eQbecxc5d4QwzJNOR69a/gHr3UOoVvZoWRpy1OPbxFlU0QVY+CKlA8UgyaUcURvWLFeZ
         wTJg==
X-Gm-Message-State: AKaTC006xK6oG+it4ZAJXG0wPW/DAd2zgD++WXPeKOlHVpmBSWN8PI7uy45H4MxPrvz0fA==
X-Received: by 10.55.23.213 with SMTP id 82mr3689049qkx.40.1479308193390;
        Wed, 16 Nov 2016 06:56:33 -0800 (PST)
Subject: Re: [PATCH 0/3] explicit_bzero v5
To: Paul Eggert <eggert@cs.ucla.edu>, Florian Weimer <fweimer@redhat.com>
References: <20161115155509.12692-1-zackw@panix.com>
 <677c23f1-d10a-890d-b875-039d32a3d228@cs.ucla.edu>
 <CAKCAbMhHRH-+ZV7sChor3Xdt5TNqNmwqAcfgYMPsCZBB8jOJBA@mail.gmail.com>
 <03bf455b-7dc9-663b-a748-8f1da9cfcfd3@cs.ucla.edu>
 <388972da-c60c-6314-b39d-db5fc818fdb8@redhat.com>
 <CAKCAbMg+=K4ix28_wTEdAtPhr2PC5HHELvTeaHSJCKHTPScu6g@mail.gmail.com>
 <b3064916-a082-9bb3-8715-9252d1fdecae@cs.ucla.edu>
Cc: GNU C Library <libc-alpha@sourceware.org>,
 Carlos O'Donell <carlos@redhat.com>,
 "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
From: Zack Weinberg <zackw@panix.com>
Message-ID: <545c2830-c00c-7eb9-65c0-cb8042a5069d@panix.com>
Date: Wed, 16 Nov 2016 14:56:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Icedove/45.4.0
MIME-Version: 1.0
In-Reply-To: <b3064916-a082-9bb3-8715-9252d1fdecae@cs.ucla.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SW-Source: 2016-11/txt/msg00554.txt.bz2

On 11/15/2016 02:35 PM, Paul Eggert wrote:
> On 11/15/2016 10:54 AM, Zack Weinberg wrote:
>> If the adversary can read the stack at all, I suspect they've
>> already won, no matter what we do.
> 
> That will likely be true in many applications, but not in all.

I doubt that very much.  An adversary who can read the stack has access
to at least one pointer into the executable image (i.e. a return
address) and that is sufficient to walk the entire address space,
including all static data and the complete contents of the heap.

> It's worth documenting the issue for applications that put sensitive
> objects in the heap, as they might not expose these object addresses
> to the stack now

How on earth are they to operate on sensitive objects on the heap
without holding their addresses in function-local variables, which one
must assume do from time to time get spilled onto the stack?

zw