* Kees Cook [off-list ref] wrote:

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?

[...] 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 ...

[...] 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.

Thanks,

	Ingo