[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1494256932.1167.1.camel@gmail.com>
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.
