On Mon, May 8, 2017 at 7:02 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Kees Cook <keescook@xxxxxxxxxxxx> wrote: > >> > 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/ >> [...] 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. >> [...] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
