From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Greg KH <gregkh@linuxfoundation.org>,
Will Deacon <will.deacon@arm.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
David Windsor <dave@progbits.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t
Date: Wed, 16 Nov 2016 09:31:55 +0100 [thread overview]
Message-ID: <20161116083155.GC1270@gmail.com> (raw)
In-Reply-To: <CAGXu5j+FHmbGvvXg5tYP1w2pjqMnso=VuJnUetobON35B-kEpA@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> On Tue, Nov 15, 2016 at 11:16 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >
> > On 15 November 2016 19:06:28 CET, Kees Cook <keescook@chromium.org> wrote:
> >
> >>I'll want to modify this in the future; I have a config already doing
> >>"Bug on data structure corruption" that makes the warn/bug choice.
> >>It'll need some massaging to fit into the new refcount_t checks, but
> >>it should be okay -- there needs to be a way to complete the
> >>saturation, etc, but still kill the offending process group.
> >
> > Ideally we'd create a new WARN like construct that continues in kernel space
> > and terminates the process on return to user. That way there would be minimal
> > kernel state corruption.
Yeah, so the problem is that sometimes you are p0wned the moment you return to a
corrupted stack, and some of these checks only detect corruption after the fact.
> Right, though I'd like to be conservative about the kernel execution
> continuing... I'll experiment with it.
So what I'd love to see is to have a kernel option that re-introduces some
historic root (and other) holes that can be exploited deterministically -
obviously default disabled.
I'd restrict this to reasonably 'deterministic' holes, and the exploits themselves
could be somewhere in tools/. (Obviously only where the maintainers agree to host
the code.) They wouldn't give a root shell, they'd only test whether they reached
uid0 (or some other elevated privilege).
The advantages of such a suite would be:
- Uptodate tests on modern kernels: It would allow the (controlled) testing of
live kernel exploits even on the latest kernel - and would allow the testing of
various defensive measures.
- It would also make sure that defensive measures _remain_ effective against
similar categories of bugs. We've had defensive measure regressions in the
past, which was only discovered when the next exploit came out ...
- Testing of new defensive measures: It would help convert this whole
probabilistic and emotion driven "kernel protection" business into something
somewhat more rational. For example new protection mechanisms should have a
demonstrated ability to turn an existing exploit test into something less
dangerous.
- Education: It would teach kernel developers the various patterns of holes,
right in the code. Maybe being more directly exposed to what can get you p0wned
is both a stronger education force plus it could give people ideas about how to
protect better.
- I also think that collecting the various problems into a single place will give
us new insights into patterns, bug counts and various exploit techniques.
The disadvantages would be:
- Maintenance: do we want to add extra (compiled out by default) code to the
kernel whose only purpose is to demonstrate certain types of bugs?
- Exposing exploits: Do we want to host a powerful collection of almost-exploits
in tools/ ? I don't think we have a choice but to face the problem directly -
but others might disagree.
I think most of the negatives could be kept small by starting small, allowing
maintainers to explicitly opt-in, and observing the effects as we go. But YMMV.
Thanks,
Ingo
next prev parent reply other threads:[~2016-11-16 8:32 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 17:39 [RFC][PATCH 0/7] kref improvements Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 1/7] kref: Add KREF_INIT() Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 2/7] kref: Add kref_read() Peter Zijlstra
2016-11-14 18:16 ` Christoph Hellwig
2016-11-15 7:28 ` Greg KH
2016-11-15 7:47 ` Peter Zijlstra
2016-11-15 8:37 ` [PATCH] printk, locking/atomics, kref: Introduce new %pAr and %pAk format string options for atomic_t and 'struct kref' Ingo Molnar
2016-11-15 8:43 ` [PATCH v2] " Ingo Molnar
2016-11-15 9:21 ` Peter Zijlstra
2016-11-15 9:41 ` [PATCH v3] printk, locking/atomics, kref: Introduce new %pAa " Ingo Molnar
2016-11-15 10:10 ` [PATCH v2] printk, locking/atomics, kref: Introduce new %pAr " kbuild test robot
2016-11-15 16:42 ` [PATCH] " Linus Torvalds
2016-11-16 8:13 ` Ingo Molnar
2016-11-15 7:33 ` [RFC][PATCH 2/7] kref: Add kref_read() Greg KH
2016-11-15 8:03 ` Peter Zijlstra
2016-11-15 20:53 ` Kees Cook
2016-11-16 8:21 ` Greg KH
2016-11-16 10:10 ` Peter Zijlstra
2016-11-16 10:18 ` Greg KH
2016-11-16 10:11 ` Daniel Borkmann
2016-11-16 10:19 ` Greg KH
2016-11-16 10:09 ` Peter Zijlstra
2016-11-16 18:58 ` Kees Cook
2016-11-17 8:34 ` Peter Zijlstra
2016-11-17 12:30 ` David Windsor
2016-11-17 12:43 ` Peter Zijlstra
2016-11-17 13:01 ` Reshetova, Elena
2016-11-17 13:22 ` Peter Zijlstra
2016-11-17 15:42 ` Reshetova, Elena
2016-11-17 18:02 ` Reshetova, Elena
2016-11-17 19:10 ` Peter Zijlstra
2016-11-17 19:29 ` Peter Zijlstra
2016-11-17 19:34 ` Kees Cook
2016-11-14 17:39 ` [RFC][PATCH 3/7] kref: Kill kref_sub() Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 4/7] kref: Use kref_get_unless_zero() more Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 5/7] kref: Implement kref_put_lock() Peter Zijlstra
2016-11-14 20:35 ` Kees Cook
2016-11-15 7:50 ` Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 6/7] kref: Avoid more abuse Peter Zijlstra
2016-11-14 17:39 ` [RFC][PATCH 7/7] kref: Implement using refcount_t Peter Zijlstra
2016-11-15 8:40 ` Ingo Molnar
2016-11-15 9:47 ` Peter Zijlstra
2016-11-15 10:03 ` Ingo Molnar
2016-11-15 10:46 ` Peter Zijlstra
2016-11-15 13:03 ` Ingo Molnar
2016-11-15 18:06 ` Kees Cook
2016-11-15 19:16 ` Peter Zijlstra
2016-11-15 19:23 ` Kees Cook
2016-11-16 8:31 ` Ingo Molnar [this message]
2016-11-16 8:51 ` Greg KH
2016-11-16 9:07 ` Ingo Molnar
2016-11-16 9:24 ` Greg KH
2016-11-16 10:15 ` Peter Zijlstra
2016-11-16 18:55 ` Kees Cook
2016-11-17 8:33 ` Peter Zijlstra
2016-11-17 19:50 ` Kees Cook
2016-11-16 18:41 ` Kees Cook
2016-11-15 12:33 ` Boqun Feng
2016-11-15 13:01 ` Peter Zijlstra
2016-11-15 14:19 ` Boqun Feng
2016-11-17 9:28 ` Peter Zijlstra
2016-11-17 9:48 ` Boqun Feng
2016-11-17 10:29 ` Peter Zijlstra
2016-11-17 10:39 ` Peter Zijlstra
2016-11-17 11:03 ` Greg KH
2016-11-17 12:48 ` Peter Zijlstra
[not found] ` <CAL0jBu-GnREUPSX4kUDp-Cc8ZGp6+Cb2q0HVandswcLzPRnChQ@mail.gmail.com>
2016-11-17 12:08 ` Peter Zijlstra
2016-11-17 12:08 ` Will Deacon
2016-11-17 16:11 ` Peter Zijlstra
2016-11-17 16:36 ` Will Deacon
2016-11-18 8:26 ` Boqun Feng
2016-11-18 10:16 ` Will Deacon
2016-11-18 10:07 ` Reshetova, Elena
2016-11-18 11:37 ` Peter Zijlstra
2016-11-18 17:06 ` Will Deacon
2016-11-18 18:57 ` Peter Zijlstra
2016-11-21 4:06 ` Boqun Feng
2016-11-21 7:48 ` Ingo Molnar
2016-11-21 8:38 ` Boqun Feng
2016-11-21 8:44 ` Boqun Feng
2016-11-21 9:02 ` Peter Zijlstra
2016-11-21 9:37 ` Boqun Feng
2016-11-18 10:47 ` Reshetova, Elena
2016-11-18 10:52 ` Peter Zijlstra
2016-11-18 16:58 ` Reshetova, Elena
2016-11-18 18:53 ` Peter Zijlstra
2016-11-19 7:14 ` Reshetova, Elena
2016-11-19 11:45 ` Peter Zijlstra
2017-01-26 23:14 ` Kees Cook
2017-01-27 9:58 ` Peter Zijlstra
2017-01-27 21:07 ` Kees Cook
2017-01-30 13:40 ` Peter Zijlstra
2016-11-15 7:27 ` [RFC][PATCH 0/7] kref improvements Greg KH
2016-11-15 7:42 ` Ingo Molnar
2016-11-15 15:05 ` Greg KH
2016-11-15 7:48 ` Peter Zijlstra
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=20161116083155.GC1270@gmail.com \
--to=mingo@kernel.org \
--cc=arnd@arndb.de \
--cc=dave@progbits.org \
--cc=elena.reshetova@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.