[ARM ATTEND] catching up on exploit mitigations

[ARM ATTEND] catching up on exploit mitigations

[Kees Cook]

I'd like to propose the topic of catching up to x86 exploit
mitigations and security features, and potentially identifying
ARM-unique mitigations/features that could be implemented. Several
years ago, with Nicolas Pitre doing all the real work, I coordinated
getting ARM caught up on things like userspace ASLR and
stack-protector. Recently, based on work by Will Drewry, I ported
seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
think it's overdue to examine this area again. A lot of work has
already been done by grsecurity in this area (see
http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
good to start there.

While it may expose my current ignorance of low level ARM mechanics,
I'd like to examine and discuss:

- RO and W^X kernel page table protections (similar to x86's
DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
LPAE and PXN is already handling this, if at all)

- something like x86's SMEP and SMAP (to deter kernel exploitation
from userspace)

- vector table protections (needs to be protected like the x86_64
vsyscall table, RO, etc)

- kernel ASLR (I'm close to having this upstreamable for x86)

- fuzzing (is anyone running trinity or similar on the ARM tree?)

- any other things ... ?

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security

[ARM ATTEND] catching up on exploit mitigations

[Kees Cook]

I'd like to propose the topic of catching up to x86 exploit
mitigations and security features, and potentially identifying
ARM-unique mitigations/features that could be implemented. Several
years ago, with Nicolas Pitre doing all the real work, I coordinated
getting ARM caught up on things like userspace ASLR and
stack-protector. Recently, based on work by Will Drewry, I ported
seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
think it's overdue to examine this area again. A lot of work has
already been done by grsecurity in this area (see
http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
good to start there.

While it may expose my current ignorance of low level ARM mechanics,
I'd like to examine and discuss:

- RO and W^X kernel page table protections (similar to x86's
DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
LPAE and PXN is already handling this, if at all)

- something like x86's SMEP and SMAP (to deter kernel exploitation
from userspace)

- vector table protections (needs to be protected like the x86_64
vsyscall table, RO, etc)

- kernel ASLR (I'm close to having this upstreamable for x86)

- fuzzing (is anyone running trinity or similar on the ARM tree?)

- any other things ... ?

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 
 > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 
Someone was kind enough to send me an arm chromebook, so I tried this just
last week (albeit, on the 3.4 kernel it shipped with). The results make
me think the answer is a resounding 'no'.

I don't have time to build more recent kernels on it, but I wouldn't
be surprised to find that things aren't much better (If they are, someone
is seriously sucking at backporting stuff to stable).

There's no ARM64 support yet in trinity, though it'd be easy to add for
someone with hardware. Again, wouldn't be surprised at all to learn there
are bugs there (It's been true of every new arch ported to so far).

On the subject of trinity, I've been hesitant about proposing a slot
at k-s this year, though if there's interest I'm always happy to talk
about it, and get feedback for new places it could go..

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 
 > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 
Someone was kind enough to send me an arm chromebook, so I tried this just
last week (albeit, on the 3.4 kernel it shipped with). The results make
me think the answer is a resounding 'no'.

I don't have time to build more recent kernels on it, but I wouldn't
be surprised to find that things aren't much better (If they are, someone
is seriously sucking at backporting stuff to stable).

There's no ARM64 support yet in trinity, though it'd be easy to add for
someone with hardware. Again, wouldn't be surprised at all to learn there
are bugs there (It's been true of every new arch ported to so far).

On the subject of trinity, I've been hesitant about proposing a slot
at k-s this year, though if there's interest I'm always happy to talk
about it, and get feedback for new places it could go..

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[H. Peter Anvin]

On 07/30/2013 03:14 PM, Dave Jones wrote:
> 
> On the subject of trinity, I've been hesitant about proposing a slot
> at k-s this year, though if there's interest I'm always happy to talk
> about it, and get feedback for new places it could go..
> 

I'd certainly be interested, no matter which forum.

	-hpa

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[H. Peter Anvin]

On 07/30/2013 03:14 PM, Dave Jones wrote:
> 
> On the subject of trinity, I've been hesitant about proposing a slot
> at k-s this year, though if there's interest I'm always happy to talk
> about it, and get feedback for new places it could go..
> 

I'd certainly be interested, no matter which forum.

	-hpa

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Jason Cooper]

On Tue, Jul 30, 2013 at 03:28:59PM -0700, H. Peter Anvin wrote:
> On 07/30/2013 03:14 PM, Dave Jones wrote:
> > 
> > On the subject of trinity, I've been hesitant about proposing a slot
> > at k-s this year, though if there's interest I'm always happy to talk
> > about it, and get feedback for new places it could go..
> > 
> 
> I'd certainly be interested, no matter which forum.

I would be as well.

thx,

Jason.

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Jason Cooper]

On Tue, Jul 30, 2013 at 03:28:59PM -0700, H. Peter Anvin wrote:
> On 07/30/2013 03:14 PM, Dave Jones wrote:
> > 
> > On the subject of trinity, I've been hesitant about proposing a slot
> > at k-s this year, though if there's interest I'm always happy to talk
> > about it, and get feedback for new places it could go..
> > 
> 
> I'd certainly be interested, no matter which forum.

I would be as well.

thx,

Jason.

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Aaro Koskinen]

Hi,

On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  
> Someone was kind enough to send me an arm chromebook, so I tried this just
> last week (albeit, on the 3.4 kernel it shipped with). The results make
> me think the answer is a resounding 'no'.

Shouldn't you run trinity only under QEMU or similar virtual
environment? Don't know about chromebook, but on some of my ARM boards
a misbehaving kernel could at least in theory brick the board...

A.

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Aaro Koskinen]

Hi,

On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
> On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  
> Someone was kind enough to send me an arm chromebook, so I tried this just
> last week (albeit, on the 3.4 kernel it shipped with). The results make
> me think the answer is a resounding 'no'.

Shouldn't you run trinity only under QEMU or similar virtual
environment? Don't know about chromebook, but on some of my ARM boards
a misbehaving kernel could at least in theory brick the board...

A.

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
 > Hi,
 > 
 > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
 > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 > >  
 > > Someone was kind enough to send me an arm chromebook, so I tried this just
 > > last week (albeit, on the 3.4 kernel it shipped with). The results make
 > > me think the answer is a resounding 'no'.
 > 
 > Shouldn't you run trinity only under QEMU or similar virtual
 > environment? Don't know about chromebook, but on some of my ARM boards
 > a misbehaving kernel could at least in theory brick the board...
 
I like to live dangerously.  Don't imitate everything you see on TV,
or read about on lkml.

More seriously, that's true if you're running trinity as root, which
yes, I usually advise people only do in qemu etc.

If you're running it as a regular user and you can brick the board,
you might have bigger problems.

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
 > Hi,
 > 
 > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
 > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
 > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
 > >  
 > > Someone was kind enough to send me an arm chromebook, so I tried this just
 > > last week (albeit, on the 3.4 kernel it shipped with). The results make
 > > me think the answer is a resounding 'no'.
 > 
 > Shouldn't you run trinity only under QEMU or similar virtual
 > environment? Don't know about chromebook, but on some of my ARM boards
 > a misbehaving kernel could at least in theory brick the board...
 
I like to live dangerously.  Don't imitate everything you see on TV,
or read about on lkml.

More seriously, that's true if you're running trinity as root, which
yes, I usually advise people only do in qemu etc.

If you're running it as a regular user and you can brick the board,
you might have bigger problems.

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Kees Cook]

On Tue, Jul 30, 2013 at 4:15 PM, Dave Jones <davej@redhat.com> wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > Hi,
>  >
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  >
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.
>
> More seriously, that's true if you're running trinity as root, which
> yes, I usually advise people only do in qemu etc.
>
> If you're running it as a regular user and you can brick the board,
> you might have bigger problems.

Exactly, and finding those problems tends to be worth the hardware hassle. :)

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Kees Cook]

On Tue, Jul 30, 2013 at 4:15 PM, Dave Jones <davej@redhat.com> wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > Hi,
>  >
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  >
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.
>
> More seriously, that's true if you're running trinity as root, which
> yes, I usually advise people only do in qemu etc.
>
> If you're running it as a regular user and you can brick the board,
> you might have bigger problems.

Exactly, and finding those problems tends to be worth the hardware hassle. :)

-Kees

-- 
Kees Cook
Chrome OS Security

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[H. Peter Anvin]

On 07/30/2013 04:33 PM, Kees Cook wrote:
>>
>> If you're running it as a regular user and you can brick the board,
>> you might have bigger problems.
> 
> Exactly, and finding those problems tends to be worth the hardware hassle. :)
> 

Even as root the number of things allowed to brick the hardware is quite
small.  Call it destructive testing.

	-hpa

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[H. Peter Anvin]

On 07/30/2013 04:33 PM, Kees Cook wrote:
>>
>> If you're running it as a regular user and you can brick the board,
>> you might have bigger problems.
> 
> Exactly, and finding those problems tends to be worth the hardware hassle. :)
> 

Even as root the number of things allowed to brick the hardware is quite
small.  Call it destructive testing.

	-hpa

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Aaro Koskinen]

Hi,

On Tue, Jul 30, 2013 at 07:15:33PM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >  
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  > 
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>  
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.

Sadly I have no TV. :)

Anyway, I think it would be interesting to learn about arch-specific
bugs discovered with trinity. Quickly thinking, the results should be
mostly same regardless of the architecture since the code being tested
is generic especially when running as a regular user. But of course
there are 32/64-bit and big-endian/little-endian and such differences,
and maybe some permission bugs (likely in vendor kernels).

A.

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Aaro Koskinen]

Hi,

On Tue, Jul 30, 2013 at 07:15:33PM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 02:11:20AM +0300, Aaro Koskinen wrote:
>  > On Tue, Jul 30, 2013 at 06:14:35PM -0400, Dave Jones wrote:
>  > > On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>  > >  > - fuzzing (is anyone running trinity or similar on the ARM tree?)
>  > >  
>  > > Someone was kind enough to send me an arm chromebook, so I tried this just
>  > > last week (albeit, on the 3.4 kernel it shipped with). The results make
>  > > me think the answer is a resounding 'no'.
>  > 
>  > Shouldn't you run trinity only under QEMU or similar virtual
>  > environment? Don't know about chromebook, but on some of my ARM boards
>  > a misbehaving kernel could at least in theory brick the board...
>  
> I like to live dangerously.  Don't imitate everything you see on TV,
> or read about on lkml.

Sadly I have no TV. :)

Anyway, I think it would be interesting to learn about arch-specific
bugs discovered with trinity. Quickly thinking, the results should be
mostly same regardless of the architecture since the code being tested
is generic especially when running as a regular user. But of course
there are 32/64-bit and big-endian/little-endian and such differences,
and maybe some permission bugs (likely in vendor kernels).

A.

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 02:58:34AM +0300, Aaro Koskinen wrote:

 > Anyway, I think it would be interesting to learn about arch-specific
 > bugs discovered with trinity. Quickly thinking, the results should be
 > mostly same regardless of the architecture since the code being tested
 > is generic especially when running as a regular user. But of course
 > there are 32/64-bit and big-endian/little-endian and such differences,
 > and maybe some permission bugs (likely in vendor kernels).

To use ARM as an example, the bugs I've seen have mostly been in arch specific
code that does things like page-table manipulation.  The chromebook bugs I
was hitting for eg were various kinds of PTE corruption warnings. 

ISTR the ia64 & sparc64 bugs it discovered long ago were also due to
things like missing cache flushes, as well as trivial fence-post errors.

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 02:58:34AM +0300, Aaro Koskinen wrote:

 > Anyway, I think it would be interesting to learn about arch-specific
 > bugs discovered with trinity. Quickly thinking, the results should be
 > mostly same regardless of the architecture since the code being tested
 > is generic especially when running as a regular user. But of course
 > there are 32/64-bit and big-endian/little-endian and such differences,
 > and maybe some permission bugs (likely in vendor kernels).

To use ARM as an example, the bugs I've seen have mostly been in arch specific
code that does things like page-table manipulation.  The chromebook bugs I
was hitting for eg were various kinds of PTE corruption warnings. 

ISTR the ia64 & sparc64 bugs it discovered long ago were also due to
things like missing cache flushes, as well as trivial fence-post errors.

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> To use ARM as an example, the bugs I've seen have mostly been in arch specific
> code that does things like page-table manipulation.  The chromebook bugs I
> was hitting for eg were various kinds of PTE corruption warnings. 

Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
having any changes related to bug reports on PTEs on ARM.

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
> To use ARM as an example, the bugs I've seen have mostly been in arch specific
> code that does things like page-table manipulation.  The chromebook bugs I
> was hitting for eg were various kinds of PTE corruption warnings. 

Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
having any changes related to bug reports on PTEs on ARM.

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
 > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
 > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
 > > code that does things like page-table manipulation.  The chromebook bugs I
 > > was hitting for eg were various kinds of PTE corruption warnings. 
 > 
 > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > having any changes related to bug reports on PTEs on ARM.

I wasn't sure if it was a googleism, or happens on mainline, so no.

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
 > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
 > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
 > > code that does things like page-table manipulation.  The chromebook bugs I
 > > was hitting for eg were various kinds of PTE corruption warnings. 
 > 
 > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > having any changes related to bug reports on PTEs on ARM.

I wasn't sure if it was a googleism, or happens on mainline, so no.

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Olof Johansson]

On Wed, Jul 31, 2013 at 7:24 AM, Dave Jones <davej@redhat.com> wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
>  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
>  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
>  > > code that does things like page-table manipulation.  The chromebook bugs I
>  > > was hitting for eg were various kinds of PTE corruption warnings.
>  >
>  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
>  > having any changes related to bug reports on PTEs on ARM.
>
> I wasn't sure if it was a googleism, or happens on mainline, so no.

We'd definitely be interested in hearing about what you've found. The
3.4 kernel has a lot of out-of-tree code for exynos, we've reduced it
quite a bit on the upcoming 3.8 one but it needs a bit more baking.

As of 3.10, it's not actually hard to run a mainline kernel on the
chromebook, but you have limited functionality (no wifi, no USB3, no
accellerated graphics). Easiest is to do it by booting from SD card.
See instructions at
http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.


How long would a useful run of trinity take? I've got an
autobuilder/autobooter setup here with a cross-section of current ARM
hardware (7 platforms and counting) that I mostly do boot testing on,
and I should add a smallish suite of testcases to the same. Trinity
would be a good candidate for that.


-Olof

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Olof Johansson]

On Wed, Jul 31, 2013 at 7:24 AM, Dave Jones <davej@redhat.com> wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
>  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
>  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
>  > > code that does things like page-table manipulation.  The chromebook bugs I
>  > > was hitting for eg were various kinds of PTE corruption warnings.
>  >
>  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
>  > having any changes related to bug reports on PTEs on ARM.
>
> I wasn't sure if it was a googleism, or happens on mainline, so no.

We'd definitely be interested in hearing about what you've found. The
3.4 kernel has a lot of out-of-tree code for exynos, we've reduced it
quite a bit on the upcoming 3.8 one but it needs a bit more baking.

As of 3.10, it's not actually hard to run a mainline kernel on the
chromebook, but you have limited functionality (no wifi, no USB3, no
accellerated graphics). Easiest is to do it by booting from SD card.
See instructions at
http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.


How long would a useful run of trinity take? I've got an
autobuilder/autobooter setup here with a cross-section of current ARM
hardware (7 platforms and counting) that I mostly do boot testing on,
and I should add a smallish suite of testcases to the same. Trinity
would be a good candidate for that.


-Olof

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:

 > >  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > >  > having any changes related to bug reports on PTEs on ARM.
 > >
 > > I wasn't sure if it was a googleism, or happens on mainline, so no.
 > 
 > As of 3.10, it's not actually hard to run a mainline kernel on the
 > chromebook, but you have limited functionality (no wifi, no USB3, no
 > accellerated graphics). Easiest is to do it by booting from SD card.
 > See instructions at
 > http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.
 
Yeah, that's how I got Fedora running on it (I think the people who did the
Fedora spin for the chromebook chose the google kernel for exactly
the reasons you mention above).  It felt a little sluggish for a native
kernel build though, and I'm not setup for cross-building so I stuck with
the 3.4 build.
 
 > How long would a useful run of trinity take?

It blew up in a minute or so of runtime when I tried last week.

 > I've got an autobuilder/autobooter setup here with a cross-section of current ARM
 > hardware (7 platforms and counting) that I mostly do boot testing on,
 > and I should add a smallish suite of testcases to the same. Trinity
 > would be a good candidate for that.

Feel free to mail me off-list if I can do anything to help out, though
hopefully things should build & run 'out of the box'.  You shouldn't
need any special command line args (though you might get inspiration
for ideas from the scripts/test-* harnesses)

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:

 > >  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > >  > having any changes related to bug reports on PTEs on ARM.
 > >
 > > I wasn't sure if it was a googleism, or happens on mainline, so no.
 > 
 > As of 3.10, it's not actually hard to run a mainline kernel on the
 > chromebook, but you have limited functionality (no wifi, no USB3, no
 > accellerated graphics). Easiest is to do it by booting from SD card.
 > See instructions at
 > http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook.
 
Yeah, that's how I got Fedora running on it (I think the people who did the
Fedora spin for the chromebook chose the google kernel for exactly
the reasons you mention above).  It felt a little sluggish for a native
kernel build though, and I'm not setup for cross-building so I stuck with
the 3.4 build.
 
 > How long would a useful run of trinity take?

It blew up in a minute or so of runtime when I tried last week.

 > I've got an autobuilder/autobooter setup here with a cross-section of current ARM
 > hardware (7 platforms and counting) that I mostly do boot testing on,
 > and I should add a smallish suite of testcases to the same. Trinity
 > would be a good candidate for that.

Feel free to mail me off-list if I can do anything to help out, though
hopefully things should build & run 'out of the box'.  You shouldn't
need any special command line args (though you might get inspiration
for ideas from the scripts/test-* harnesses)

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Vince Weaver]

On Wed, 31 Jul 2013, Dave Jones wrote:

> On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:
>  > How long would a useful run of trinity take?
> 
> It blew up in a minute or so of runtime when I tried last week.

I also have a chromebook running 3.4 and it is trivially easy to crash it 
with some simple perf_event tests I have (not the fuzzer, but just the 
regular validation tests that test counter overflow).

Like Dave, I didn't bother reporting the problem because I figured 3.4 was 
too old for anyone to care about and it was a struggle getting any 
distro/kernel installed at all on the system let alone trying to boot 
something close to current mainline on it.

Vince

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Vince Weaver]

On Wed, 31 Jul 2013, Dave Jones wrote:

> On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:
>  > How long would a useful run of trinity take?
> 
> It blew up in a minute or so of runtime when I tried last week.

I also have a chromebook running 3.4 and it is trivially easy to crash it 
with some simple perf_event tests I have (not the fuzzer, but just the 
regular validation tests that test counter overflow).

Like Dave, I didn't bother reporting the problem because I figured 3.4 was 
too old for anyone to care about and it was a struggle getting any 
distro/kernel installed at all on the system let alone trying to boot 
something close to current mainline on it.

Vince

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
>  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
>  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
>  > > code that does things like page-table manipulation.  The chromebook bugs I
>  > > was hitting for eg were various kinds of PTE corruption warnings. 
>  > 
>  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
>  > having any changes related to bug reports on PTEs on ARM.
> 
> I wasn't sure if it was a googleism, or happens on mainline, so no.

I've been running several iterations of it for a while (== up to 10 minutes
run time - which is normally about how long it takes to find the rather-too-
exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
page table corruption.

Maybe you can give some ideas as to how you were running it?  Was it
running as root or as a normal user?  Were there any nonstandard platform
specific devices in /dev which that user could access - such as graphics
or video decoder devices which could be exposing big holes?

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
>  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
>  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
>  > > code that does things like page-table manipulation.  The chromebook bugs I
>  > > was hitting for eg were various kinds of PTE corruption warnings. 
>  > 
>  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
>  > having any changes related to bug reports on PTEs on ARM.
> 
> I wasn't sure if it was a googleism, or happens on mainline, so no.

I've been running several iterations of it for a while (== up to 10 minutes
run time - which is normally about how long it takes to find the rather-too-
exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
page table corruption.

Maybe you can give some ideas as to how you were running it?  Was it
running as root or as a normal user?  Were there any nonstandard platform
specific devices in /dev which that user could access - such as graphics
or video decoder devices which could be exposing big holes?

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
 > On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
 > > On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
 > >  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
 > >  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
 > >  > > code that does things like page-table manipulation.  The chromebook bugs I
 > >  > > was hitting for eg were various kinds of PTE corruption warnings. 
 > >  > 
 > >  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > >  > having any changes related to bug reports on PTEs on ARM.
 > > 
 > > I wasn't sure if it was a googleism, or happens on mainline, so no.
 > 
 > I've been running several iterations of it for a while (== up to 10 minutes
 > run time - which is normally about how long it takes to find the rather-too-
 > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
 > page table corruption.

awesome. Guess it was a google specific issue then.
(Or something that got fixed post 3.4)

 > Maybe you can give some ideas as to how you were running it?  Was it
 > running as root or as a normal user? 

yeah, unpriv'd user. 

 > Were there any nonstandard platform
 > specific devices in /dev which that user could access - such as graphics
 > or video decoder devices which could be exposing big holes?

I'm not sure what google patched into that kernel altogether, so who knows..

	Dave

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
 > On Wed, Jul 31, 2013 at 10:24:30AM -0400, Dave Jones wrote:
 > > On Wed, Jul 31, 2013 at 10:40:12AM +0100, Russell King - ARM Linux wrote:
 > >  > On Tue, Jul 30, 2013 at 08:04:44PM -0400, Dave Jones wrote:
 > >  > > To use ARM as an example, the bugs I've seen have mostly been in arch specific
 > >  > > code that does things like page-table manipulation.  The chromebook bugs I
 > >  > > was hitting for eg were various kinds of PTE corruption warnings. 
 > >  > 
 > >  > Hmm, really?  Did you reported these bugs?  I'm not aware of mainline
 > >  > having any changes related to bug reports on PTEs on ARM.
 > > 
 > > I wasn't sure if it was a googleism, or happens on mainline, so no.
 > 
 > I've been running several iterations of it for a while (== up to 10 minutes
 > run time - which is normally about how long it takes to find the rather-too-
 > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
 > page table corruption.

awesome. Guess it was a google specific issue then.
(Or something that got fixed post 3.4)

 > Maybe you can give some ideas as to how you were running it?  Was it
 > running as root or as a normal user? 

yeah, unpriv'd user. 

 > Were there any nonstandard platform
 > specific devices in /dev which that user could access - such as graphics
 > or video decoder devices which could be exposing big holes?

I'm not sure what google patched into that kernel altogether, so who knows..

	Dave

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
>  > I've been running several iterations of it for a while (== up to 10 minutes
>  > run time - which is normally about how long it takes to find the rather-too-
>  > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
>  > page table corruption.
> 
> awesome. Guess it was a google specific issue then.
> (Or something that got fixed post 3.4)

It's been running on this run for 38 minutes so far (having put a
__GFP_NOWARN stopper in that kmalloc - which I think there needs to be
a better solution.)

What I have noticed is during the initialisation of the fd[] array, it
sometimes hangs on a futex.  Killing trinity, removing all the files
and restarting it seems to sort the problem out.  I'm not sure what's
doing that - any ideas?  I couldn't find any evidence of another trinity
thread doing anything with futexes.

>  > Were there any nonstandard platform
>  > specific devices in /dev which that user could access - such as graphics
>  > or video decoder devices which could be exposing big holes?
> 
> I'm not sure what google patched into that kernel altogether, so who knows..

Unfortunately, it seems to be rather common if there's hardware GPU or
video codecs to expose physical addresses to userspace which get passed
around in closed source libraries and ultimately to GPU/video hardware.
I would not be surprised if trinity was finding that and finding some
way to get something to poke randomly in kernel memory.

It seems also that the normal approach is to expose the device nodes in
/dev to the world, effectively handing any userspace program the ability
to:

(a) a way to allocate from a pool of memory, and get its physical address
(b) to be able to pass a physical address to hardware for DMA type operations
(c) to initiate DMA on that hardware

This is why closed source GPU/video stuff is Bad News(tm) for security.
I'd strongly suggest keeping such platforms well away from any data
anyone cares about keeping private and keeping them well isolated. :)

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Wed, Aug 21, 2013 at 11:43:55AM -0400, Dave Jones wrote:
> On Wed, Aug 21, 2013 at 04:26:14PM +0100, Russell King - ARM Linux wrote:
>  > I've been running several iterations of it for a while (== up to 10 minutes
>  > run time - which is normally about how long it takes to find the rather-too-
>  > exposed kmalloc in sys_oabi_epoll_wait) and so far have seen no sign of any
>  > page table corruption.
> 
> awesome. Guess it was a google specific issue then.
> (Or something that got fixed post 3.4)

It's been running on this run for 38 minutes so far (having put a
__GFP_NOWARN stopper in that kmalloc - which I think there needs to be
a better solution.)

What I have noticed is during the initialisation of the fd[] array, it
sometimes hangs on a futex.  Killing trinity, removing all the files
and restarting it seems to sort the problem out.  I'm not sure what's
doing that - any ideas?  I couldn't find any evidence of another trinity
thread doing anything with futexes.

>  > Were there any nonstandard platform
>  > specific devices in /dev which that user could access - such as graphics
>  > or video decoder devices which could be exposing big holes?
> 
> I'm not sure what google patched into that kernel altogether, so who knows..

Unfortunately, it seems to be rather common if there's hardware GPU or
video codecs to expose physical addresses to userspace which get passed
around in closed source libraries and ultimately to GPU/video hardware.
I would not be surprised if trinity was finding that and finding some
way to get something to poke randomly in kernel memory.

It seems also that the normal approach is to expose the device nodes in
/dev to the world, effectively handing any userspace program the ability
to:

(a) a way to allocate from a pool of memory, and get its physical address
(b) to be able to pass a physical address to hardware for DMA type operations
(c) to initiate DMA on that hardware

This is why closed source GPU/video stuff is Bad News(tm) for security.
I'd strongly suggest keeping such platforms well away from any data
anyone cares about keeping private and keeping them well isolated. :)

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dan Carpenter]

I was just reading http://faultlinux.lip6.fr/ which says that in
2011 the static checker fault rate in arch/ and fs/ was worse than
in drivers/.  I suspect that there are some security vulnerabilities
there.

regards,
dan carpenter

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dan Carpenter]

I was just reading http://faultlinux.lip6.fr/ which says that in
2011 the static checker fault rate in arch/ and fs/ was worse than
in drivers/.  I suspect that there are some security vulnerabilities
there.

regards,
dan carpenter

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
 > I was just reading http://faultlinux.lip6.fr/ which says that in
 > 2011 the static checker fault rate in arch/ and fs/ was worse than
 > in drivers/

I've been working on getting more regular builds in coverity, so we can
get more meaningful statistics on things like "what area is getting worse".

Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
in terms of highest bug counts.

Drivers/net/wireless: 659 
Drivers/ [1] : 600
Drivers/staging: 449
Drivers/scsi: 409
Drivers/net: 350
Net/[2] : 297
Drivers/media: 286
Sound: 220
Drivers/GPU: 217

That's the top categories for the whole kernel.

That wireless was top of the list was the least shocking thing to me,
based on what we get reported to Fedora bugzilla.  That it found more
bugs there than in staging was amusing though. The good news is that
wireless also takes the top slot for 'resolved' issues.

The paper above talks about 'arch' but doesn't indicate if it's counting
all arches, or just the one they run the tests on. (Coverity only covers x86,
so arch/ shows up in 10th place there).
FS doesn't show up on the list until 14th place, where there's a another
catchall category like [1][2]. The first actual fs category with the most
bugs is btrfs at 16th place, with 68 outstanding reports.

There's a lot of work to do picking through their database, including writing
modelling functions to reduce false positives. But, I'm on it.
I'll write up something a bit more in-depth later.

	Dave

[1] This is everything that doesn't match one of the more specific drivers category, 
    of which there's those mentioned above, plus about a dozen others.
[2] This is everything in net/ except for ipv4/ipv6/sctp, so all the weirdo protocols basically.

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dave Jones]

On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
 > I was just reading http://faultlinux.lip6.fr/ which says that in
 > 2011 the static checker fault rate in arch/ and fs/ was worse than
 > in drivers/

I've been working on getting more regular builds in coverity, so we can
get more meaningful statistics on things like "what area is getting worse".

Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
in terms of highest bug counts.

Drivers/net/wireless: 659 
Drivers/ [1] : 600
Drivers/staging: 449
Drivers/scsi: 409
Drivers/net: 350
Net/[2] : 297
Drivers/media: 286
Sound: 220
Drivers/GPU: 217

That's the top categories for the whole kernel.

That wireless was top of the list was the least shocking thing to me,
based on what we get reported to Fedora bugzilla.  That it found more
bugs there than in staging was amusing though. The good news is that
wireless also takes the top slot for 'resolved' issues.

The paper above talks about 'arch' but doesn't indicate if it's counting
all arches, or just the one they run the tests on. (Coverity only covers x86,
so arch/ shows up in 10th place there).
FS doesn't show up on the list until 14th place, where there's a another
catchall category like [1][2]. The first actual fs category with the most
bugs is btrfs at 16th place, with 68 outstanding reports.

There's a lot of work to do picking through their database, including writing
modelling functions to reduce false positives. But, I'm on it.
I'll write up something a bit more in-depth later.

	Dave

[1] This is everything that doesn't match one of the more specific drivers category, 
    of which there's those mentioned above, plus about a dozen others.
[2] This is everything in net/ except for ipv4/ipv6/sctp, so all the weirdo protocols basically.

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dan Carpenter]

On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
>  > I was just reading http://faultlinux.lip6.fr/ which says that in
>  > 2011 the static checker fault rate in arch/ and fs/ was worse than
>  > in drivers/
> 
> I've been working on getting more regular builds in coverity, so we can
> get more meaningful statistics on things like "what area is getting worse".
> 
> Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> in terms of highest bug counts.
> 
> Drivers/net/wireless: 659 
> Drivers/ [1] : 600
> Drivers/staging: 449
> Drivers/scsi: 409
> Drivers/net: 350
> Net/[2] : 297
> Drivers/media: 286
> Sound: 220
> Drivers/GPU: 217
> 
> That's the top categories for the whole kernel.
> 
> That wireless was top of the list was the least shocking thing to me,
> based on what we get reported to Fedora bugzilla.  That it found more
> bugs there than in staging was amusing though. The good news is that
> wireless also takes the top slot for 'resolved' issues.
> 
> The paper above talks about 'arch' but doesn't indicate if it's counting
> all arches, or just the one they run the tests on. (Coverity only covers x86,
> so arch/ shows up in 10th place there).

It's Coccinelle, so my guess is they ran it on all the .c files.

regards,
dan carpenter

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Dan Carpenter]

On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
>  > I was just reading http://faultlinux.lip6.fr/ which says that in
>  > 2011 the static checker fault rate in arch/ and fs/ was worse than
>  > in drivers/
> 
> I've been working on getting more regular builds in coverity, so we can
> get more meaningful statistics on things like "what area is getting worse".
> 
> Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> in terms of highest bug counts.
> 
> Drivers/net/wireless: 659 
> Drivers/ [1] : 600
> Drivers/staging: 449
> Drivers/scsi: 409
> Drivers/net: 350
> Net/[2] : 297
> Drivers/media: 286
> Sound: 220
> Drivers/GPU: 217
> 
> That's the top categories for the whole kernel.
> 
> That wireless was top of the list was the least shocking thing to me,
> based on what we get reported to Fedora bugzilla.  That it found more
> bugs there than in staging was amusing though. The good news is that
> wireless also takes the top slot for 'resolved' issues.
> 
> The paper above talks about 'arch' but doesn't indicate if it's counting
> all arches, or just the one they run the tests on. (Coverity only covers x86,
> so arch/ shows up in 10th place there).

It's Coccinelle, so my guess is they ran it on all the .c files.

regards,
dan carpenter

[Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Julia Lawall]

On Thu, 1 Aug 2013, Dan Carpenter wrote:

> On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> > On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
> >  > I was just reading http://faultlinux.lip6.fr/ which says that in
> >  > 2011 the static checker fault rate in arch/ and fs/ was worse than
> >  > in drivers/
> > 
> > I've been working on getting more regular builds in coverity, so we can
> > get more meaningful statistics on things like "what area is getting worse".
> > 
> > Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> > in terms of highest bug counts.
> > 
> > Drivers/net/wireless: 659 
> > Drivers/ [1] : 600
> > Drivers/staging: 449
> > Drivers/scsi: 409
> > Drivers/net: 350
> > Net/[2] : 297
> > Drivers/media: 286
> > Sound: 220
> > Drivers/GPU: 217
> > 
> > That's the top categories for the whole kernel.
> > 
> > That wireless was top of the list was the least shocking thing to me,
> > based on what we get reported to Fedora bugzilla.  That it found more
> > bugs there than in staging was amusing though. The good news is that
> > wireless also takes the top slot for 'resolved' issues.
> > 
> > The paper above talks about 'arch' but doesn't indicate if it's counting
> > all arches, or just the one they run the tests on. (Coverity only covers x86,
> > so arch/ shows up in 10th place there).
> 
> It's Coccinelle, so my guess is they ran it on all the .c files.

Coccinelle runs on all C files.  The rates in the paper are relative to 
what are referred to as notes, ie the number of potential bug sites.  
For example, code that does not use kmalloc is not likely to contain 
missing kfrees.

julia

Re: [Ksummit-2013-discuss] [ARM ATTEND] catching up on exploit mitigations

[Julia Lawall]

On Thu, 1 Aug 2013, Dan Carpenter wrote:

> On Thu, Aug 01, 2013 at 03:05:56PM -0400, Dave Jones wrote:
> > On Thu, Aug 01, 2013 at 12:13:22PM +0300, Dan Carpenter wrote:
> >  > I was just reading http://faultlinux.lip6.fr/ which says that in
> >  > 2011 the static checker fault rate in arch/ and fs/ was worse than
> >  > in drivers/
> > 
> > I've been working on getting more regular builds in coverity, so we can
> > get more meaningful statistics on things like "what area is getting worse".
> > 
> > Of the current bugs I've categorised so far, here's the breakdown for 3.11-rc3
> > in terms of highest bug counts.
> > 
> > Drivers/net/wireless: 659 
> > Drivers/ [1] : 600
> > Drivers/staging: 449
> > Drivers/scsi: 409
> > Drivers/net: 350
> > Net/[2] : 297
> > Drivers/media: 286
> > Sound: 220
> > Drivers/GPU: 217
> > 
> > That's the top categories for the whole kernel.
> > 
> > That wireless was top of the list was the least shocking thing to me,
> > based on what we get reported to Fedora bugzilla.  That it found more
> > bugs there than in staging was amusing though. The good news is that
> > wireless also takes the top slot for 'resolved' issues.
> > 
> > The paper above talks about 'arch' but doesn't indicate if it's counting
> > all arches, or just the one they run the tests on. (Coverity only covers x86,
> > so arch/ shows up in 10th place there).
> 
> It's Coccinelle, so my guess is they ran it on all the .c files.

Coccinelle runs on all C files.  The rates in the paper are relative to 
what are referred to as notes, ie the number of potential bug sites.  
For example, code that does not use kmalloc is not likely to contain 
missing kfrees.

julia

[ARM ATTEND] catching up on exploit mitigations

[Russell King - ARM Linux]

On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
> - vector table protections (needs to be protected like the x86_64
> vsyscall table, RO, etc)

(Dropped some mailing lists to reduce the visibility of this as its
soo close to the patches being merged...)

On the subject of this, those who are following what's going on at the
blackhat conference will be aware that there was a presentation
yesterday on this very subject.

Now that the presentation has been done, and the fixes are now merged
into Linus' tree, I can now talk about this.

There seems to be some confusion about the vector page - there are some
people who claim that the vector page is writable from userspace.  They
are simply wrong - no mainline kernel has ever had wriable vectors from
userspace.  That would be one hell of a big security hole.

However, there is a concern that the vector page reveals too much
information to userspace about the kernel, possibly giving away the
location of the syscall table, and whether the exposed code in that
page could be used to assist exploits of user applications - effectively
making ASLR useless.

This has been mitigated as much as reasonably possible; the signal
return code is now in a page which is placed randomly into the user
address space - and the signal handlers are placed randomly within
that page, and the page poisoned with a faulting instruction on both
ARM and Thumb.

The vector page is also poisoned in a similar manner; any attempt to
execute non-intentional code in that page will result in a SIGILL.

The code fragments which are jumped to by the instruction at the vector
location is now moved to a following page, which is inaccessible to
userspace.  All userspace can see there now is a set of branches to
the following page, not the branches into the kernel image.

The kuser helpers are an all together much bigger problem, because
they're part of our userspace ABI.  Don't go thinking that modern
builds don't call them, because they do, even when the builds are
optimised for ARMv7, as I can demonstrate with Ubuntu 12.04.1 ARMHF.
The get_tls helper still sees quite an amount of calls to it.

However, the option is given to the guy configuring the kernel to
disable these and make the vector page inaccessible to userspace.
When the page is made inaccessible to userspace, it becomes read-only
on the kernel side too.  The down side of this is the user ABI breakage,
so it can only be done _if_ you're sure that you have absolutely no
users of that stuff and none of your 3rd party stuff does either (iow,
think Android apps).

Some other solutions were considered, such as trapping faults to the
page and emulating the code that was there; given the amount of use
this stuff gets, I believe that would have a noticable performance
impact.  I also considered making the vectors page inaccessible to
userspace based on a kernel command line parameter - that's something
we can add if people want that.

As this issue in itself does not lead to the kernel being exploitable,
I view this as a fairly minor security issue; these patches are just
hardening the system against possible abuse, just like ASLR
theoretically makes it harder.

[ARM ATTEND] catching up on exploit mitigations

[Kees Cook]

On Fri, Aug 2, 2013 at 5:03 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote:
>> - vector table protections (needs to be protected like the x86_64
>> vsyscall table, RO, etc)
>
> (Dropped some mailing lists to reduce the visibility of this as its
> soo close to the patches being merged...)
>
> On the subject of this, those who are following what's going on at the
> blackhat conference will be aware that there was a presentation
> yesterday on this very subject.
>
> Now that the presentation has been done, and the fixes are now merged
> into Linus' tree, I can now talk about this.

This all sounds excellent. Thanks for working on it!

Do you see other areas that might need similar attention, or could
benefit from more hardening?

Thanks,

-Kees

-- 
Kees Cook
Chrome OS Security

[ARM ATTEND] catching up on exploit mitigations

[Laura Abbott]

On 7/30/2013 12:05 PM, Kees Cook wrote:
> I'd like to propose the topic of catching up to x86 exploit
> mitigations and security features, and potentially identifying
> ARM-unique mitigations/features that could be implemented. Several
> years ago, with Nicolas Pitre doing all the real work, I coordinated
> getting ARM caught up on things like userspace ASLR and
> stack-protector. Recently, based on work by Will Drewry, I ported
> seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
> think it's overdue to examine this area again. A lot of work has
> already been done by grsecurity in this area (see
> http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
> good to start there.
>
> While it may expose my current ignorance of low level ARM mechanics,
> I'd like to examine and discuss:
>
> - RO and W^X kernel page table protections (similar to x86's
> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> LPAE and PXN is already handling this, if at all)
>

We've had support for RO/NX on our tree for a while. I'm interested in 
attending the summit to share what we've done and to see how much of it 
could be mainlined.

> - something like x86's SMEP and SMAP (to deter kernel exploitation
> from userspace)
>
> - vector table protections (needs to be protected like the x86_64
> vsyscall table, RO, etc)
>
> - kernel ASLR (I'm close to having this upstreamable for x86)
>
> - fuzzing (is anyone running trinity or similar on the ARM tree?)
>
> - any other things ... ?

I'd add getting something similar to CONFIG_ARCH_RANDOM for ARM. It 
wouldn't be a direct drop in to x86 but we have some usecases for a 
framework to hook into the arch_get_random_{int,long}. This is mostly 
useful for cases where we need random numbers before the kernel's 
entropy source is completely initialized. The last point is a separate 
discussion all together.

>
> Thanks,
>
> -Kees
>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [ARM ATTEND] catching up on exploit mitigations

[Laura Abbott]

On 7/30/2013 12:05 PM, Kees Cook wrote:
> I'd like to propose the topic of catching up to x86 exploit
> mitigations and security features, and potentially identifying
> ARM-unique mitigations/features that could be implemented. Several
> years ago, with Nicolas Pitre doing all the real work, I coordinated
> getting ARM caught up on things like userspace ASLR and
> stack-protector. Recently, based on work by Will Drewry, I ported
> seccomp-bpf to ARM. I'd like to continue this kind of thing, and I
> think it's overdue to examine this area again. A lot of work has
> already been done by grsecurity in this area (see
> http://forums.grsecurity.net/viewtopic.php?f=7&t=3292), so it would be
> good to start there.
>
> While it may expose my current ignorance of low level ARM mechanics,
> I'd like to examine and discuss:
>
> - RO and W^X kernel page table protections (similar to x86's
> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> LPAE and PXN is already handling this, if at all)
>

We've had support for RO/NX on our tree for a while. I'm interested in 
attending the summit to share what we've done and to see how much of it 
could be mainlined.

> - something like x86's SMEP and SMAP (to deter kernel exploitation
> from userspace)
>
> - vector table protections (needs to be protected like the x86_64
> vsyscall table, RO, etc)
>
> - kernel ASLR (I'm close to having this upstreamable for x86)
>
> - fuzzing (is anyone running trinity or similar on the ARM tree?)
>
> - any other things ... ?

I'd add getting something similar to CONFIG_ARCH_RANDOM for ARM. It 
wouldn't be a direct drop in to x86 but we have some usecases for a 
framework to hook into the arch_get_random_{int,long}. This is mostly 
useful for cases where we need random numbers before the kernel's 
entropy source is completely initialized. The last point is a separate 
discussion all together.

>
> Thanks,
>
> -Kees
>

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[ARM ATTEND] catching up on exploit mitigations

[Mark Brown]

On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
> On 7/30/2013 12:05 PM, Kees Cook wrote:

> >- RO and W^X kernel page table protections (similar to x86's
> >DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> >LPAE and PXN is already handling this, if at all)

> We've had support for RO/NX on our tree for a while. I'm interested
> in attending the summit to share what we've done and to see how much
> of it could be mainlined.

Is that related to the code that Google have in their tree?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130826/124e3c20/attachment.sig>

Re: [ARM ATTEND] catching up on exploit mitigations

[Mark Brown]

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

On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
> On 7/30/2013 12:05 PM, Kees Cook wrote:

> >- RO and W^X kernel page table protections (similar to x86's
> >DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
> >LPAE and PXN is already handling this, if at all)

> We've had support for RO/NX on our tree for a while. I'm interested
> in attending the summit to share what we've done and to see how much
> of it could be mainlined.

Is that related to the code that Google have in their tree?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[ARM ATTEND] catching up on exploit mitigations

[Laura Abbott]

On 8/26/2013 12:56 PM, Mark Brown wrote:
> On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
>> On 7/30/2013 12:05 PM, Kees Cook wrote:
>
>>> - RO and W^X kernel page table protections (similar to x86's
>>> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
>>> LPAE and PXN is already handling this, if at all)
>
>> We've had support for RO/NX on our tree for a while. I'm interested
>> in attending the summit to share what we've done and to see how much
>> of it could be mainlined.
>
> Is that related to the code that Google have in their tree?

It's 'related' in that it covers some of the same use cases but the two 
were developed independently as far as I know.

Thanks,
Laura



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Re: [ARM ATTEND] catching up on exploit mitigations

[Laura Abbott]

On 8/26/2013 12:56 PM, Mark Brown wrote:
> On Mon, Aug 12, 2013 at 09:51:59PM -0700, Laura Abbott wrote:
>> On 7/30/2013 12:05 PM, Kees Cook wrote:
>
>>> - RO and W^X kernel page table protections (similar to x86's
>>> DEBUG_RODATA and DEBUG_SET_MODULE_RONX; it's not clear to me how much
>>> LPAE and PXN is already handling this, if at all)
>
>> We've had support for RO/NX on our tree for a while. I'm interested
>> in attending the summit to share what we've done and to see how much
>> of it could be mainlined.
>
> Is that related to the code that Google have in their tree?

It's 'related' in that it covers some of the same use cases but the two 
were developed independently as far as I know.

Thanks,
Laura



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation