Date: Mon, 08 May 2017 11:22:12 -0400 From: Daniel Micay <danielmicay@...il.com> To: Ingo Molnar <mingo@...nel.org>, Thomas Garnier <thgarnie@...gle.com> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>, Heiko Carstens <heiko.carstens@...ibm.com>, Dave Hansen <dave.hansen@...el.com>, Arnd Bergmann <arnd@...db.de>, Thomas Gleixner <tglx@...utronix.de>, David Howells <dhowells@...hat.com>, René Nyffenegger <mail@...enyffenegger.ch>, Andrew Morton <akpm@...ux-foundation.org>, "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, "Eric W . Biederman" <ebiederm@...ssion.com>, Oleg Nesterov <oleg@...hat.com>, Pavel Tikhomirov <ptikhomirov@...tuozzo.com>, Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Rik van Riel <riel@...hat.com>, Kees Cook <keescook@...omium.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Borislav Petkov <bp@...en8.de>, Brian Gerst <brgerst@...il.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Christian Borntraeger <borntraeger@...ibm.com>, Russell King <linux@...linux.org.uk>, Will Deacon <will.deacon@....com>, Catalin Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>, James Morse <james.morse@....com>, linux-s390 <linux-s390@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, the arch/x86 maintainers <x86@...nel.org>, linux-arm-kernel@...ts.infradead.org, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl> Subject: Re: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode On Mon, 2017-05-08 at 09:52 +0200, Ingo Molnar wrote: > > ... it's just not usable in that form for a regular maintenance flow. > > So what would be more useful is to add a specific Sparse check that > only checks > KERNEL_DS, to add it as a regular (.config driven) build option and > make sure the > kernel build has zero warnings. > > From that point on we can declare that this kind of bug won't occur > anymore, if > the Sparse implementation of the check is correct. > > But there's a (big) problem with that development model: Sparse is not > part of the > kernel tree and adding a feature to it while making the kernel depend > on that > brand new feature is a logistical nightmare. The overhead is quite > similar to > adding new features to a compiler - it happens at a glacial pace and > is only done > for major features really, at considerable expense. I don't think this > is an > adequate model for 'extended syntax checking' of the kernel, > especially when it > comes to correctness that has such obvious security impact. > > Thanks, > > Ingo There's the option of using GCC plugins now that the infrastructure was upstreamed from grsecurity. It can be used as part of the regular build process and as long as the analysis is pretty simple it shouldn't hurt compile time much. The problem with doing that is I don't think there are people with much experience with GCC contributing upstream and it's going to be more work to develop/maintain than some kind of specialized DSL for analysis. I think a few static analysis plugins are used as part of maintaining grsecurity for solving issues like finding false positives for the REFCOUNT overflow checking feature, so it's something that's already being done in practice elsewhere.
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.