[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJog1M5B9O7rO9rk-Rsfd+9avcGuAz=Tmq+CVU3n+5fzA@mail.gmail.com>
Date: Fri, 13 Jan 2017 11:26:42 -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 11:06 AM, Kees Cook <keescook@...omium.org> 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.
>
> 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.
I did notice too that it seems like it doesn't notice static initializers:
security/tomoyo/common.c: In function ‘tomoyo_load_builtin_policy’:
security/tomoyo/common.c:2745:27: note: userspace variable will be
forcibly initialized
struct tomoyo_io_buffer head = { };
^
fs/read_write.c: In function ‘new_sync_write’:
fs/read_write.c:490:15: note: userspace variable will be forcibly initialized
struct iovec iov = { .iov_base = (void __user *)buf, .iov_len = len };
^
-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.
