Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDLWs-LH=SOt+zpwiqXimirOPSnMGbWHn91Rhim_GCrno7VOQ@mail.gmail.com>
Date: Sat, 4 Feb 2017 08:42:22 +0530
From: Kaiwan N Billimoria <kaiwan@...wantech.com>
To: Kees Cook <keescook@...omium.org>
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

>
>
> 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
>
> ​Okay got it.
​

> > 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:
>
> ​Right.

>
> 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").
>
> Yup..​​

>
> 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.
>
> ​Hmm, ok.. naivete on my part :-)
​

> > 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.
>
​Yeah; I meant under the existing 'Security options' menu actually. But
still..​

>
> Hopefully that all makes sense! :)
>
​Indeed! Thanks very much..
-Kaiwan.​

>
> -Kees
>
> --
> Kees Cook
> Pixel Security
>
>

Content of type "text/html" skipped

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.