Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLuo8NrhowJVTxLq-GX0eBrL+c2Tyd4k5TbHP5eEG0oFA@mail.gmail.com>
Date: Fri, 13 Jan 2017 14:04:58 -0800
From: Kees Cook <keescook@...omium.org>
To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Cc: PaX Team <pageexec@...email.hu>, "AKASHI, Takahiro" <takahiro.akashi@...aro.org>, 
	Mark Rutland <mark.rutland@....com>, park jinbum <jinb.park7@...il.com>
Subject: Re: Introduction

On Fri, Jan 13, 2017 at 1:57 PM, Daniel Micay <danielmicay@...il.com> wrote:
> On Fri, 2017-01-13 at 11:06 -0800, Kees Cook wrote:
>> On Fri, Jan 13, 2017 at 10:51 AM, PaX Team <pageexec@...email.hu>
>> wrote:
>> > On 13 Jan 2017 at 9:54, Kees Cook wrote:
>> >
>> > > PaX Team, the heuristic for STRUCTLEAK appears to be "does the
>> > > struct
>> > > contain anything marked __user". Is this actually a meaningful
>> > > information exposure case? It seems like there are a lot more
>> > > cases
>> > > for exposures where there is nothing marked __user. Is that the
>> > > meaning of "much smaller coverage" compared to STACKLEAK in the
>> > > Kconfig?
>> >
>> > STRUCTLEAK was written in response to a particular bug a few years
>> > ago
>> > where we didn't want to give the bug away but still wanted to fix it
>> > during the embargo. the struct in question could be matched by this
>> > heuristics, matching everything else (however little of it) is
>> > really
>> > just a free side effect. could coverage be improved? of course but
>> > that
>> > would take a whole lot more work (manual markups and/or data flow
>> > analysis
>> > in LTO mode).
>>
>> Out of curiosity, do you remember which bug? I'd be curious to compare
>> it against others. It seems like adding structleak to upstream still
>> has value, even if the coverage isn't as complete as stackleak.
>
> There's the performance-oblivious approach of zeroing all locals early
> in the compiler pipeline and relying on compiler optimizations to remove
> it when it's not required. They're already pretty good at doing it.

Yeah, I think that's what happens here. Some initializations are seen
as constructors still, while others are marked as SSAs already.
Hopefully the optimization pass will correctly collapse the cases.

-Kees

-- 
Kees Cook
Nexus Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.