[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC561CD14B2A@ORSMSX103.amr.corp.intel.com>
Date: Fri, 7 Oct 2016 14:21:01 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: Kees Cook <keescook@...omium.org>, Christoph Hellwig <hch@...radead.org>
CC: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, "corbet@....net" <corbet@....net>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] printk: introduce kptr_restrict level 3
<snip>
>
> As a _singlular_ argument, "it's for out-of-tree code" is weak. As an _additional_
> argument, it has value. Saying "this only helps out-of-tree code" doesn't carry
> much weight. Saying "this helps kernel security, even for out-of-tree code" is
> perfectly valid. And a wrinkle in this is that some day, either that out-of-tree
> code, or brand new code, will land in the kernel, and we don't want to continue
> to require authors be aware of an opt-in security feature. The kernel should
> protect itself (and all of itself, including out-of-tree or future code) by default.
>
I should have made this more clear in my message, this was in my head and I assumed
that people would just get it. But I shouldn't have made such an assumption.
> And based on my read of this thread, we all appear to be in violent agreement. :)
> "always protect %p" is absolutely the goal, and we can figure out the best way to
> get there.
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
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.
