From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: "Thomas Garnier" <thgarnie@google.com>,
"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
"Dave Hansen" <dave.hansen@intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Thomas Gleixner" <tglx@linutronix.de>,
"David Howells" <dhowells@redhat.com>,
"René Nyffenegger" <mail@renenyffenegger.ch>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
"Eric W . Biederman" <ebiederm@xmission.com>,
"Oleg Nesterov" <oleg@redhat.com>,
"Pavel Tikhomirov" <ptikhomirov@virtuozzo.com>,
"Ingo Molnar" <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Rik van Riel" <riel@redhat.com>,
"Josh Poimboeuf" <jpoimboe@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Brian Gerst" <brgerst@gmail.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Russell King" <linux@armlinux.org.uk>,
"Will Deacon" <will.deacon@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"James Morse" <james.morse@arm.com>,
linux-s390 <linux-s390@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Linux API" <linux-api@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode
Date: Tue, 9 May 2017 08:34:04 +0200 [thread overview]
Message-ID: <20170509063404.pngn4otdmbbrvou3@gmail.com> (raw)
In-Reply-To: <CAGXu5jJ4iY7QZ9wRu5dmm7RHtLh_V6TQh4huWwLCYPKOr63aiA@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> On Mon, May 8, 2017 at 7:02 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Kees Cook <keescook@chromium.org> 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/
Ok, so that's CVE-2010-4258, where an oops with KERNEL_DS set was used to escalate
privileges, due to the kernel's oops handler not cleaning up the KERNEL_DS. The
exploit used another bug, a crash in a network protocol handler, to execute the
oops handler with KERNEL_DS set.
The explanation of the exploit itself points out that it's a very interesting bug
and I agree, it's not a general kernel bug but a bug in a very narrow code path
(oops handling) that caused this, and I don't see how that example can be turned
into a general example: it was a bug in oops handling to let the process continue
execution (and perform the CLEARTID operation) *and* leak the address limit at
KERNEL_DS.
By similar argument a bug in the runtime checking of the address limit may allow
exploits. Consider the oops path cleanup a similarly sensitive code path as the
address limit check.
To handle this category of exploits it would be enough to add a runtime check to
the _oops handling code itself_ (to make sure we've set addr_limit back to USER_DS
even if we crash in a KERNEL_DS code area), not to every system call!
That check would avoid that particular historic pattern, if combined with static
analysis that ensured that KERNEL_DS is always set/restored correctly. (Which btw.
I believe some of the regular static scans of the kernel are already doing today.)
Furthermore, to go back to your original argument:
> Static analysis is just not going to cover all cases.
it's not even true that a runtime check will 'cover all cases': for example a
similar bug to CVE-2010-4258 could still be exploited:
- Note that the actual put_user() was not prevented via the runtime check - the
runtime check would run *after* the buggy put_user() was done. The runtime
check warns or panics after the fact, which might (or might not) be enough to
prevent the exploit.
- Also note that a slightly different form of the bug would still be exploitable,
even with the runtime check: for example if the task-shutdown code can be made
to unconditionally set KERNEL_DS, but after the put_user(), then the runtime
check would not 'cover all cases'.
So the argument for doing this runtime check after every system call is very
dubious.
Thanks,
Ingo
prev parent reply other threads:[~2017-05-09 6:34 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-28 15:32 [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode Thomas Garnier
2017-04-28 15:32 ` [PATCH v9 2/4] x86/syscalls: Optimize address limit check Thomas Garnier
2017-04-28 15:32 ` [PATCH v9 3/4] arm/syscalls: " Thomas Garnier
2017-04-28 15:32 ` [PATCH v9 4/4] arm64/syscalls: " Thomas Garnier
2017-05-05 22:18 ` [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode Thomas Garnier
2017-05-08 7:33 ` Ingo Molnar
2017-05-08 7:52 ` Ingo Molnar
2017-05-08 15:22 ` [kernel-hardening] " Daniel Micay
2017-05-08 15:26 ` Kees Cook
2017-05-08 19:51 ` Thomas Garnier
2017-05-09 6:56 ` Ingo Molnar
2017-05-09 11:10 ` Greg KH
2017-05-09 14:29 ` Thomas Garnier
2017-05-11 23:17 ` Thomas Garnier
2017-05-11 23:44 ` Linus Torvalds
2017-05-12 5:28 ` Martin Schwidefsky
2017-05-12 5:34 ` Kees Cook
2017-05-12 5:54 ` Martin Schwidefsky
2017-05-12 19:01 ` Kees Cook
2017-05-12 19:08 ` Russell King - ARM Linux
2017-05-12 19:08 ` Linus Torvalds
2017-05-12 19:30 ` Kees Cook
2017-05-12 20:21 ` Russell King - ARM Linux
2017-05-12 20:30 ` Peter Zijlstra
2017-05-12 20:45 ` Russell King - ARM Linux
2017-05-12 21:00 ` Kees Cook
2017-05-12 21:04 ` Kees Cook
2017-05-13 7:21 ` Christoph Hellwig
2017-05-12 21:06 ` Al Viro
2017-05-12 21:16 ` Daniel Micay
2017-05-12 21:17 ` Kees Cook
2017-05-12 21:23 ` Daniel Micay
2017-05-12 21:41 ` Al Viro
2017-05-12 21:47 ` Rik van Riel
2017-05-12 22:57 ` Al Viro
2017-05-12 21:50 ` Kees Cook
2017-05-12 6:57 ` Ingo Molnar
2017-05-12 6:13 ` Andy Lutomirski
2017-05-12 6:58 ` Ingo Molnar
2017-05-12 17:05 ` Thomas Garnier
2017-05-09 16:30 ` Kees Cook
2017-05-08 12:46 ` Greg KH
2017-05-09 6:45 ` Ingo Molnar
2017-05-09 8:56 ` Christoph Hellwig
2017-05-09 13:00 ` Andy Lutomirski
2017-05-09 13:02 ` Christoph Hellwig
2017-05-09 16:03 ` Christoph Hellwig
2017-05-09 16:50 ` Kees Cook
2017-05-09 22:52 ` Andy Lutomirski
2017-05-09 23:31 ` Kees Cook
2017-05-10 1:59 ` Andy Lutomirski
2017-05-10 7:15 ` Christoph Hellwig
2017-05-11 11:22 ` Borislav Petkov
2017-05-10 6:46 ` Christoph Hellwig
2017-05-10 2:11 ` Al Viro
2017-05-10 2:45 ` Al Viro
2017-05-10 3:12 ` Al Viro
2017-05-10 3:21 ` Al Viro
2017-05-10 3:39 ` Al Viro
2017-05-10 6:54 ` Christoph Hellwig
2017-05-10 6:53 ` Christoph Hellwig
2017-05-10 7:27 ` Al Viro
2017-05-10 7:35 ` Christoph Hellwig
2017-05-10 6:49 ` Christoph Hellwig
2017-05-10 7:28 ` Arnd Bergmann
2017-05-10 7:35 ` Christoph Hellwig
2017-05-09 16:05 ` Brian Gerst
2017-05-10 7:37 ` Arnd Bergmann
2017-05-10 8:08 ` Al Viro
2017-05-10 8:14 ` Christoph Hellwig
2017-05-11 0:18 ` Andy Lutomirski
2017-05-12 7:00 ` Ingo Molnar
2017-05-12 7:15 ` Al Viro
2017-05-12 7:35 ` Christoph Hellwig
2017-05-12 7:43 ` Arnd Bergmann
2017-05-12 8:11 ` Christoph Hellwig
2017-05-12 8:16 ` Al Viro
2017-05-12 8:11 ` Al Viro
2017-05-12 8:20 ` Arnd Bergmann
2017-05-12 23:20 ` Andy Lutomirski
2017-05-08 13:09 ` Kees Cook
2017-05-08 14:02 ` Ingo Molnar
2017-05-08 14:06 ` Jann Horn
2017-05-08 20:48 ` Al Viro
2017-05-12 23:15 ` Andy Lutomirski
2017-05-08 15:24 ` Kees Cook
2017-05-09 6:34 ` Ingo Molnar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170509063404.pngn4otdmbbrvou3@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=borntraeger@de.ibm.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=mail@renenyffenegger.ch \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=ptikhomirov@virtuozzo.com \
--cc=riel@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).