[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5879219B.26854.33C60FDB@pageexec.freemail.hu>
Date: Fri, 13 Jan 2017 19:51:07 +0100
From: "PaX Team" <pageexec@...email.hu>
To: "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
Kees Cook <keescook@...omium.org>
CC: 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 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).
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.
