[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLUdxDkjZ8Qndui1=5LC-_eavCpsgAqRa7RbdBUVdSsEg@mail.gmail.com>
Date: Fri, 3 Feb 2017 16:23:32 -0800
From: Kees Cook <keescook@...omium.org>
To: Kaiwan N Billimoria <kaiwan@...wantech.com>
Cc: Laura Abbott <labbott@...hat.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Merge in PAX_MEMORY_SANITIZE work from grsec
to linux-next
On Thu, Feb 2, 2017 at 8:49 PM, Kaiwan N Billimoria
<kaiwan@...wantech.com> wrote:
> Pl bear with me, am trying to understand this correctly.
No problem at all. Thanks for continuing to poke at this. :)
> From what I gather, we look to create a new config directive, say,
> CONFIG_MEMORY_SANITIZE .
>
> It will turn ON :
> CONFIG_DEBUG_PAGEALLOC
> (which internally turns ON CONFIG_PAGE_EXTENSION), and
> CONFIG_PAGE_POISONING
> (similar internal turn-ons :).
I think CONFIG_MEMORY_SANITIZE would enable:
CONFIG_SLUB_DEBUG=y
CONFIG_PAGE_POISONING=y
CONFIG_PAGE_POISONING_NO_SANITY=y
but it would _also_ need to set these kernel command-line variables as
if they had been set:
page_poison=1
slub_debug=P
> The new config now enables the CONFIG_PAX_MEMORY_SANITIZE code (my prev
> email patch), correct? (leaving out the stuff we cannot get without the
> full grsec implementation).
No, the first step would be for the config to only provide the above changes.
Then, we'd want to add the poison value defaults as you mention:
> -Would include the 'new' poison / sanitize values of 0xfe and 0xff for slab
> (64 and 32-bit resp), etc etc.
And then finally add the exceptions for the "frequently freed" slub
caches, as identified by PaX already. This would need the flag
defined, the poisoning logic adjusted to check the flag, and for the
new kernel command-line options for changing the whether or not the
flag is respected (like PaX's "pax_sanitize_slab").
> Even if this is (somewhat) correct, my thinking is - correct me I'm totally
> wrong here - that the whole purpose of the exercise is to improve _security_;
> hence, tying this code into the "debug features" of the kernel isn't really
> what we want, yes?
In the discussions Laura had with the mm folks, the only realistic
path to landing this in the upstream kernel is through these debug
features.
> Most folks would only use debug during development, if at all - given all the
> concerns regarding performance. Here, the objective is to enable a powerful
> security feature set. Hence, the config directives should come under the
> 'Security Options' menu.
We're not close to having a "Kernel Security" menu, so for now, I've
wanted to focus on getting the features, and then making the Kconfig
menus pretty later.
Hopefully that all makes sense! :)
-Kees
--
Kees Cook
Pixel 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.
