[kernel-hardening] status: PAX_REFCOUNT

[kernel-hardening] status: PAX_REFCOUNT

[David Windsor]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

I'm currently in the process of splitting PAX_REFCOUNT.

It looks to touch a massive number of files.  Many of the modifications
occur in drivers:

dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
402
dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked"
drivers/ | wc -l
158

As it stands, I'm trying to come up with a good way to split the patches.
I'm currently going with a scheme of creating separate patches per kernel
subsystem, further separating by component type (filesystems, drivers,
etc.).  For instance, for patches touching fs/, I've created a patch for
filesystem-independent changes, then separate patches for each individual
filesystem's changes.  Extrapolated over the entire kernel, I estimate this
strategy will produce approximately between 50 and 75 patches.

I'm moving my way through the tree and will hopefully have an RFC
submission soon.

Thanks,
David Windsor

[-- Attachment #2: Type: text/html, Size: 1174 bytes --]

Re: [kernel-hardening] status: PAX_REFCOUNT

[Kees Cook]

On Tue, Nov 24, 2015 at 11:37 AM, David Windsor <dave@0x4141.net> wrote:
> I'm currently in the process of splitting PAX_REFCOUNT.
>
> It looks to touch a massive number of files.  Many of the modifications
> occur in drivers:
>
> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
> 402
> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" drivers/
> | wc -l
> 158

Interesting there are so many intentional overflows. I think the
hardest part for getting this series upstream will be sticking to our
principle of not needing a developer to "opt in" to the protection. I
still think this is a compelling reason to keep it as-is, but it
should be an interesting discussion. :)

> As it stands, I'm trying to come up with a good way to split the patches.
> I'm currently going with a scheme of creating separate patches per kernel
> subsystem, further separating by component type (filesystems, drivers,
> etc.).  For instance, for patches touching fs/, I've created a patch for
> filesystem-independent changes, then separate patches for each individual
> filesystem's changes.  Extrapolated over the entire kernel, I estimate this
> strategy will produce approximately between 50 and 75 patches.

That'll be a lot of patches. I wonder if we could break it up by
top-level maintainer? i.e. everything in drivers would go in one
patch, etc?

> I'm moving my way through the tree and will hopefully have an RFC submission
> soon.

Great! Are you working on this full-time? (If not, would potential CII
funding help at all?)

I'll send an lkdtm patch that'll twiddle the atomic type, so you have
something to validate it with.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] status: PAX_REFCOUNT

[David Windsor]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

> That'll be a lot of patches. I wonder if we could break it up by
> top-level maintainer? i.e. everything in drivers would go in one
> patch, etc?
>
>
I can certainly do that, but the size of the drivers patch is going to be
tremendous.  I just figured that smaller patches would be less offensive to
upstream's delicate sensibilities =)

> I'm moving my way through the tree and will hopefully have an RFC
> submission
> > soon.
>
> Great! Are you working on this full-time? (If not, would potential CII
> funding help at all?)
>
>
Just working on this in my spare time.  I've wanted to see PaX/grsecurity
included upstream for a long while now.  Funding is unnecessary, as it
wouldn't enable me to get this finished any more quickly than I would
otherwise.  I'll publish my tree to github so others can help.


> I'll send an lkdtm patch that'll twiddle the atomic type, so you have
> something to validate it with.
>
>
Thanks!

[-- Attachment #2: Type: text/html, Size: 1672 bytes --]

Re: [kernel-hardening] status: PAX_REFCOUNT

[Greg KH]

On Tue, Nov 24, 2015 at 02:37:41PM -0500, David Windsor wrote:
> I'm currently in the process of splitting PAX_REFCOUNT. 
> 
> It looks to touch a massive number of files.  Many of the modifications occur
> in drivers:
> 
> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
> 402
> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" drivers/ |
> wc -l
> 158

Odds are, we can take lots of these existing atomic usages and either
replace them with a kref, or remove them, as I can't imagine that we
need that many different atomic variables for things that are not just
debugging things.

thanks,

greg k-h

Re: [kernel-hardening] status: PAX_REFCOUNT

[Greg KH]

On Tue, Nov 24, 2015 at 01:20:24PM -0800, Greg KH wrote:
> On Tue, Nov 24, 2015 at 02:37:41PM -0500, David Windsor wrote:
> > I'm currently in the process of splitting PAX_REFCOUNT. 
> > 
> > It looks to touch a massive number of files.  Many of the modifications occur
> > in drivers:
> > 
> > dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
> > 402
> > dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" drivers/ |
> > wc -l
> > 158
> 
> Odds are, we can take lots of these existing atomic usages and either
> replace them with a kref, or remove them, as I can't imagine that we
> need that many different atomic variables for things that are not just
> debugging things.

Ok, it's worse than I thought, I see a lot of atomic_t usages in places
that do not even make sense (i.e. being used for some type of flag
instead of taking a lock, or they only access it under a lock making it
pointless to be an atomic variable.)  There's lots of low-hanging fruit
to clean up in this area that I'm sure patches like this will start to
highlight.

thanks,

greg k-h

Re: [kernel-hardening] status: PAX_REFCOUNT

[Kees Cook]

On Tue, Nov 24, 2015 at 1:20 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Nov 24, 2015 at 02:37:41PM -0500, David Windsor wrote:
>> I'm currently in the process of splitting PAX_REFCOUNT.
>>
>> It looks to touch a massive number of files.  Many of the modifications occur
>> in drivers:
>>
>> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" | wc -l
>> 402
>> dave@strontium:~/src/linux-grsec-4.2$ grep -ril "atomic.*unchecked" drivers/ |
>> wc -l
>> 158
>
> Odds are, we can take lots of these existing atomic usages and either
> replace them with a kref, or remove them, as I can't imagine that we
> need that many different atomic variables for things that are not just
> debugging things.

Yeah, I'll be curious to get a look at it in raw extracted form. I
still want to make sure we're whitelisting, though, and not asking
people to learn a new API (unless they do NOT want the protection).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security