Messages in this thread |  | | Date | Fri, 13 Dec 2013 14:27:53 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/9] Known exploit detection |
| |
* Vegard Nossum <vegard.nossum@oracle.com> wrote:
> On 12/12/2013 10:13 PM, Kees Cook wrote: > > > I like it. I like how lightweight it is, and I like that it can be > > trivially compiled out. My concerns would be: > > > > - how do we avoid bikeshedding about which exploits are "serious > > enough" to trigger a report? > > Well, I've already suggested that only bugs that potentially lead to > privilege escalation/intrusion (local and remote) would be > candidates. This probably includes any kind of buffer overflow or > "wild write" bug.
It's also up to the maintainer of the subsystem, so bikeshedding is only as effective as the maintainer allows it to be.
> Clearly, a bug should also be present over a complete release cycle > before it's worth annotating. [...]
Yes, only bugs present in a released kernel are candiates.
> [...] A bug introduced in -rc1 and fixed in -rc5 is NOT a candidate.
That's generally true, except perhaps in the special case if a bug got backported and released in a stable kernel, and some good exploit got released for that bug. In that case checking it is useful.
The point is that we want to check things that have a chance to result in actual messages: i.e. deterministically triggerable bugs in released kernel that are either trivially exploitable or are known to be exploited in exploit kits.
Thanks,
Ingo
|  |