On Mon, May 8, 2017 at 7:02 AM, Ingo Molnar [off-list ref] wrote:

* Kees Cook [off-list ref] wrote:

quoted

quoted

And yes, I realize that there were other such bugs and that such bugs might
occur in the future - but why not push the overhead of the security check to
the kernel build phase? I.e. I'm wondering how well we could do static
analysis during kernel build - would a limited mode of Sparse be good enough
for that? Or we could add a new static checker to tools/, built from first
principles and used primarily for extended syntactical checking.

Static analysis is just not going to cover all cases. We've had vulnerabilities
where interrupt handlers left KERNEL_DS set, for example. [...]

Got any commit ID of that bug - was it because a function executed by the
interrupt handler leaked KERNEL_DS?

Ah, it was an exception handler, but the one I was thinking of was this:
https://lwn.net/Articles/419141/

quoted

[...] If there are performance concerns, let's put this behind a CONFIG. 2-5
instructions is not an issue for most people that want this coverage.

That doesn't really _solve_ the performance concerns, it just forces most people
to enable it by creating a 'security or performance' false dichotomy ...

That's fair, but what I'm trying to say is that many people will want
this, so rejecting it because it's 2 more instructions seems
unreasonable. We have had much more invasive changes added to the
kernel.

quoted

[...] and it still won't catch everything. Bug-finding is different from making
a bug class just unexploitable at all. As we've done before, it's the difference
between trying to find format string attacks vs just removing %n from the format
parser.

No, it does not make it unexploitable, it could still be exploitable if the
runtime check is buggy or if there's kernel execution outside of the regular
system call paths - there's plenty of such hardware functionality on x86 for
example.

Fine, but this is splitting hairs. This does protect a specific
situation, and it does so very cheaply. The real fix would be to
remove set_fs() entirely. :P

-Kees

-- 
Kees Cook
Pixel Security