[kernel-hardening] Self Introduction

[kernel-hardening] Self Introduction

[David Brown]

Per "Get Involved" on the Kernel Self Protection Project wiki, I'm
introducing myself.

I have recently joined Linaro on the Security Working Group.  As such,
I expect to seen be getting involved with the various kernel hardening
and related projects.

David Brown

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org> wrote:
> Per "Get Involved" on the Kernel Self Protection Project wiki, I'm
> introducing myself.
>
> I have recently joined Linaro on the Security Working Group.  As such,
> I expect to seen be getting involved with the various kernel hardening
> and related projects.

Hi David!

Welcome to the mailing list. :)

What sorts of things are you interested in working on?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[David Brown]

On Wed, Dec 09, 2015 at 02:19:24PM -0800, Kees Cook wrote:
>On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org> wrote:
>> Per "Get Involved" on the Kernel Self Protection Project wiki, I'm
>> introducing myself.
>>
>> I have recently joined Linaro on the Security Working Group.  As such,
>> I expect to seen be getting involved with the various kernel hardening
>> and related projects.
>
>Welcome to the mailing list. :)
>
>What sorts of things are you interested in working on?

A while back, I'd gone through each of the features in grsecurity and
PAX.  There were a number that seemed good from a security point of
view, but difficult in terms of culture within the kernel.  I've just
started up going through these again, as well as reading the kernel
hardening wiki, and I should soon have a better idea of what would be
good to work on.  My scope is broad enough that I want to get a good
idea of where others want to go as well, as well as what brings good
benefit.

I suspect part of the challenge is going to be clearly describing the
various features along with specific examples of already-discovered
exploits that the feature would have mitigated.

Most recently, I backported ARM PAN support to the Linaro stable
kernels (3.18 and 4.1).

David

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Wed, Dec 9, 2015 at 4:00 PM, David Brown <david.brown@linaro.org> wrote:
> On Wed, Dec 09, 2015 at 02:19:24PM -0800, Kees Cook wrote:
>>
>> On Wed, Dec 9, 2015 at 9:21 AM, David Brown <david.brown@linaro.org>
>> wrote:
>>>
>>> Per "Get Involved" on the Kernel Self Protection Project wiki, I'm
>>> introducing myself.
>>>
>>> I have recently joined Linaro on the Security Working Group.  As such,
>>> I expect to seen be getting involved with the various kernel hardening
>>> and related projects.
>>
>>
>> Welcome to the mailing list. :)
>>
>> What sorts of things are you interested in working on?
>
>
> A while back, I'd gone through each of the features in grsecurity and
> PAX.  There were a number that seemed good from a security point of
> view, but difficult in terms of culture within the kernel.  I've just
> started up going through these again, as well as reading the kernel
> hardening wiki, and I should soon have a better idea of what would be
> good to work on.  My scope is broad enough that I want to get a good
> idea of where others want to go as well, as well as what brings good
> benefit.

Great! It might be valuable to read through this mailing lists's
threads over the last month. We discuss a few of the features and some
work has been started.

> I suspect part of the challenge is going to be clearly describing the
> various features along with specific examples of already-discovered
> exploits that the feature would have mitigated.

Yes indeed. :) That's why I've arranged the wiki the way I did:
classes and methods first, with potential solutions listed under them.
We want to start with problem descriptions and work from actual
exploits when possible.

This is why the recent x86 VDSO attack was very timely: it
demonstrates cleanly why we want __ro_after_init (née __read_only) in
upstream. (As well as the constification plugin.)

> Most recently, I backported ARM PAN support to the Linaro stable
> kernels (3.18 and 4.1).

Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very
nice to have a UDEREF-like feature on arm. It's too bad this doesn't
exist for Intel yet, but I'm hoping they'll step up.

For 3.18, is this the right place to be looking?
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18

I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel too.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[David Brown]

On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:

>Great! It might be valuable to read through this mailing lists's
>threads over the last month. We discuss a few of the features and some
>work has been started.

Reading through stuff now.  Looks like the list got quite a boost in
November.

>> I suspect part of the challenge is going to be clearly describing the
>> various features along with specific examples of already-discovered
>> exploits that the feature would have mitigated.
>
>Yes indeed. :) That's why I've arranged the wiki the way I did:
>classes and methods first, with potential solutions listed under them.
>We want to start with problem descriptions and work from actual
>exploits when possible.
>
>This is why the recent x86 VDSO attack was very timely: it
>demonstrates cleanly why we want __ro_after_init (née __read_only) in
>upstream. (As well as the constification plugin.)

Which also seems like this will be quite useful on ARM as well.  Do
you know any efforts to do this?

>> Most recently, I backported ARM PAN support to the Linaro stable
>> kernels (3.18 and 4.1).
>
>Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very
>nice to have a UDEREF-like feature on arm. It's too bad this doesn't
>exist for Intel yet, but I'm hoping they'll step up.
>
>For 3.18, is this the right place to be looking?
>https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18

It will be once it gets through testing.
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN
to peek before then.  There's also
https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN
for the 4.1 tree.

Should I CC kernel-hardening when sending patches for the Linaro
stable kernels?

>I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel too.

I'll put this on my list to investigate.  Sadly, it looks like there
is a bit of a window of ARM CPUs where neither solution will work;
Basically the pre V8.1 64-bit.

In fact, I don't have any hardware yet that supports PAN.  I've done
all of the testing in emulation.

David

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
>
>> Great! It might be valuable to read through this mailing lists's
>> threads over the last month. We discuss a few of the features and some
>> work has been started.
>
>
> Reading through stuff now.  Looks like the list got quite a boost in
> November.
>
>>> I suspect part of the challenge is going to be clearly describing the
>>> various features along with specific examples of already-discovered
>>> exploits that the feature would have mitigated.
>>
>>
>> Yes indeed. :) That's why I've arranged the wiki the way I did:
>> classes and methods first, with potential solutions listed under them.
>> We want to start with problem descriptions and work from actual
>> exploits when possible.
>>
>> This is why the recent x86 VDSO attack was very timely: it
>> demonstrates cleanly why we want __ro_after_init (née __read_only) in
>> upstream. (As well as the constification plugin.)
>
>
> Which also seems like this will be quite useful on ARM as well.  Do
> you know any efforts to do this?

I've not seen any yet. If you get it written, I can include it in my
__ro_after_init series on the next revision.

>>> Most recently, I backported ARM PAN support to the Linaro stable
>>> kernels (3.18 and 4.1).
>>
>>
>> Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very
>> nice to have a UDEREF-like feature on arm. It's too bad this doesn't
>> exist for Intel yet, but I'm hoping they'll step up.
>>
>> For 3.18, is this the right place to be looking?
>>
>> https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18
>
>
> It will be once it gets through testing.
> https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN
> to peek before then.  There's also
> https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN
> for the 4.1 tree.

Oh! I see now. You meant hardware PAN support. Yes, also good to get
in for the arm64 devices. I meant the CONFIG_CPU_SW_DOMAIN_PAN
support. I've backported that from 4.3 to 4.1 since then all arm
devices would gain PAN-like support too.

> Should I CC kernel-hardening when sending patches for the Linaro
> stable kernels?

Probably not for stable backports. I think upstream development things
probably should be, and we can certainly discuss stuff that looks like
it'd be good to backport, but I wouldn't want to bore people with
patch for old kernels. :)

>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
>> too.
>
> I'll put this on my list to investigate.  Sadly, it looks like there
> is a bit of a window of ARM CPUs where neither solution will work;
> Basically the pre V8.1 64-bit.

The LPAE support for PAN emulation exists in grsecurity, if someone
wanted to look at how to extract it and add it to
CONFIG_CPU_SW_DOMAIN_PAN (or similar).

> In fact, I don't have any hardware yet that supports PAN.  I've done
> all of the testing in emulation.

Heh, yeah, that's how the x86 SMAP stuff is too. ;)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Stephen Smalley]

On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
>>> too.
>>
>> I'll put this on my list to investigate.  Sadly, it looks like there
>> is a bit of a window of ARM CPUs where neither solution will work;
>> Basically the pre V8.1 64-bit.
>
> The LPAE support for PAN emulation exists in grsecurity, if someone
> wanted to look at how to extract it and add it to
> CONFIG_CPU_SW_DOMAIN_PAN (or similar).

Are you looking for this:
http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2

Haven't seen any follow up on it though...

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley
<stephen.smalley@gmail.com> wrote:
> On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
>>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
>>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
>>>> too.
>>>
>>> I'll put this on my list to investigate.  Sadly, it looks like there
>>> is a bit of a window of ARM CPUs where neither solution will work;
>>> Basically the pre V8.1 64-bit.
>>
>> The LPAE support for PAN emulation exists in grsecurity, if someone
>> wanted to look at how to extract it and add it to
>> CONFIG_CPU_SW_DOMAIN_PAN (or similar).
>
> Are you looking for this:
> http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2
>
> Haven't seen any follow up on it though...

Ah yes! Thank you!

https://patchwork.kernel.org/patch/7250401/
https://patchwork.kernel.org/patch/7250391/
https://patchwork.kernel.org/patch/7250421/
https://patchwork.kernel.org/patch/7250441/

Catalin, where does this stand? Also, what options do ARMv8 (not
ARMv8.1) devices have for PAN if they're running 64-bit?

The matrix for PAN seems to be:

ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN
ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)
ARMv8 32-bit: Catalin's series?
ARMv8 64-bit: ??
ARMv8.1: hardware PAN
x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
x86 Broadwell+: hardware PAN (SMAP)
powerpc: ??
MIPS: ??

Corrections appreciated. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Daniel Micay]

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

> ARMv8 64-bit: ??

The worst case scenario would be doing something like the x86_64 UDEREF.

> x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)

It's worth noting that there's the pre-PCID implementation (slow and
vulnerable to races) and then two choices of better implementations when
PCID is available. You probably know that already, but it's not obvious
to everyone else.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Self Introduction

[Catalin Marinas]

On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote:
> On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley
> <stephen.smalley@gmail.com> wrote:
> > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote:
> >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
> >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
> >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
> >>>> too.
> >>>
> >>> I'll put this on my list to investigate.  Sadly, it looks like there
> >>> is a bit of a window of ARM CPUs where neither solution will work;
> >>> Basically the pre V8.1 64-bit.
> >>
> >> The LPAE support for PAN emulation exists in grsecurity, if someone
> >> wanted to look at how to extract it and add it to
> >> CONFIG_CPU_SW_DOMAIN_PAN (or similar).
> >
> > Are you looking for this:
> > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2
> >
> > Haven't seen any follow up on it though...
> 
> Ah yes! Thank you!
> 
> https://patchwork.kernel.org/patch/7250401/
> https://patchwork.kernel.org/patch/7250391/
> https://patchwork.kernel.org/patch/7250421/
> https://patchwork.kernel.org/patch/7250441/
> 
> Catalin, where does this stand?

I haven't done any further improvements to them, nor have I received any
feedback. I'll rebase them against latest kernel if anyone else is
willing to test. I had a plan to run some benchmarks and see how
performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
again for upstreaming but I haven't had the time.

> Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if
> they're running 64-bit?

No PAN support for ARMv8.0. It could be done similarly to the 32-bit
LPAE support.

> The matrix for PAN seems to be:
> 
> ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN
> ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)

Correct.

> ARMv8 32-bit: Catalin's series?

ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32
kernel.

> ARMv8 64-bit: ??

None.

> ARMv8.1: hardware PAN

Correct.

-- 
Catalin

Re: [kernel-hardening] Self Introduction

[Kees Cook]

I've put the matrix up on the wiki here:

http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

On Thu, Dec 10, 2015 at 9:55 AM, Daniel Micay <danielmicay@gmail.com> wrote:
>> ARMv8 64-bit: ??
>
> The worst case scenario would be doing something like the x86_64 UDEREF.
>
>> x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
>
> It's worth noting that there's the pre-PCID implementation (slow and
> vulnerable to races) and then two choices of better implementations when
> PCID is available. You probably know that already, but it's not obvious
> to everyone else.

Yeah. PCID was Sandybridge and later?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Thu, Dec 10, 2015 at 10:42 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote:
>> On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley
>> <stephen.smalley@gmail.com> wrote:
>> > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote:
>> >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
>> >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
>> >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
>> >>>> too.
>> >>>
>> >>> I'll put this on my list to investigate.  Sadly, it looks like there
>> >>> is a bit of a window of ARM CPUs where neither solution will work;
>> >>> Basically the pre V8.1 64-bit.
>> >>
>> >> The LPAE support for PAN emulation exists in grsecurity, if someone
>> >> wanted to look at how to extract it and add it to
>> >> CONFIG_CPU_SW_DOMAIN_PAN (or similar).
>> >
>> > Are you looking for this:
>> > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2
>> >
>> > Haven't seen any follow up on it though...
>>
>> Ah yes! Thank you!
>>
>> https://patchwork.kernel.org/patch/7250401/
>> https://patchwork.kernel.org/patch/7250391/
>> https://patchwork.kernel.org/patch/7250421/
>> https://patchwork.kernel.org/patch/7250441/
>>
>> Catalin, where does this stand?
>
> I haven't done any further improvements to them, nor have I received any
> feedback. I'll rebase them against latest kernel if anyone else is
> willing to test. I had a plan to run some benchmarks and see how
> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> again for upstreaming but I haven't had the time.

Please CC this mailing list when you do. I'd like to give it a spin
(and maybe other folks will too).

>> Also, what options do ARMv8 (not ARMv8.1) devices have for PAN if
>> they're running 64-bit?
>
> No PAN support for ARMv8.0. It could be done similarly to the 32-bit
> LPAE support.
>
>> The matrix for PAN seems to be:
>>
>> ARMv7 32-bit non-LPAE: CONFIG_CPU_SW_DOMAIN_PAN
>> ARMv7 32-bit LPAE: Catalin's series (CPU_TTBR0_PAN)
>
> Correct.
>
>> ARMv8 32-bit: Catalin's series?
>
> ARMv8 32-bit is backwards compatible with ARMv7, so the same arm32
> kernel.
>
>> ARMv8 64-bit: ??
>
> None.
>
>> ARMv8.1: hardware PAN
>
> Correct.

Excellent, thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Daniel Micay]

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

> Yeah. PCID was Sandybridge and later?

Yeah, that's right. And it defaults to the strong PCID implementation,
but there's also a weaker but significantly faster PCID-based one.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> wrote:
>> Yeah. PCID was Sandybridge and later?
>
> Yeah, that's right. And it defaults to the strong PCID implementation,
> but there's also a weaker but significantly faster PCID-based one.

Is there anyone from Intel on the list? I would love to see UDEREF
ported to upstream on x86 (and the non PCID version too). No one has
stepped up to work on it yet.

As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd
love to update the matrix for powerpc and MIPS.

http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

RE: [kernel-hardening] Self Introduction

[Schaufler, Casey]

> -----Original Message-----
> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of
> Kees Cook
> Sent: Thursday, December 10, 2015 11:24 AM
> To: kernel-hardening@lists.openwall.com
> Cc: Catalin Marinas <catalin.marinas@arm.com>; PaX Team
> <pageexec@freemail.hu>; Michael Ellerman <mpe@ellerman.id.au>; Heiko
> Carstens <heiko.carstens@de.ibm.com>; Ralf Baechle <ralf@linux-mips.org>
> Subject: Re: [kernel-hardening] Self Introduction
> 
> On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com>
> wrote:
> >> Yeah. PCID was Sandybridge and later?
> >
> > Yeah, that's right. And it defaults to the strong PCID implementation,
> > but there's also a weaker but significantly faster PCID-based one.
> 
> Is there anyone from Intel on the list? I would love to see UDEREF
> ported to upstream on x86 (and the non PCID version too). No one has
> stepped up to work on it yet.

Yes, we're here. There are a couple things we need to do before making
commitments on things, including deciding which are the most urgent
from our perspective. We will be looking at what we want to do with
UDEREF.

> As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd
> love to update the matrix for powerpc and MIPS.
> 
> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
> 
> -Kees
> 
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey
<casey.schaufler@intel.com> wrote:
>> -----Original Message-----
>> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of
>> Kees Cook
>> Sent: Thursday, December 10, 2015 11:24 AM
>> To: kernel-hardening@lists.openwall.com
>> Cc: Catalin Marinas <catalin.marinas@arm.com>; PaX Team
>> <pageexec@freemail.hu>; Michael Ellerman <mpe@ellerman.id.au>; Heiko
>> Carstens <heiko.carstens@de.ibm.com>; Ralf Baechle <ralf@linux-mips.org>
>> Subject: Re: [kernel-hardening] Self Introduction
>>
>> On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com>
>> wrote:
>> >> Yeah. PCID was Sandybridge and later?
>> >
>> > Yeah, that's right. And it defaults to the strong PCID implementation,
>> > but there's also a weaker but significantly faster PCID-based one.
>>
>> Is there anyone from Intel on the list? I would love to see UDEREF
>> ported to upstream on x86 (and the non PCID version too). No one has
>> stepped up to work on it yet.
>
> Yes, we're here. There are a couple things we need to do before making
> commitments on things, including deciding which are the most urgent
> from our perspective. We will be looking at what we want to do with
> UDEREF.

That's great! Thanks for speaking up. Another area that hasn't seen
any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love
to see someone else take on that chunk of work.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[PaX Team]

On 10 Dec 2015 at 10:42, Kees Cook wrote:

> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
> 
> On Thu, Dec 10, 2015 at 9:55 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> >> ARMv8 64-bit: ??
> >
> > The worst case scenario would be doing something like the x86_64 UDEREF.
> >
> >> x86 pre-late-Broadwell: nothing upstream (though UDEREF in PaX exists)
> >
> > It's worth noting that there's the pre-PCID implementation (slow and
> > vulnerable to races)

uhm, what races? the per-cpu PGD exists for that reason, regardless of PCID.

> > and then two choices of better implementations when
> > PCID is available. You probably know that already, but it's not obvious
> > to everyone else.
> 
> Yeah. PCID was Sandybridge and later?

IIRC, it is more like Westmere and later.

Re: [kernel-hardening] Self Introduction

[Daniel Micay]

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

> uhm, what races? the per-cpu PGD exists for that reason, regardless of
> PCID.

Ah, that makes sense. So the non-strong PCID UDEREF is really just
hardware acceleration for what you were already doing before.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Thu, Dec 10, 2015 at 10:42 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Dec 10, 2015 at 09:49:13AM -0800, Kees Cook wrote:
>> On Thu, Dec 10, 2015 at 9:14 AM, Stephen Smalley
>> <stephen.smalley@gmail.com> wrote:
>> > On Wed, Dec 9, 2015 at 7:41 PM, Kees Cook <keescook@chromium.org> wrote:
>> >> On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@linaro.org> wrote:
>> >>> On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote:
>> >>>> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel
>> >>>> too.
>> >>>
>> >>> I'll put this on my list to investigate.  Sadly, it looks like there
>> >>> is a bit of a window of ARM CPUs where neither solution will work;
>> >>> Basically the pre V8.1 64-bit.
>> >>
>> >> The LPAE support for PAN emulation exists in grsecurity, if someone
>> >> wanted to look at how to extract it and add it to
>> >> CONFIG_CPU_SW_DOMAIN_PAN (or similar).
>> >
>> > Are you looking for this:
>> > http://marc.info/?l=linux-arm-kernel&m=144308911409429&w=2
>> >
>> > Haven't seen any follow up on it though...
>>
>> Ah yes! Thank you!
>>
>> https://patchwork.kernel.org/patch/7250401/
>> https://patchwork.kernel.org/patch/7250391/
>> https://patchwork.kernel.org/patch/7250421/
>> https://patchwork.kernel.org/patch/7250441/
>>
>> Catalin, where does this stand?
>
> I haven't done any further improvements to them, nor have I received any
> feedback. I'll rebase them against latest kernel if anyone else is
> willing to test. I had a plan to run some benchmarks and see how
> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> again for upstreaming but I haven't had the time.

David, getting back to something that might good to get your help
with: would you be able to test Catalin's LPAE TTBR0 PAN series on
real hardware? (Are you familiar with the LKDTM tests for this[1]?)

-Kees

[1] http://lwn.net/Articles/663531/ specifically ACCESS_USERSPACE and
EXEC_USERSPACE

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[David Brown]

On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:

>David, getting back to something that might good to get your help
>with: would you be able to test Catalin's LPAE TTBR0 PAN series on
>real hardware? (Are you familiar with the LKDTM tests for this[1]?)

I was planning on this.  It's probably going to be a little while (as
in January) before I have any reasonable hardware to test things on,
though.  I have one board I need to get working, and another is in the
mail.  Both, however, are A53-based, which gets all of the other
configurations.  I'll see if I can figure out how to get access to our
test infrastructure.

I am familiar with LKDTM, and it's how I was able to test PAN easily.

Thanks,
David

Re: [kernel-hardening] Self Introduction

[Valdis.Kletnieks]

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

On Thu, 10 Dec 2015 11:45:35 -0800, Kees Cook said:
> On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey

> That's great! Thanks for speaking up. Another area that hasn't seen
> any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love
> to see someone else take on that chunk of work.

Whoops. sorry.. I just didn't have anything in a state ready to share,
and I got sidetracked by a week in the hospital (am all OK now, thankfully).

Biggest problem is just taking one big 7M patch and teasing out just the
USERCOPY parts, and then re-arranging it into something that upstream will
be willing to take.  Just lots and lots of grunt work.

I don't suppose the grsecurity guys have a git repo where a lot of the
heavy duty lifting is already done? :)

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

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Fri, Dec 11, 2015 at 9:54 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 10 Dec 2015 11:45:35 -0800, Kees Cook said:
>> On Thu, Dec 10, 2015 at 11:38 AM, Schaufler, Casey
>
>> That's great! Thanks for speaking up. Another area that hasn't seen
>> any traction yet is PAX_USERCOPY. Valdis seems to be MIA, so I'd love
>> to see someone else take on that chunk of work.
>
> Whoops. sorry.. I just didn't have anything in a state ready to share,
> and I got sidetracked by a week in the hospital (am all OK now, thankfully).

Yikes! Glad you're okay. If other people have more time to dedicate to
PAX_USERCOPY extraction, maybe you could help with testing? Or what do
you think?

> Biggest problem is just taking one big 7M patch and teasing out just the
> USERCOPY parts, and then re-arranging it into something that upstream will
> be willing to take.  Just lots and lots of grunt work.

Yup, that's the first step in the work. Well, first is extraction,
then figuring out the best way to upstream.

> I don't suppose the grsecurity guys have a git repo where a lot of the
> heavy duty lifting is already done? :)

AIUI, no such thing exists. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Heiko Carstens]

On Thu, Dec 10, 2015 at 11:23:34AM -0800, Kees Cook wrote:
> On Thu, Dec 10, 2015 at 11:07 AM, Daniel Micay <danielmicay@gmail.com> wrote:
> >> Yeah. PCID was Sandybridge and later?
> >
> > Yeah, that's right. And it defaults to the strong PCID implementation,
> > but there's also a weaker but significantly faster PCID-based one.
> 
> Is there anyone from Intel on the list? I would love to see UDEREF
> ported to upstream on x86 (and the non PCID version too). No one has
> stepped up to work on it yet.
> 
> As for non-ARM and non-x86, IIRC s/390 has always had PAN, and I'd
> love to update the matrix for powerpc and MIPS.
> 
> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

The statement for s390 is correct: we always had PAN in use. It's a
hardware feature simply called "Address Spaces".

The way we use it in Linux on s390 makes is impossible to access user space
contents from kernel space without special instructions.

Re: [kernel-hardening] Self Introduction

[David Brown]

On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:

>> I haven't done any further improvements to them, nor have I received any
>> feedback. I'll rebase them against latest kernel if anyone else is
>> willing to test. I had a plan to run some benchmarks and see how
>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
>> again for upstreaming but I haven't had the time.
>
>David, getting back to something that might good to get your help
>with: would you be able to test Catalin's LPAE TTBR0 PAN series on
>real hardware? (Are you familiar with the LKDTM tests for this[1]?)

Sorry for the delay in getting back to you.  Been both moving and
taking vacation.

I'd like to test this.  I'm just trying to see if I can track down
some hardware that'll boot LPAE.

Thanks,
David

Re: [kernel-hardening] Self Introduction

[Kees Cook]

On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
>
>>> I haven't done any further improvements to them, nor have I received any
>>> feedback. I'll rebase them against latest kernel if anyone else is
>>> willing to test. I had a plan to run some benchmarks and see how
>>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
>>> again for upstreaming but I haven't had the time.
>>
>>
>> David, getting back to something that might good to get your help
>> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
>> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
>
>
> Sorry for the delay in getting back to you.  Been both moving and
> taking vacation.
>
> I'd like to test this.  I'm just trying to see if I can track down
> some hardware that'll boot LPAE.

Awesome! Thanks for the update.

Catalin, did you end up figuring out if your TTBR0 stuff was correct?
You'd mentioned you needed to check something about the
implementation?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Self Introduction

[Catalin Marinas]

+ rmk

On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote:
> On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
> >
> >>> I haven't done any further improvements to them, nor have I received any
> >>> feedback. I'll rebase them against latest kernel if anyone else is
> >>> willing to test. I had a plan to run some benchmarks and see how
> >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> >>> again for upstreaming but I haven't had the time.
> >>
> >>
> >> David, getting back to something that might good to get your help
> >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
> >> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
> >
> >
> > Sorry for the delay in getting back to you.  Been both moving and
> > taking vacation.
> >
> > I'd like to test this.  I'm just trying to see if I can track down
> > some hardware that'll boot LPAE.
> 
> Awesome! Thanks for the update.
> 
> Catalin, did you end up figuring out if your TTBR0 stuff was correct?
> You'd mentioned you needed to check something about the
> implementation?

Unfortunately, I checked with the ARM architecture folk. While the trick
is probably fine on existing hardware, the architecture allows caching
of the TTBCR bits (or their effect) in the TLB. Therefore changing the
TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed
to have an effect until the TLBs are invalidated. CPU implementations
are allowed to rely on this, so we can't safely use it in Linux.

The minor side effect is that the PAN may not always work. We could
invalidate the TLBs at every PAN change and take a significant
performance hit. However, the more serious side effect is that TLB
conflicts may happen, leading to aborts (though unlikely on existing
hardware but we can't guarantee it for the future). The latter can't be
avoided (only reduce) by more TLB invalidation (the proper fix would be
MMU disabling).

In conclusion, I'm NAK'ing my own patch ;). The alternative is to make
TTBR0 point to swapper_pg_dir where there are no user mappings. The
difficulty is that such patch won't fit nicely onto the existing
uaccess_* macros that rmk added. It also doesn't work well with
switch_mm(), we would have to defer the TTBR0 setting until returning to
user space (cpu_switch_mm() should no longer be called in
check_and_switch_context() as it automatically enables privileged access
to user).

I haven't had time to look into re-writing the patch. Hopefully sometime
in February, unless someone else volunteers to take over.

Question for Russell: do we have any guarantees that lowmem doesn't
cross a 32-bit boundary? This would simplify the code a bit by
preserving the top 32-bit of TTBR0 when changing. But looking at the
sanity_check_meminfo(), I couldn't see anything that would guarantee
this. Even the virt_to_phys() macro does a carry add for the top 32-bit.

-- 
Catalin

Re: [kernel-hardening] Self Introduction

[Catalin Marinas]

+ rmk (actually cc'ing him this time)

On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote:
> On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
> >
> >>> I haven't done any further improvements to them, nor have I received any
> >>> feedback. I'll rebase them against latest kernel if anyone else is
> >>> willing to test. I had a plan to run some benchmarks and see how
> >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> >>> again for upstreaming but I haven't had the time.
> >>
> >>
> >> David, getting back to something that might good to get your help
> >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
> >> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
> >
> >
> > Sorry for the delay in getting back to you.  Been both moving and
> > taking vacation.
> >
> > I'd like to test this.  I'm just trying to see if I can track down
> > some hardware that'll boot LPAE.
> 
> Awesome! Thanks for the update.
> 
> Catalin, did you end up figuring out if your TTBR0 stuff was correct?
> You'd mentioned you needed to check something about the
> implementation?

Unfortunately, I checked with the ARM architecture folk. While the trick
is probably fine on existing hardware, the architecture allows caching
of the TTBCR bits (or their effect) in the TLB. Therefore changing the
TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed
to have an effect until the TLBs are invalidated. CPU implementations
are allowed to rely on this, so we can't safely use it in Linux.

The minor side effect is that the PAN may not always work. We could
invalidate the TLBs at every PAN change and take a significant
performance hit. However, the more serious side effect is that TLB
conflicts may happen, leading to aborts (though unlikely on existing
hardware but we can't guarantee it for the future). The latter can't be
avoided (only reduce) by more TLB invalidation (the proper fix would be
MMU disabling).

In conclusion, I'm NAK'ing my own patch ;). The alternative is to make
TTBR0 point to swapper_pg_dir where there are no user mappings. The
difficulty is that such patch won't fit nicely onto the existing
uaccess_* macros that rmk added. It also doesn't work well with
switch_mm(), we would have to defer the TTBR0 setting until returning to
user space (cpu_switch_mm() should no longer be called in
check_and_switch_context() as it automatically enables privileged access
to user).

I haven't had time to look into re-writing the patch. Hopefully sometime
in February, unless someone else volunteers to take over.

Question for Russell: do we have any guarantees that lowmem doesn't
cross a 32-bit boundary? This would simplify the code a bit by
preserving the top 32-bit of TTBR0 when changing. But looking at the
sanity_check_meminfo(), I couldn't see anything that would guarantee
this. Even the virt_to_phys() macro does a carry add for the top 32-bit.

-- 
Catalin

Re: [kernel-hardening] Self Introduction

[Ben Hutchings]

On Wed, 2016-01-13 at 11:31 +0000, Catalin Marinas wrote:
> + rmk (actually cc'ing him this time)
> 
> On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote:
> > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
> > >
> > >>> I haven't done any further improvements to them, nor have I received any
> > >>> feedback. I'll rebase them against latest kernel if anyone else is
> > >>> willing to test. I had a plan to run some benchmarks and see how
> > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> > >>> again for upstreaming but I haven't had the time.
> > >>
> > >>
> > >> David, getting back to something that might good to get your help
> > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
> > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
> > >
> > >
> > > Sorry for the delay in getting back to you.  Been both moving and
> > > taking vacation.
> > >
> > > I'd like to test this.  I'm just trying to see if I can track down
> > > some hardware that'll boot LPAE.
> > 
> > Awesome! Thanks for the update.
> > 
> > Catalin, did you end up figuring out if your TTBR0 stuff was correct?
> > You'd mentioned you needed to check something about the
> > implementation?
> 
> Unfortunately, I checked with the ARM architecture folk. While the trick
> is probably fine on existing hardware, the architecture allows caching
> of the TTBCR bits (or their effect) in the TLB. Therefore changing the
> TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed
> to have an effect until the TLBs are invalidated. CPU implementations
> are allowed to rely on this, so we can't safely use it in Linux.
[...]

Could you whitelist the cores where this is known to work as intended?
Or is it not practical to enable/disable this PAN implementation at boot
time?

Ben.

Re: [kernel-hardening] Self Introduction

[Catalin Marinas]

On Thu, Jan 14, 2016 at 01:04:38AM +0000, Ben Hutchings wrote:
> On Wed, 2016-01-13 at 11:31 +0000, Catalin Marinas wrote:
> > On Tue, Jan 12, 2016 at 11:31:50AM -0800, Kees Cook wrote:
> > > On Mon, Jan 11, 2016 at 10:33 AM, David Brown <david.brown@linaro.org> wrote:
> > > > On Thu, Dec 10, 2015 at 03:52:16PM -0800, Kees Cook wrote:
> > > >
> > > >>> I haven't done any further improvements to them, nor have I received any
> > > >>> feedback. I'll rebase them against latest kernel if anyone else is
> > > >>> willing to test. I had a plan to run some benchmarks and see how
> > > >>> performance is affected (including the CPU_SW_DOMAIN_PAN) before pushing
> > > >>> again for upstreaming but I haven't had the time.
> > > >>
> > > >>
> > > >> David, getting back to something that might good to get your help
> > > >> with: would you be able to test Catalin's LPAE TTBR0 PAN series on
> > > >> real hardware? (Are you familiar with the LKDTM tests for this[1]?)
> > > >
> > > >
> > > > Sorry for the delay in getting back to you.  Been both moving and
> > > > taking vacation.
> > > >
> > > > I'd like to test this.  I'm just trying to see if I can track down
> > > > some hardware that'll boot LPAE.
> > > 
> > > Awesome! Thanks for the update.
> > > 
> > > Catalin, did you end up figuring out if your TTBR0 stuff was correct?
> > > You'd mentioned you needed to check something about the
> > > implementation?
> > 
> > Unfortunately, I checked with the ARM architecture folk. While the trick
> > is probably fine on existing hardware, the architecture allows caching
> > of the TTBCR bits (or their effect) in the TLB. Therefore changing the
> > TTBCR.EPD0 (or A1) to disable TTBR0 page table walks is not guaranteed
> > to have an effect until the TLBs are invalidated. CPU implementations
> > are allowed to rely on this, so we can't safely use it in Linux.
> [...]
> 
> Could you whitelist the cores where this is known to work as intended?

Even this information is hard to get accurately. You would have to ask
the micro-architects (and not all are ARM Ltd) about the details as
these are not usually publicly available. So in Linux we aim as much as
possible to stick to the architecture specification rather than
individual implementations, with a few exceptions for features
documented in the CPU TRM (or errata docs).

> Or is it not practical to enable/disable this PAN implementation at boot
> time?

Some boot-time code patching may do but we should rather do it properly
by using a reserved TTBR0.

-- 
Catalin

Re: [kernel-hardening] self introduction

[Kees Cook]

On Tue, Oct 18, 2016 at 4:52 AM, Gengjia Chen <chengjia4574@gmail.com> wrote:
>> >2016-10-18 4:15 GMT+08:00 Kees Cook <keescook@chromium.org>:
>> >The ARM open/close depends on their use of Domains. For upstream,
>> >you'd have to examine how Domains are being used (which seems
>> >different to me).
>>
>> So, I will try to start to port pax_open_kernel/pax_close_kernel
>> arm-specific features to upstream, and keep you in touch.

Cool, feel free to post RFC patches even if they're not totally finished. :)

>> >The other work is building the in-kernel
>> >infrastructure to support write-rarely memory (likely a new section,
>> >like ro_after_init, etc).
>> >
>>
>> It seems that the constify plugin still not been ported to the lastest
>> code (v4.9-rc1),
>> If I understand, you means that a new section should be added
>> to the upstream , and cooperate with the future constify plugin (the
>> plugin automatically put those objects to that section ) ?

It hasn't been forward-ported, no, but building out the infrastructure
to support it in upstream will be needed regardless. In PaX, the
section is called .data..read_only, but I suspect that will turn out
to be a confusing name, since it's actually "write-rarely", but lives
in the .rodata section, and the open/close implementation will be used
to write to it.

The constify plugin actually moves variables into the .rodata section,
so not only does any code writing to such things need to be wrapped in
open/close calls, but the C compiler needs to be tricked into
generating sensible code (see PaX's const_cast() macro).

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Gengjia Chen]

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

>
>
>
> >2016-10-18 4:15 GMT+08:00 Kees Cook <keescook@chromium.org>:
> >On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen <chengjia4574@gmail.com>
> wrote:
> >>>>> In your research have you seen a common kind of bug that results in
> >>>>> the vulnerabilities you find?
> >>>>
> >>>> No,
> >>>> Most of those issues are caused by the lack of checking of  user input
> >>>> length
> >>>> in copy_xx_user functions or afterwards in memcpy functions,
> >>>> however, looking into the details,
> >>>> they vary among different functions in different files.
> >>>
> >>>Cool, I hope the recent hardened usercopy stuff will improve that
> >>>situation, though there is plenty left to do.
> >>>
> >>>>> Is there anything that would have
> >>>>> significantly made exploitation more difficult in the things you
> >>>>> worked on?
> >>>>
> >>>> Yes!
> >>>>
> >>>> I mostly exploit buffer overflow vulns by overwrite function pointers
> >>>> (such
> >>>> as
> >>>> pointers in file_operations) of a global object or a heap object
> >>>> to redirect execution (and if PXN is enable, we simply use rop
> gadgets).
> >>>> Therefore mitigation solutions of Function_pointer_overwrite  would
> >>>> make such kind of exploitation much more diffcult.
> >>>> But I don't know if you have let all the pointers "const".
> >>>
> >>>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel()
> >>>combined with the constify plugin would vastly improve the function
> >>>tables that could be const in the kernel. Perhaps that's something you
> >>>could look at: porting the pax_open_kernel()/pax_close_kernel()
> >>>infrastructure on ARM to upstream?
> >>>
> >>
> >> I found that pax_open_kernel()/pax_close_kernel() infrastructure
> >> had been ported on ARM in patch
> >> grsecurity-3.1-4.7.8-201610161720.patch, as follow:
> >>
> >> file: arch/arm/include/asm/pgtable.h
> >>
> >> #ifdef CONFIG_PAX_KERNEXEC
> >> static inline unsigned long pax_open_kernel(void) {
> >> #ifdef CONFIG_ARM_LPAE
> >>         /* TODO */
> >> #else
> >>         preempt_disable();
> >>         BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC));
> >>         modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC);
> >> #endif
> >>         return 0;
> >> }
> >>
> >> static inline unsigned long pax_close_kernel(void) {
> >> #ifdef CONFIG_ARM_LPAE
> >>         /* TODO */
> >> #else
> >>         BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER));
> >>         /* DOMAIN_MANAGER = "client" under KERNEXEC */
> >>         modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER);
> >>         preempt_enable_no_resched();
> >> #endif
> >>         return 0;
> >> }
> >> #else
> >> static inline unsigned long pax_open_kernel(void) { return 0; }
> >> static inline unsigned long pax_close_kernel(void) { return 0; }
> >> #endif
> >>
> >> Is there anything else I can do to help about this (mitigation
> solutions of
> >> Function_pointer_overwrite )?
> >
> >The ARM open/close depends on their use of Domains. For upstream,
> >you'd have to examine how Domains are being used (which seems
> >different to me).
>
> So, I will try to start to port pax_open_kernel/pax_close_kernel
> arm-specific features to upstream, and keep you in touch.
>
> >The other work is building the in-kernel
> >infrastructure to support write-rarely memory (likely a new section,
> >like ro_after_init, etc).
> >
>
> It seems that the constify plugin still not been ported to the lastest
> code (v4.9-rc1),
> If I understand, you means that a new section should be added
> to the upstream , and cooperate with the future constify plugin (the
> plugin automatically put those objects to that section ) ?
>

>
> >>>> Becsides, ret2dir is a common way to exploit  UAF vulns
> >>>> so  I think solutions like XPFO is a way  to make
> >>>> those kind of exploitation more diffcult.
> >>>
> >>>That's also good to hear. XPFO is making some progress; I'm looking
> >>>forward to it's next patch version (though IIUC, we'll need
> >>>arch-specific support for it on ARM -- the current patches are x86
> >>>only).
> >>
> >> I think I can also start with porting XPFO on ARM if you need.
> >
> >Sure, I'd be very curious to see this! Hopefully Juerg has some ideas
> >for helping there (he's been working on the x86 XPFO).
> >
> >>>> Right now KALSR is still disable in most android devices,
> >>>> so it is easy to get kernel symbol address,
> >>>> however if KALSR is enable, it may make exploitation more diffcult.
> >>>
> >>>Eliminating the various address exposures for KASLR is going to be a
> >>>long process, I suspect. If you find any that look easily fixable,
> >>>let's get them in. :)
> >>>
> >>>>> Are you interested mostly in ARM-specific things?
> >>>>
> >>>> I am famillar with ARM-specific things mostly, but I can also accept
> >>>> x86/x64
> >>>> tasks.
> >>>>
> >>>>> Are you interested in kernel-assisted userspace defenses too?
> >>>>
> >>>> What dose that mean ?  something like seccomp ?
> >>>
> >>>Sure, though I meant things like the brute-force detection, or W^X
> >>>memory enforcement for mmap/mprotect, etc. The defenses that the
> >>>kernel provides, but are for userspace hardening rather than kernel
> >>>hardening.
> >>
> >> Right now, I am rather more interested in kernel hardening,
> >> however, if there are people in charge of all areas, I can also
> >> get involve in userspace hardening
> >
> >Yeah, it's fine to stick with kernel; no worries. :) Thanks!
> >
> >-Kees
> >
> >
> >--
> >Kees Cook
> >Nexus Security
>

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

Re: [kernel-hardening] self introduction

[Kees Cook]

On Mon, Oct 17, 2016 at 4:57 AM, Gengjia Chen <chengjia4574@gmail.com> wrote:
>>>> In your research have you seen a common kind of bug that results in
>>>> the vulnerabilities you find?
>>>
>>> No,
>>> Most of those issues are caused by the lack of checking of  user input
>>> length
>>> in copy_xx_user functions or afterwards in memcpy functions,
>>> however, looking into the details,
>>> they vary among different functions in different files.
>>
>>Cool, I hope the recent hardened usercopy stuff will improve that
>>situation, though there is plenty left to do.
>>
>>>> Is there anything that would have
>>>> significantly made exploitation more difficult in the things you
>>>> worked on?
>>>
>>> Yes!
>>>
>>> I mostly exploit buffer overflow vulns by overwrite function pointers
>>> (such
>>> as
>>> pointers in file_operations) of a global object or a heap object
>>> to redirect execution (and if PXN is enable, we simply use rop gadgets).
>>> Therefore mitigation solutions of Function_pointer_overwrite  would
>>> make such kind of exploitation much more diffcult.
>>> But I don't know if you have let all the pointers "const".
>>
>>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel()
>>combined with the constify plugin would vastly improve the function
>>tables that could be const in the kernel. Perhaps that's something you
>>could look at: porting the pax_open_kernel()/pax_close_kernel()
>>infrastructure on ARM to upstream?
>>
>
> I found that pax_open_kernel()/pax_close_kernel() infrastructure
> had been ported on ARM in patch
> grsecurity-3.1-4.7.8-201610161720.patch, as follow:
>
> file: arch/arm/include/asm/pgtable.h
>
> #ifdef CONFIG_PAX_KERNEXEC
> static inline unsigned long pax_open_kernel(void) {
> #ifdef CONFIG_ARM_LPAE
>         /* TODO */
> #else
>         preempt_disable();
>         BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC));
>         modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC);
> #endif
>         return 0;
> }
>
> static inline unsigned long pax_close_kernel(void) {
> #ifdef CONFIG_ARM_LPAE
>         /* TODO */
> #else
>         BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER));
>         /* DOMAIN_MANAGER = "client" under KERNEXEC */
>         modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER);
>         preempt_enable_no_resched();
> #endif
>         return 0;
> }
> #else
> static inline unsigned long pax_open_kernel(void) { return 0; }
> static inline unsigned long pax_close_kernel(void) { return 0; }
> #endif
>
> Is there anything else I can do to help about this (mitigation solutions of
> Function_pointer_overwrite )?

The ARM open/close depends on their use of Domains. For upstream,
you'd have to examine how Domains are being used (which seems
different to me). The other work is building the in-kernel
infrastructure to support write-rarely memory (likely a new section,
like ro_after_init, etc).

>>> Becsides, ret2dir is a common way to exploit  UAF vulns
>>> so  I think solutions like XPFO is a way  to make
>>> those kind of exploitation more diffcult.
>>
>>That's also good to hear. XPFO is making some progress; I'm looking
>>forward to it's next patch version (though IIUC, we'll need
>>arch-specific support for it on ARM -- the current patches are x86
>>only).
>
> I think I can also start with porting XPFO on ARM if you need.

Sure, I'd be very curious to see this! Hopefully Juerg has some ideas
for helping there (he's been working on the x86 XPFO).

>>> Right now KALSR is still disable in most android devices,
>>> so it is easy to get kernel symbol address,
>>> however if KALSR is enable, it may make exploitation more diffcult.
>>
>>Eliminating the various address exposures for KASLR is going to be a
>>long process, I suspect. If you find any that look easily fixable,
>>let's get them in. :)
>>
>>>> Are you interested mostly in ARM-specific things?
>>>
>>> I am famillar with ARM-specific things mostly, but I can also accept
>>> x86/x64
>>> tasks.
>>>
>>>> Are you interested in kernel-assisted userspace defenses too?
>>>
>>> What dose that mean ?  something like seccomp ?
>>
>>Sure, though I meant things like the brute-force detection, or W^X
>>memory enforcement for mmap/mprotect, etc. The defenses that the
>>kernel provides, but are for userspace hardening rather than kernel
>>hardening.
>
> Right now, I am rather more interested in kernel hardening,
> however, if there are people in charge of all areas, I can also
> get involve in userspace hardening

Yeah, it's fine to stick with kernel; no worries. :) Thanks!

-Kees


-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Gengjia Chen]

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

>>> In your research have you seen a common kind of bug that results in
>>> the vulnerabilities you find?
>>
>> No,
>> Most of those issues are caused by the lack of checking of  user input
>> length
>> in copy_xx_user functions or afterwards in memcpy functions,
>> however, looking into the details,
>> they vary among different functions in different files.
>
>Cool, I hope the recent hardened usercopy stuff will improve that
>situation, though there is plenty left to do.
>
>>> Is there anything that would have
>>> significantly made exploitation more difficult in the things you
>>> worked on?
>>
>> Yes!
>>
>> I mostly exploit buffer overflow vulns by overwrite function pointers
(such
>> as
>> pointers in file_operations) of a global object or a heap object
>> to redirect execution (and if PXN is enable, we simply use rop gadgets).
>> Therefore mitigation solutions of Function_pointer_overwrite  would
>> make such kind of exploitation much more diffcult.
>> But I don't know if you have let all the pointers "const".
>
>Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel()
>combined with the constify plugin would vastly improve the function
>tables that could be const in the kernel. Perhaps that's something you
>could look at: porting the pax_open_kernel()/pax_close_kernel()
>infrastructure on ARM to upstream?
>

I found that pax_open_kernel()/pax_close_kernel() infrastructure
had been ported on ARM in patch
grsecurity-3.1-4.7.8-201610161720.patch, as follow:

file: arch/arm/include/asm/pgtable.h

#ifdef CONFIG_PAX_KERNEXEC
static inline unsigned long pax_open_kernel(void) {
#ifdef CONFIG_ARM_LPAE
        /* TODO */
#else
        preempt_disable();
        BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC));
        modify_domain(DOMAIN_KERNEL, DOMAIN_KERNEXEC);
#endif
        return 0;
}

static inline unsigned long pax_close_kernel(void) {
#ifdef CONFIG_ARM_LPAE
        /* TODO */
#else
        BUG_ON(test_domain(DOMAIN_KERNEL, DOMAIN_MANAGER));
        /* DOMAIN_MANAGER = "client" under KERNEXEC */
        modify_domain(DOMAIN_KERNEL, DOMAIN_MANAGER);
        preempt_enable_no_resched();
#endif
        return 0;
}
#else
static inline unsigned long pax_open_kernel(void) { return 0; }
static inline unsigned long pax_close_kernel(void) { return 0; }
#endif

Is there anything else I can do to help about this (mitigation solutions of
Function_pointer_overwrite )?


>> Becsides, ret2dir is a common way to exploit  UAF vulns
>> so  I think solutions like XPFO is a way  to make
>> those kind of exploitation more diffcult.
>
>That's also good to hear. XPFO is making some progress; I'm looking
>forward to it's next patch version (though IIUC, we'll need
>arch-specific support for it on ARM -- the current patches are x86
>only).
>

I think I can also start with porting XPFO on ARM if you need.


>> Right now KALSR is still disable in most android devices,
>> so it is easy to get kernel symbol address,
>> however if KALSR is enable, it may make exploitation more diffcult.
>
>Eliminating the various address exposures for KASLR is going to be a
>long process, I suspect. If you find any that look easily fixable,
>let's get them in. :)
>
>>> Are you interested mostly in ARM-specific things?
>>
>> I am famillar with ARM-specific things mostly, but I can also accept
x86/x64
>> tasks.
>>
>>> Are you interested in kernel-assisted userspace defenses too?
>>
>> What dose that mean ?  something like seccomp ?
>
>Sure, though I meant things like the brute-force detection, or W^X
>memory enforcement for mmap/mprotect, etc. The defenses that the
>kernel provides, but are for userspace hardening rather than kernel
>hardening.

Right now, I am rather more interested in kernel hardening,
however, if there are people in charge of all areas, I can also
get involve in userspace hardening

2016-10-14 2:50 GMT+08:00 Kees Cook <keescook@chromium.org>:

> On Thu, Oct 13, 2016 at 4:14 AM, Gengjia Chen <chengjia4574@gmail.com>
> wrote:
> >> In your research have you seen a common kind of bug that results in
> >> the vulnerabilities you find?
> >
> > No,
> > Most of those issues are caused by the lack of checking of  user input
> > length
> > in copy_xx_user functions or afterwards in memcpy functions,
> > however, looking into the details,
> > they vary among different functions in different files.
>
> Cool, I hope the recent hardened usercopy stuff will improve that
> situation, though there is plenty left to do.
>
> >> Is there anything that would have
> >> significantly made exploitation more difficult in the things you
> >> worked on?
> >
> > Yes!
> >
> > I mostly exploit buffer overflow vulns by overwrite function pointers
> (such
> > as
> > pointers in file_operations) of a global object or a heap object
> > to redirect execution (and if PXN is enable, we simply use rop gadgets).
> > Therefore mitigation solutions of Function_pointer_overwrite  would
> > make such kind of exploitation much more diffcult.
> > But I don't know if you have let all the pointers "const".
>
> Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel()
> combined with the constify plugin would vastly improve the function
> tables that could be const in the kernel. Perhaps that's something you
> could look at: porting the pax_open_kernel()/pax_close_kernel()
> infrastructure on ARM to upstream?
>
> > Becsides, ret2dir is a common way to exploit  UAF vulns
> > so  I think solutions like XPFO is a way  to make
> > those kind of exploitation more diffcult.
>
> That's also good to hear. XPFO is making some progress; I'm looking
> forward to it's next patch version (though IIUC, we'll need
> arch-specific support for it on ARM -- the current patches are x86
> only).
>
> > Right now KALSR is still disable in most android devices,
> > so it is easy to get kernel symbol address,
> > however if KALSR is enable, it may make exploitation more diffcult.
>
> Eliminating the various address exposures for KASLR is going to be a
> long process, I suspect. If you find any that look easily fixable,
> let's get them in. :)
>
> >> Are you interested mostly in ARM-specific things?
> >
> > I am famillar with ARM-specific things mostly, but I can also accept
> x86/x64
> > tasks.
> >
> >> Are you interested in kernel-assisted userspace defenses too?
> >
> > What dose that mean ?  something like seccomp ?
>
> Sure, though I meant things like the brute-force detection, or W^X
> memory enforcement for mmap/mprotect, etc. The defenses that the
> kernel provides, but are for userspace hardening rather than kernel
> hardening.
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
>

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

Re: [kernel-hardening] self introduction

[Andy Lutomirski]

On Mon, Oct 10, 2016 at 1:57 PM, Kees Cook <keescook@chromium.org> wrote:
> On Sun, Oct 9, 2016 at 5:34 AM, Colin Vidal <colin@cvidal.org> wrote:
>> My name is Colin Vidal. I am currently a PhD student in computer
>> science. My researches  consist on building a dedicated specific
>> language on top of JavaScript in order to handle asynchronous events in
>> a synchronous style. Hence, with a direct relation between the control
>> flow and the instruction flow.
>>
>> Beside my researches, I am taking up the Eudyptula Challenge (task 15
>> submitted). It helps me to have a global view of the kernel
>> (organization, tree, some features), but it is not enough to get
>> involved in serious development. Therefore, I am looking for task I can
>> accomplish to be involved into real kernel development!
>
> Hi! Welcome to the fun! :)
>
> I see there's already a thread getting into the HARDENED_ATOMIC
> effort, though I thought I might bring up some other areas too, in
> case they entice you as well. You've got some background in control
> flow -- have you spent much time in compiler internals? The recent
> addition of the gcc plugin infrastructure means there's a much wider
> ability for the kernel to do compiler tricks now. Two things that come
> to mind for CFI when looking at the existing PaX/Grsecurity gcc
> plugins are the kernexec plugin (which, AIUI, is mainly a weak form of
> SMEP emulation on x86, using simple CFI to keep the high bit set on
> all kernel function calls) which I think would be easy to extract as a
> stand-alone plugin:
>
> https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/scripts/gcc-plugins/kernexec_plugin.c
>
> And at the other end of the spectrum is the RAP plugin (which does a
> portion of PaX's full RAP, though there appear to be some non-trivial
> kernel changes need to support it, e.g. per-cpu PGD):
>
> https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

Linus has loudly poo-pooed per-cpu PGD, and I'm not sure I disagree.
It would be *really* nice to find a clean way to do RAP without it.

>
>> I still don't have yet a narrow idea about where I can begin. I like
>> though the idea of kernel self protection. For instance, I find the VM-
>> mapped stack to be really interesting, but I think it is an overkill as
>> a beginning, and a lot of work have already been done on it. On the
>> architecture point-of-view, I have a preference of x86 since I only
>> have this hardware for now, but I can work on ARM and others with QEMU
>> too.
>
> A piece missing from vmap-stack (I think) is having guard pages at
> _both_ ends of the kernel stack. Andy Lutomirski surely knows better
> than I do, but I'm hoping he's working on looking at PCID-based SMAP
> emulation. (Hi Andy!) :)
>

Hi!  I'm not presently working on it, and I'm a bit swamped, but maybe soon.

Re: [kernel-hardening] self introduction

[Hans Liljestrand]

On Thu, Oct 13, 2016 at 11:53:29AM -0700, Kees Cook wrote:
> On Sun, Oct 9, 2016 at 11:02 PM, Reshetova, Elena
> <elena.reshetova@intel.com> wrote:
> > This branch to be precise:
> > https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next
> 
> Github seems to think this hasn't been touched in 2 weeks and shows an
> error of "Failed to load latest commit information." in its web UI. Is
> there some place to find the last version? (Or rather, is there an RFC
> v2 coming soon?)

Not sure what's up with the github repository, I've been getting the same error
since we started. The most recent change was two days ago, which shows up on the
commit page:

https://github.com/ereshetova/linux-stable/commits/hardened_atomic_on_next

..although it seems the individual dates haven't been updated, so maybe it's
some issue with how we've been doing the updates. Anyays, the most recent code
should be available there.

I'm working under the assumption we're trying to get the RFC v2 out next week,
so hopefully soon.

Best Regards,
-hans

Re: [kernel-hardening] self introduction

[Kees Cook]

On Sun, Oct 9, 2016 at 11:02 PM, Reshetova, Elena
<elena.reshetova@intel.com> wrote:
> This branch to be precise:
> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next

Github seems to think this hasn't been touched in 2 weeks and shows an
error of "Failed to load latest commit information." in its web UI. Is
there some place to find the last version? (Or rather, is there an RFC
v2 coming soon?)

I'd like to get it added to my kernel.org account so that the 0-day
builder can poke at it. It regularly finds corner cases, etc...

Thanks!

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Kees Cook]

On Thu, Oct 13, 2016 at 4:14 AM, Gengjia Chen <chengjia4574@gmail.com> wrote:
>> In your research have you seen a common kind of bug that results in
>> the vulnerabilities you find?
>
> No,
> Most of those issues are caused by the lack of checking of  user input
> length
> in copy_xx_user functions or afterwards in memcpy functions,
> however, looking into the details,
> they vary among different functions in different files.

Cool, I hope the recent hardened usercopy stuff will improve that
situation, though there is plenty left to do.

>> Is there anything that would have
>> significantly made exploitation more difficult in the things you
>> worked on?
>
> Yes!
>
> I mostly exploit buffer overflow vulns by overwrite function pointers (such
> as
> pointers in file_operations) of a global object or a heap object
> to redirect execution (and if PXN is enable, we simply use rop gadgets).
> Therefore mitigation solutions of Function_pointer_overwrite  would
> make such kind of exploitation much more diffcult.
> But I don't know if you have let all the pointers "const".

Creating a mechanism like PaX's pax_open_kernel()/pax_close_kernel()
combined with the constify plugin would vastly improve the function
tables that could be const in the kernel. Perhaps that's something you
could look at: porting the pax_open_kernel()/pax_close_kernel()
infrastructure on ARM to upstream?

> Becsides, ret2dir is a common way to exploit  UAF vulns
> so  I think solutions like XPFO is a way  to make
> those kind of exploitation more diffcult.

That's also good to hear. XPFO is making some progress; I'm looking
forward to it's next patch version (though IIUC, we'll need
arch-specific support for it on ARM -- the current patches are x86
only).

> Right now KALSR is still disable in most android devices,
> so it is easy to get kernel symbol address,
> however if KALSR is enable, it may make exploitation more diffcult.

Eliminating the various address exposures for KASLR is going to be a
long process, I suspect. If you find any that look easily fixable,
let's get them in. :)

>> Are you interested mostly in ARM-specific things?
>
> I am famillar with ARM-specific things mostly, but I can also accept x86/x64
> tasks.
>
>> Are you interested in kernel-assisted userspace defenses too?
>
> What dose that mean ?  something like seccomp ?

Sure, though I meant things like the brute-force detection, or W^X
memory enforcement for mmap/mprotect, etc. The defenses that the
kernel provides, but are for userspace hardening rather than kernel
hardening.

-Kees

-- 
Kees Cook
Nexus Security

RE: [kernel-hardening] self introduction

[Reshetova, Elena]

> get why the test in arch/x86/include/kernel/traps.c
>
>         if (trapnr == X86_TRAP_OF)
>                 hardened_atomic_overflow(regs);
>
> is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if 
> CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in 
> arch/x86/include/asm/atomic.h are guarded by it), and it would avoid 
> the other implementation of hardened_atomic_overflow in 
> include/asm-generic/bug.h.

>The implementation is a static inline with no body, so the compiler will automatically eliminate the entire "if" statement, since it's a no-op.

Ups, my mistake here,  this static inline function currently is not empty, see: https://github.com/ereshetova/linux-stable/commit/3591430c0c7560de88b4721021f461e816d6cf38#diff-94d0be26498109f234666923aaafc7d9R221 
I didn't understood this part properly, will fix it to be a real empty function. 

Thank you for noticing this!

Best Regards,
Elena.

Re: [kernel-hardening] self introduction

[Gengjia Chen]

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

> In your research have you seen a common kind of bug that results in
> the vulnerabilities you find?

No,
Most of those issues are caused by the lack of checking of  user input
length
in copy_xx_user functions or afterwards in memcpy functions,
however, looking into the details,
they vary among different functions in different files.

> Is there anything that would have
> significantly made exploitation more difficult in the things you
> worked on?

Yes!

I mostly exploit buffer overflow vulns by overwrite function pointers (such
as
pointers in file_operations) of a global object or a heap object
to redirect execution (and if PXN is enable, we simply use rop gadgets).
Therefore mitigation solutions of Function_pointer_overwrite
<https://kernsec.org/wiki/index.php/Exploit_Methods/Function_pointer_overwrite>
would
make such kind of exploitation much more diffcult.
But I don't know if you have let all the pointers "const".

Becsides, ret2dir is a common way to exploit  UAF vulns
so  I think solutions like XPFO is a way  to make
those kind of exploitation more diffcult.

Right now KALSR is still disable in most android devices,
so it is easy to get kernel symbol address,
however if KALSR is enable, it may make exploitation more diffcult.

> Are you interested mostly in ARM-specific things?

I am famillar with ARM-specific things mostly, but I can also accept
x86/x64 tasks.

> Are you interested in kernel-assisted userspace defenses too?

What dose that mean ?  something like seccomp ?

2016-10-13 6:31 GMT+08:00 Kees Cook <keescook@chromium.org>:

> On Tue, Oct 11, 2016 at 8:19 PM, Gengjia Chen <chengjia4574@gmail.com>
> wrote:
> > Hi all,
>
> Hi, welcome!
>
> > My name is Jiayy (@chengjia4574). I am currently a security researcher in
> > android and linux kernel. My researches  consist on hunting
> vulnerabilities
> > in kernel code (most of them within drivers) and doing exploits using
> those
> > vulns.
> > I had found more than 40 vulnerabilities which were confirmed by Android
> > Security Team
> > in the past year. I also figured out some way to attack mitigation
> solutions
> > of kernel
> > (such as Bypass PXN).
>
> In your research have you seen a common kind of bug that results in
> the vulnerabilities you find? Is there anything that would have
> significantly made exploitation more difficult in the things you
> worked on?
>
> > Those works help me get familiar with the kernel(device tree, memory
> > management,
> > network , some features especially those associated with security such as
> > pxn, selinux, seccomp) and ARM instruction. However, it is not enough to
> get
> > involved in real security development in kernel. Therefore, I am looking
> for
> > task
> > I can accomplish to be involved into real kernel development!  Recently I
> > found
> > this project (kernel self protection) and I thought it is so interesting.
> >
> > I don't know whether I can involve and  where I can begin, I am looking
> > forward to
> > your response.
>
> Are you interested mostly in ARM-specific things? Are you interested
> in kernel-assisted userspace defenses too?
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
>

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

Re: [kernel-hardening] self introduction

[Kees Cook]

On Wed, Oct 12, 2016 at 1:27 AM, Colin Vidal <colin@cvidal.org> wrote:
>> I see there's already a thread getting into the HARDENED_ATOMIC
>> effort, though I thought I might bring up some other areas too, in
>> case they entice you as well. You've got some background in control
>> flow -- have you spent much time in compiler internals? The recent
>
> Not really on mainstream compilers. I've done some static inter/intra
> procedural analysis on previous projects (in order to optimize object
> call site), and the compiler of the DSL I'm working on is based on a
> completely different theories (it uses Esterel synchronous language
> semantic) and does not uses static CFG. Hence, I am quite far of CFI
> analysis :(

Heh, okay, no worries. I just thought I'd ask. I saw some key words in
your introduction. ;)

>> addition of the gcc plugin infrastructure means there's a much wider
>> ability for the kernel to do compiler tricks now. Two things that
>> come to mind for CFI when looking at the existing PaX/Grsecurity gcc
>> plugins are the kernexec plugin (which, AIUI, is mainly a weak form
>> of SMEP emulation on x86, using simple CFI to keep the high bit set
>> on all kernel function calls) which I think would be easy to extract
>> as a stand-alone plugin:
>>
>> https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/sc
>> ripts/gcc-plugins/kernexec_plugin.c
>
> If I understand, this plugin protects against running user-space code
> in supervisor mode (SMEP emulation, so avoid ROP class exploit), but
> since this analysis is purely static, it does not protects again
> out-of-tree dynamically loaded modules, right?

I can't tell which of two questions you're asking, so I'll answer both. :)

The gcc plugin infrastructure in the kernel is designed so that any
kernel modules built for the kernel will get the plugin run on it. The
kernexec plugin in particular, however, has logic to handle totally
out-of-tree builds that lack the instrumentation (see the Kconfig for
it). In that case, that module would not be protected, but the rest of
the kernel would be.

And, allowing arbitrary module loading on a system would nullify
virtually all kernel self-protection efforts when defending against
the root user, so it's an assumed that systems that are serious about
system security are either built monolithic (without modules) or
perform some kind of module verification (module signing, or LoadPin
with dm-verity).

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Kees Cook]

On Wed, Oct 12, 2016 at 1:25 AM, Colin Vidal <colin@cvidal.org> wrote:
>> > So, I will try to start to port PAX_REFCOUNT arm-specific features
>> > to hardened_atomic_on_next, and keep you in touch. Is there a
>> > deadline?  (4.10 / 5.0 merge window?)
>>
>> You may want to compare notes with Takahiro (CCed) who may have
>> started to look at arm64 (and maybe arm too).
>
> Thanks, I would be grateful!

Here's a thread Takahiro replied to:

http://www.openwall.com/lists/kernel-hardening/2016/10/12/2

>> As for a deadline, as Elena says, we have no specific target. ("As
>> soon as possible.") The only thing around timing that I like to see
>> is persistent progress: if a patch series goes up for review,
>> getting people to take a look at it, ask questions, make comments,
>> and then hopefully within a week or so, the next version comes
>> up. Momentum is easier to maintain than to build. ;)
>
> OK, good! I will have more time to work on it this WE, still I began to
> familiarize myself with atomic_t internals (and PaX patch).
>
> I noticed the build is broken for non-x86 architecture (at least
> arm/arm64), since basically each arch needs to provide atomic_*_wrap()
> functions. Is there plans to have (probably dummies) functions in case
> the architecture does not implements this functionality? I noticed the
> list of define atomic_*_wrap at the end of atomic-long.h, but it does
> not seems to works (they are defined after the call sites in the
> expansion of previous macros).

Yeah, I think this has already come up in the other thread and folks
are fixing (have fixed?) it. I expect to see a v2 RFC soon.

> Apart from that, in case of over-/underflow, hardened_atomic_overflow()
> is called to hang the system if CONFIG_HARDENED_ATOMIC is set. I don't

No, not hang the system, but rather stop further kernel execution and
kill the userspace process.

> get why the test in arch/x86/include/kernel/traps.c
>
>         if (trapnr == X86_TRAP_OF)
>                 hardened_atomic_overflow(regs);
>
> is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if
> CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in
> arch/x86/include/asm/atomic.h are guarded by it), and it would avoid
> the other implementation of hardened_atomic_overflow in
> include/asm-generic/bug.h.

The implementation is a static inline with no body, so the compiler
will automatically eliminate the entire "if" statement, since it's a
no-op. This is standard kernel coding style, to make the .c code as
readable as possible. Having it littered with #ifdefs makes things
harder to read.

>> > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch
>>
>> This is a quite old version of PaX. (Note the date.) If you want to
>> examine PaX separately from Grsecurity (noting differences can be
>> enlightening), check here:
>>
>> https://www.grsecurity.net/~paxguy1/?C=M;O=D
>
> Thanks!

Sure thing! I'm glad to have another set of eyes on this -- it's a
pretty big set of changes. :)

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Kees Cook]

On Tue, Oct 11, 2016 at 8:19 PM, Gengjia Chen <chengjia4574@gmail.com> wrote:
> Hi all,

Hi, welcome!

> My name is Jiayy (@chengjia4574). I am currently a security researcher in
> android and linux kernel. My researches  consist on hunting vulnerabilities
> in kernel code (most of them within drivers) and doing exploits using those
> vulns.
> I had found more than 40 vulnerabilities which were confirmed by Android
> Security Team
> in the past year. I also figured out some way to attack mitigation solutions
> of kernel
> (such as Bypass PXN).

In your research have you seen a common kind of bug that results in
the vulnerabilities you find? Is there anything that would have
significantly made exploitation more difficult in the things you
worked on?

> Those works help me get familiar with the kernel(device tree, memory
> management,
> network , some features especially those associated with security such as
> pxn, selinux, seccomp) and ARM instruction. However, it is not enough to get
> involved in real security development in kernel. Therefore, I am looking for
> task
> I can accomplish to be involved into real kernel development!  Recently I
> found
> this project (kernel self protection) and I thought it is so interesting.
>
> I don't know whether I can involve and  where I can begin, I am looking
> forward to
> your response.

Are you interested mostly in ARM-specific things? Are you interested
in kernel-assisted userspace defenses too?

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Colin Vidal]

> > Beside my researches, I am taking up the Eudyptula Challenge (task
> > 15 submitted). It helps me to have a global view of the kernel
> > (organization, tree, some features), but it is not enough to get
> > involved in serious development. Therefore, I am looking for task
> > I can accomplish to be involved into real kernel development!
>
> Hi! Welcome to the fun! :)

Cheers :)

> I see there's already a thread getting into the HARDENED_ATOMIC
> effort, though I thought I might bring up some other areas too, in
> case they entice you as well. You've got some background in control
> flow -- have you spent much time in compiler internals? The recent

Not really on mainstream compilers. I've done some static inter/intra
procedural analysis on previous projects (in order to optimize object
call site), and the compiler of the DSL I'm working on is based on a
completely different theories (it uses Esterel synchronous language
semantic) and does not uses static CFG. Hence, I am quite far of CFI
analysis :(

> addition of the gcc plugin infrastructure means there's a much wider
> ability for the kernel to do compiler tricks now. Two things that
> come to mind for CFI when looking at the existing PaX/Grsecurity gcc
> plugins are the kernexec plugin (which, AIUI, is mainly a weak form
> of SMEP emulation on x86, using simple CFI to keep the high bit set
> on all kernel function calls) which I think would be easy to extract
> as a stand-alone plugin:
>
> https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/sc
> ripts/gcc-plugins/kernexec_plugin.c

If I understand, this plugin protects against running user-space code
in supervisor mode (SMEP emulation, so avoid ROP class exploit), but
since this analysis is purely static, it does not protects again
out-of-tree dynamically loaded modules, right?

> And at the other end of the spectrum is the RAP plugin (which does a
> portion of PaX's full RAP, though there appear to be some non-trivial
> kernel changes need to support it, e.g. per-cpu PGD):
>
> https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

Seems really interesting, though! I have plenty of food for thought
with HARDENED_ATOMIC port for now, but I keep that in the back of my
mind!

> > I still don't have yet a narrow idea about where I can begin. I
> > like though the idea of kernel self protection. For instance, I
> > find the VM- mapped stack to be really interesting, but I think it
> > is an overkill as a beginning, and a lot of work have already been
> > done on it. On the architecture point-of-view, I have a preference
> > of x86 since I only have this hardware for now, but I can work on
> > ARM and others with QEMU too.
>
> A piece missing from vmap-stack (I think) is having guard pages at
> _both_ ends of the kernel stack. Andy Lutomirski surely knows better
> than I do, but I'm hoping he's working on looking at PCID-based SMAP
> emulation. (Hi Andy!) :)
>
> -Kees

Thanks!

Colin

Re: [kernel-hardening] self introduction

[Colin Vidal]

> > So, I will try to start to port PAX_REFCOUNT arm-specific features
> > to hardened_atomic_on_next, and keep you in touch. Is there a
> > deadline?  (4.10 / 5.0 merge window?)
>
> You may want to compare notes with Takahiro (CCed) who may have
> started to look at arm64 (and maybe arm too).

Thanks, I would be grateful!

> As for a deadline, as Elena says, we have no specific target. ("As
> soon as possible.") The only thing around timing that I like to see
> is persistent progress: if a patch series goes up for review,
> getting people to take a look at it, ask questions, make comments,
> and then hopefully within a week or so, the next version comes
> up. Momentum is easier to maintain than to build. ;)

OK, good! I will have more time to work on it this WE, still I began to
familiarize myself with atomic_t internals (and PaX patch).

I noticed the build is broken for non-x86 architecture (at least
arm/arm64), since basically each arch needs to provide atomic_*_wrap()
functions. Is there plans to have (probably dummies) functions in case
the architecture does not implements this functionality? I noticed the
list of define atomic_*_wrap at the end of atomic-long.h, but it does
not seems to works (they are defined after the call sites in the
expansion of previous macros).

Apart from that, in case of over-/underflow, hardened_atomic_overflow()
is called to hang the system if CONFIG_HARDENED_ATOMIC is set. I don't
get why the test in arch/x86/include/kernel/traps.c

	if (trapnr == X86_TRAP_OF)
        	hardened_atomic_overflow(regs);

is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if
CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in
arch/x86/include/asm/atomic.h are guarded by it), and it would avoid
the other implementation of hardened_atomic_overflow in
include/asm-generic/bug.h.

> > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch
>
> This is a quite old version of PaX. (Note the date.) If you want to
> examine PaX separately from Grsecurity (noting differences can be
> enlightening), check here:
>
> https://www.grsecurity.net/~paxguy1/?C=M;O=D

Thanks!

Colin

Re: [kernel-hardening] self introduction

[Gengjia Chen]

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

Hi all,

My name is Jiayy (@chengjia4574 <https://twitter.com/chengjia4574>). I am
currently a security researcher in
android and linux kernel. My researches  consist on hunting vulnerabilities
in kernel code (most of them within drivers) and doing exploits using those
vulns.
I had found more than 40 vulnerabilities
<http://www.linkedin.com/in/chen-gengjia-a4411855?trk=nav_responsive_tab_profile>
which were confirmed by Android Security Team
in the past year. I also figured out some way to attack mitigation
solutions of kernel
(such as Bypass PXN <http://en.mosec.org/#speech_bg>).

Those works help me get familiar with the kernel(device tree, memory
management,
network , some features especially those associated with security such as
pxn, selinux, seccomp) and ARM instruction. However, it is not enough to
get
involved in real security development in kernel. Therefore, I am looking
for task
I can accomplish to be involved into real kernel development!  Recently I
found
this project (kernel self protection) and I thought it is so interesting.

I don't know whether I can involve and  where I can begin, I am looking
forward to
your response.


Thanks,

Jiayy

2016-10-11 5:05 GMT+08:00 Kees Cook <keescook@chromium.org>:

> On Mon, Oct 10, 2016 at 9:01 AM, Colin Vidal <colin@cvidal.org> wrote:
> >> This branch to be precise:
> >> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next
> >>
> >> This is where the latest code for linux-next is hosted now and where
> >> we work with David and Hans.
> >> >
> >> > >
> >> > > Please contact me if you have any questions; I'd be glad to help!
> >> >
> >> > I actually have question. :-) As far as I understand, PAX_REFCOUNT
> >> > [1] is mainly a x86-only
> >>
> >> >
> >> > No, PAX_REFCOUNT also supports a bunch of other architectures. As
> >> > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC.
> >>
> >> Yes, just in our patch series we only made implementation for x86.
> >> But if you look into Grsecurity/PaX patches, it has support for
> >> others implemented.
> >
> > OK, got it! Thanks for this clarification.
> >
> > So, I will try to start to port PAX_REFCOUNT arm-specific features to
> > hardened_atomic_on_next, and keep you in touch. Is there a deadline?
> > (4.10 / 5.0 merge window?)
>
> You may want to compare notes with Takahiro (CCed) who may have
> started to look at arm64 (and maybe arm too).
>
> As for a deadline, as Elena says, we have no specific target. ("As
> soon as possible.") The only thing around timing that I like to see is
> persistent progress: if a patch series goes up for review, getting
> people to take a look at it, ask questions, make comments, and then
> hopefully within a week or so, the next version comes up. Momentum is
> easier to maintain than to build. ;)
>
> > Just to be sure, the patch [1] and documentation [2] of PaX are still
> > up-to-date, or there is another references I missed?
> >
> > Thanks
> >
> > Colin
> >
> > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch
>
> This is a quite old version of PaX. (Note the date.) If you want to
> examine PaX separately from Grsecurity (noting differences can be
> enlightening), check here:
>
> https://www.grsecurity.net/~paxguy1/?C=M;O=D
>
> > [2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173
>
> Yes, outside of reading the code itself, I believe this to be the most
> comprehensive piece of documentation about PAX_REFCOUNT.
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
>

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

Re: [kernel-hardening] self introduction

[Kees Cook]

On Mon, Oct 10, 2016 at 9:01 AM, Colin Vidal <colin@cvidal.org> wrote:
>> This branch to be precise:
>> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next
>>
>> This is where the latest code for linux-next is hosted now and where
>> we work with David and Hans.
>> >
>> > >
>> > > Please contact me if you have any questions; I'd be glad to help!
>> >
>> > I actually have question. :-) As far as I understand, PAX_REFCOUNT
>> > [1] is mainly a x86-only
>>
>> >
>> > No, PAX_REFCOUNT also supports a bunch of other architectures. As
>> > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC.
>>
>> Yes, just in our patch series we only made implementation for x86.
>> But if you look into Grsecurity/PaX patches, it has support for
>> others implemented.
>
> OK, got it! Thanks for this clarification.
>
> So, I will try to start to port PAX_REFCOUNT arm-specific features to
> hardened_atomic_on_next, and keep you in touch. Is there a deadline?
> (4.10 / 5.0 merge window?)

You may want to compare notes with Takahiro (CCed) who may have
started to look at arm64 (and maybe arm too).

As for a deadline, as Elena says, we have no specific target. ("As
soon as possible.") The only thing around timing that I like to see is
persistent progress: if a patch series goes up for review, getting
people to take a look at it, ask questions, make comments, and then
hopefully within a week or so, the next version comes up. Momentum is
easier to maintain than to build. ;)

> Just to be sure, the patch [1] and documentation [2] of PaX are still
> up-to-date, or there is another references I missed?
>
> Thanks
>
> Colin
>
> [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch

This is a quite old version of PaX. (Note the date.) If you want to
examine PaX separately from Grsecurity (noting differences can be
enlightening), check here:

https://www.grsecurity.net/~paxguy1/?C=M;O=D

> [2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173

Yes, outside of reading the code itself, I believe this to be the most
comprehensive piece of documentation about PAX_REFCOUNT.

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] self introduction

[Kees Cook]

On Sun, Oct 9, 2016 at 5:34 AM, Colin Vidal <colin@cvidal.org> wrote:
> My name is Colin Vidal. I am currently a PhD student in computer
> science. My researches  consist on building a dedicated specific
> language on top of JavaScript in order to handle asynchronous events in
> a synchronous style. Hence, with a direct relation between the control
> flow and the instruction flow.
>
> Beside my researches, I am taking up the Eudyptula Challenge (task 15
> submitted). It helps me to have a global view of the kernel
> (organization, tree, some features), but it is not enough to get
> involved in serious development. Therefore, I am looking for task I can
> accomplish to be involved into real kernel development!

Hi! Welcome to the fun! :)

I see there's already a thread getting into the HARDENED_ATOMIC
effort, though I thought I might bring up some other areas too, in
case they entice you as well. You've got some background in control
flow -- have you spent much time in compiler internals? The recent
addition of the gcc plugin infrastructure means there's a much wider
ability for the kernel to do compiler tricks now. Two things that come
to mind for CFI when looking at the existing PaX/Grsecurity gcc
plugins are the kernexec plugin (which, AIUI, is mainly a weak form of
SMEP emulation on x86, using simple CFI to keep the high bit set on
all kernel function calls) which I think would be easy to extract as a
stand-alone plugin:

https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/scripts/gcc-plugins/kernexec_plugin.c

And at the other end of the spectrum is the RAP plugin (which does a
portion of PaX's full RAP, though there appear to be some non-trivial
kernel changes need to support it, e.g. per-cpu PGD):

https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

> I still don't have yet a narrow idea about where I can begin. I like
> though the idea of kernel self protection. For instance, I find the VM-
> mapped stack to be really interesting, but I think it is an overkill as
> a beginning, and a lot of work have already been done on it. On the
> architecture point-of-view, I have a preference of x86 since I only
> have this hardware for now, but I can work on ARM and others with QEMU
> too.

A piece missing from vmap-stack (I think) is having guard pages at
_both_ ends of the kernel stack. Andy Lutomirski surely knows better
than I do, but I'm hoping he's working on looking at PCID-based SMAP
emulation. (Hi Andy!) :)

-Kees

-- 
Kees Cook
Nexus Security

RE: [kernel-hardening] self introduction

[Reshetova, Elena]

> Yes, just in our patch series we only made implementation for x86.
> But if you look into Grsecurity/PaX patches, it has support for others 
> implemented.

>OK, got it! Thanks for this clarification.

>So, I will try to start to port PAX_REFCOUNT arm-specific features to hardened_atomic_on_next, and keep you in touch. Is there a deadline?
>(4.10 / 5.0 merge window?)

I don't think we have any particular deadline in mind: getting it in the upstream and making it behaving correctly is more of a priority. 

>Just to be sure, the patch [1] and documentation [2] of PaX are still up-to-date, or there is another references I missed?

I don't think there are any other significant references. Where we functionaly deviate from PaX/Grsecurity, we documented it in commit messages (so far only on percpu refcount thing) . 

Best Regards,
Elena.

Re: [kernel-hardening] self introduction

[Colin Vidal]

> This branch to be precise:
> https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next
>
> This is where the latest code for linux-next is hosted now and where
> we work with David and Hans.
> > 
> > > 
> > > Please contact me if you have any questions; I'd be glad to help!
> > 
> > I actually have question. :-) As far as I understand, PAX_REFCOUNT
> > [1] is mainly a x86-only
>
> >
> > No, PAX_REFCOUNT also supports a bunch of other architectures. As
> > far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC.
> 
> Yes, just in our patch series we only made implementation for x86.
> But if you look into Grsecurity/PaX patches, it has support for
> others implemented.

OK, got it! Thanks for this clarification.

So, I will try to start to port PAX_REFCOUNT arm-specific features to
hardened_atomic_on_next, and keep you in touch. Is there a deadline?
(4.10 / 5.0 merge window?)

Just to be sure, the patch [1] and documentation [2] of PaX are still
up-to-date, or there is another references I missed?

Thanks

Colin

[1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch
[2] https://forums.grsecurity.net/viewtopic.php?f=7&t=4173

RE: [kernel-hardening] self introduction

[Reshetova, Elena]

On Sun, Oct 09, 2016 at 09:09:42PM +0200, Colin Vidal wrote:
> Hi David,
> 
> > If you're interested, the HARDENED_ATOMIC team is looking for people 
> > to help porting the feature to other architectures.  ARM is a 
> > reasonable candidate for someone new to the project.  I have begun 
> > this effort myself, but if you'd like to collaborate I'd be 
> > grateful.
> 
> Sounds good!
> 
> > It essentially involves porting the original arch-specific features 
> > from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC 
> > tree, which can be found at 
> > https://github.com/esreshetova/linux-stable
> 
> The link seems broken (https://github.com/esreshetova too). I found 
> https://github.com/dwindsor/hardened-atomic but it is empty. Did I 
> miss something/Github filter?

>Typo in the link, I think?
>https://github.com/ereshetova/linux-stable

This branch to be precise: 
https://github.com/ereshetova/linux-stable/tree/hardened_atomic_on_next 

This is where the latest code for linux-next is hosted now and where we work with David and Hans. 

> > Please contact me if you have any questions; I'd be glad to help!
> 
> I actually have question. :-) As far as I understand, PAX_REFCOUNT [1] 
> is mainly a x86-only

>No, PAX_REFCOUNT also supports a bunch of other architectures. As far as I can tell from a quick look: ARM, MIPS, PowerPC and SPARC.

Yes, just in our patch series we only made implementation for x86. But if you look into Grsecurity/PaX patches, it has support for others implemented. 

Re: [kernel-hardening] self introduction

[Jann Horn]

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

On Sun, Oct 09, 2016 at 09:09:42PM +0200, Colin Vidal wrote:
> Hi David,
> 
> > If you're interested, the HARDENED_ATOMIC team is looking for people
> > to help porting the feature to other architectures.  ARM is a
> > reasonable candidate for someone new to the project.  I have begun
> > this effort myself, but if you'd like to collaborate I'd be
> > grateful.
> 
> Sounds good!
> 
> > It essentially involves porting the original arch-specific features
> > from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC
> > tree, which can be found at
> > https://github.com/esreshetova/linux-stable
> 
> The link seems broken (https://github.com/esreshetova too). I found
> https://github.com/dwindsor/hardened-atomic but it is empty. Did I
> miss something/Github filter?

Typo in the link, I think?
https://github.com/ereshetova/linux-stable


> > Please contact me if you have any questions; I'd be glad to help!
> 
> I actually have question. :-) As far as I understand, PAX_REFCOUNT [1]
> is mainly a x86-only

No, PAX_REFCOUNT also supports a bunch of other architectures. As far as
I can tell from a quick look: ARM, MIPS, PowerPC and SPARC.

> port from PaX project

It is part of the PaX patch.

> in order to avoid overflow
> on atomic_t variable (and avoid use-after-free exploits)

Yes - overflow (beyond INT_MAX) and underflow (beyond INT_MIN).

. I am a
> little bit confused about the Elena patch-set HARDENED_ATOMIC [2]. It
> is a more mature/recent version of the port, isn't it ?

HARDENED_ATOMIC is a patch based on PAX_REFCOUNT that is developed with
the intent to merge it into the upstream kernel.

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

Re: [kernel-hardening] self introduction

[Colin Vidal]

Hi David,

> If you're interested, the HARDENED_ATOMIC team is looking for people
> to help porting the feature to other architectures.  ARM is a
> reasonable candidate for someone new to the project.  I have begun
> this effort myself, but if you'd like to collaborate I'd be
> grateful.

Sounds good!

> It essentially involves porting the original arch-specific features
> from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC
> tree, which can be found at
> https://github.com/esreshetova/linux-stable

The link seems broken (https://github.com/esreshetova too). I found
https://github.com/dwindsor/hardened-atomic but it is empty. Did I
miss something/Github filter?

> Please contact me if you have any questions; I'd be glad to help!

I actually have question. :-) As far as I understand, PAX_REFCOUNT [1]
is mainly a x86-only port from PaX project in order to avoid overflow
on atomic_t variable (and avoid use-after-free exploits). I am a
little bit confused about the Elena patch-set HARDENED_ATOMIC [2]. It
is a more mature/recent version of the port, isn't it ?

Thanks!

Colin

[1] https://lwn.net/Articles/668724/
[2] https://lwn.net/Articles/702640/

Re: [kernel-hardening] self introduction

[David Windsor]

Hi Colin,

If you're interested, the HARDENED_ATOMIC team is looking for people to help porting the feature to other architectures.  ARM is a reasonable candidate for someone new to the project.  I have begun this effort myself, but if you'd like to collaborate I'd be grateful.  

It essentially involves porting the original arch-specific features from PAX_REFCOUNT into Elena Reshetova's official HARDENED_ATOMIC tree, which can be found at https://github.com/esreshetova/linux-stable

Please contact me if you have any questions; I'd be glad to help!

Thanks,
David


> On Oct 9, 2016, at 8:34 AM, Colin Vidal <colin@cvidal.org> wrote:
> 
> Hi all,
> 
> My name is Colin Vidal. I am currently a PhD student in computer
> science. My researches  consist on building a dedicated specific
> language on top of JavaScript in order to handle asynchronous events in
> a synchronous style. Hence, with a direct relation between the control
> flow and the instruction flow.
> 
> Beside my researches, I am taking up the Eudyptula Challenge (task 15
> submitted). It helps me to have a global view of the kernel
> (organization, tree, some features), but it is not enough to get
> involved in serious development. Therefore, I am looking for task I can
> accomplish to be involved into real kernel development!
> 
> I still don't have yet a narrow idea about where I can begin. I like
> though the idea of kernel self protection. For instance, I find the VM-
> mapped stack to be really interesting, but I think it is an overkill as
> a beginning, and a lot of work have already been done on it. On the
> architecture point-of-view, I have a preference of x86 since I only
> have this hardware for now, but I can work on ARM and others with QEMU
> too.
> 
> Thanks,
> 
> Colin

[kernel-hardening] self introduction

[Colin Vidal]

Hi all,

My name is Colin Vidal. I am currently a PhD student in computer
science. My researches  consist on building a dedicated specific
language on top of JavaScript in order to handle asynchronous events in
a synchronous style. Hence, with a direct relation between the control
flow and the instruction flow.

Beside my researches, I am taking up the Eudyptula Challenge (task 15
submitted). It helps me to have a global view of the kernel
(organization, tree, some features), but it is not enough to get
involved in serious development. Therefore, I am looking for task I can
accomplish to be involved into real kernel development!

I still don't have yet a narrow idea about where I can begin. I like
though the idea of kernel self protection. For instance, I find the VM-
mapped stack to be really interesting, but I think it is an overkill as
a beginning, and a lot of work have already been done on it. On the
architecture point-of-view, I have a preference of x86 since I only
have this hardware for now, but I can work on ARM and others with QEMU
too.

Thanks,

Colin