From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <20170118095155.5e3bf976@kaiwan-T460> <90224a2d-2bfc-8c1e-1f2c-ca5bfbdb4879@redhat.com> <20170203101949.4c6908be@kaiwan-T460> From: Kaiwan N Billimoria Date: Sat, 4 Feb 2017 08:42:22 +0530 Message-ID: Content-Type: multipart/alternative; boundary=001a114b172690bc710547abc54b Subject: Re: [kernel-hardening] Merge in PAX_MEMORY_SANITIZE work from grsec to linux-next To: Kees Cook Cc: Laura Abbott , "kernel-hardening@lists.openwall.com" List-ID: --001a114b172690bc710547abc54b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > > I think CONFIG_MEMORY_SANITIZE would enable: > > CONFIG_SLUB_DEBUG=3Dy > CONFIG_PAGE_POISONING=3Dy > CONFIG_PAGE_POISONING_NO_SANITY=3Dy > > but it would _also_ need to set these kernel command-line variables as > if they had been set: > > page_poison=3D1 > slub_debug=3DP > > =E2=80=8BOkay got it. =E2=80=8B > > 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: > > =E2=80=8BRight. > > 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..=E2=80=8B=E2=80=8B > > 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. > > =E2=80=8BHmm, ok.. naivete on my part :-) =E2=80=8B > > 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 th= e > > '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. > =E2=80=8BYeah; I meant under the existing 'Security options' menu actually.= But still..=E2=80=8B > > Hopefully that all makes sense! :) > =E2=80=8BIndeed! Thanks very much.. -Kaiwan.=E2=80=8B > > -Kees > > -- > Kees Cook > Pixel Security > > --001a114b172690bc710547abc54b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think CONFIG_MEMORY_SANITIZE would enable:=

CONFIG_SLUB_DEBUG=3Dy
CONFIG_PAGE_POISONING=3Dy
CONFIG_PAGE_POISONING_NO_SANITY=3Dy

but it would _also_ need to set these kernel command-line variables as
if they had been set:

page_poison=3D1
slub_debug=3DP

=E2=80=8BOkay got it.
=E2=80=8B
<= span class=3D""> > The new config now enables the CONFIG_PAX_MEMORY_SANITIZE code (my pre= v
> email patch), correct? (leaving out the stuff we cannot get without th= e
> 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:

=E2=80=8BRight.

And then finally add the exceptions for the "frequently freed&q= uot; 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..=E2=80=8B=E2=80=8B

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.

=E2=80=8BHmm, ok.. naivete on my part :-)
=E2=80=8B
> Most folks would only use debug during development, if at all - given = all the
> concerns regarding performance. Here, the objective is to enable a pow= erful
> security feature set. Hence, the config directives should come under t= he
> '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.
=E2=80=8BYeah; I meant under the existing 'Security opt= ions' menu actually. But still..=E2=80=8B

Hopefully that all makes sense! :)
=E2=80=8BIndeed! Thanks very much..
-Kaiwan.=E2=80=8B
=

-Kees

--
Kees Cook
Pixel Security


--001a114b172690bc710547abc54b--