Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Jan 2017 09:01:05 +0530
From: Kaiwan N Billimoria <>
To: Kees Cook <>
Cc: "" <>
Subject: Re: New to KSPP, would like to contribute

Okay, thanks, I see it better now :)

Forgive my silly qs:
so as I understand it, the objective is to start merging in some of the
grsec code into mainline, yes? So, which kernel do we work on? the latest
rc or do I work on the one where the above patch applies (i.e. 4.8.17)?
(Also, fyi, i'll be travelling from tomm so will not be able to work on
this for a few days at least).



Kaiwan N Billimoria

Do visit our enhanced website.

4931, 11th Floor, Highpoint IV, 45 Palace Road, Bangalore 560 001.
☎ +91.9845016788 (M)
☎ TeleFax: +91.80.22389396 | Alt. Tel: +91.80.64500257


I blog here:
Tech :  |
Running :

"Don't be afraid that your life will end,
be afraid that it will never begin."

On Wed, Jan 11, 2017 at 1:55 AM, Kees Cook <> wrote:

> On Tue, Jan 10, 2017 at 4:42 AM, Kaiwan N Billimoria
> <> wrote:
> > Thanks Kees,
> >>
> >>
> >> Welcome to the list! If you're familiar with mm areas, I'd say a great
> >> place to start would be to help finish up the zero-poisoning work,
> >> especially extracting the optimizations that PaX did for slabs to
> >> avoid, etc.
> >
> > Ok so I really have no idea reg PaX and optimizations done for slab via
> it..
> > Could you
> > enlighten me pl? Point me to relevant links perhaps..
> Sure thing! I would recommend downloading the latest grsecurity patchset:
> (currently for a 4.8.7 kernel) and apply it there. Once you have a
> tree you can examine, I would look at how CONFIG_PAX_MEMORY_SANITIZE
> works, and especially note this from the security/Kconfig:
>           The tradeoff is performance impact, on a single CPU system kernel
>           compilation sees a 3% slowdown, other systems and workloads may
> vary
>           and you are advised to test this feature on your expected
> workload
>           before deploying it.
>           The slab sanitization feature excludes a few slab caches per
> default
>           for performance reasons.  To extend the feature to cover those as
>           well, pass "pax_sanitize_slab=full" as kernel command line
> parameter.
>           To reduce the performance penalty by sanitizing pages only,
> albeit
>           limiting the effectiveness of this feature at the same time, slab
>           sanitization can be disabled with the kernel command line
> parameter
>           "pax_sanitize_slab=off".
> I'd like to see the mentioned excluded slab caches also done in the
> kernel, along with similar kernel command line options. Additionally,
> getting all the upstream stuff behind a single CONFIG (similar to
> CONFIG_PAX_MEMORY_SANITIZE) would be great, instead of having to set 3
> CONFIGs and 2 kernel parameters. :)
> Let me know if you need more details...
> -Kees
> --
> Kees Cook
> Nexus 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.