[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJt7Kc9eH+=a11=ewem1E0GDo4+tu48OWGQ67Tu7fJfLA@mail.gmail.com>
Date: Fri, 13 Jan 2017 11:06:08 -0800
From: Kees Cook <keescook@...omium.org>
To: PaX Team <pageexec@...email.hu>
Cc: "AKASHI, Takahiro" <takahiro.akashi@...aro.org>, Mark Rutland <mark.rutland@....com>,
park jinbum <jinb.park7@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Introduction
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.
I wanted to do some simple performance checks with it too. I imagine
it wouldn't have much impact given its coverage isn't very wide.
-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.
