All of lore.kernel.org
 help / color / mirror / Atom feed
* [kernel-hardening] Re: Self introduction
       [not found] <20160912065318.GH16712@linaro.org>
@ 2016-09-26 17:17 ` Kees Cook
  2016-09-27  0:29   ` David Windsor
  0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2016-09-26 17:17 UTC (permalink / raw)
  To: AKASHI Takahiro; +Cc: kernel-hardening

On Sun, Sep 11, 2016 at 11:53 PM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> Hi Kees and all,

Hi! Sorry for not replying sooner -- this email seemed to strangely
not make its way into the kernel-hardening list, even though it looks
from the headers like you sent it there. Regardless, on to my late
reply...

> I'm looking for any tasks that I could contribute in
> kernel-hardening areas. As I'm working for Linaro,
> arm/arm64-related items (or arch-specific implementation
> of more generic features) would be better fitted, but I'm
> open to broader topics, including complementary tasks
> for other guys.

Awesome! Yeah, it'll be great to have you helping. Are there any areas
you especially enjoy working on?

> Do you have any suggestions about such items for me
> to start small (or can be even big :) with?

I think a great area would be looking at arm and arm64 support for
catching atomic_t wrap-around. This kind of protection would have
stopped many of the public attacks from last year, since accidents
with refcounting on atomic_t tend to be a precursor to use-after-free
vulnerabilities.

This idea has been implemented in PaX/Grsecurity for a while now as
PAX_REFCOUNT. An earlier effort to extract it was started but he ran
out of time to work on it. Recently the folks from Intel have been
looking at the x86 side of this (and took on the burden of preparing
the upstreaming of the marking of the expected-wrap uses in the
kernel), but we'll still need other architectures to support this
feature. There's an excellent write-up on the feature here:
https://forums.grsecurity.net/viewtopic.php?f=7&t=4173
There isn't yet an implementation for arm64 (though maybe it'll be
identical/similar to the existing arm implementation).

I think Intel will be posting an RFC series soonish, which would
likely be the right place to start from.

-Kees

-- 
Kees Cook
Nexus Security

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [kernel-hardening] Re: Self introduction
  2016-09-26 17:17 ` [kernel-hardening] Re: Self introduction Kees Cook
@ 2016-09-27  0:29   ` David Windsor
  2016-09-27  2:29     ` Kees Cook
  0 siblings, 1 reply; 5+ messages in thread
From: David Windsor @ 2016-09-27  0:29 UTC (permalink / raw)
  To: kernel-hardening; +Cc: AKASHI Takahiro

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

Hi,


On Mon, Sep 26, 2016 at 1:17 PM, Kees Cook <keescook@chromium.org> wrote:

> On Sun, Sep 11, 2016 at 11:53 PM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > Hi Kees and all,
>
> Hi! Sorry for not replying sooner -- this email seemed to strangely
> not make its way into the kernel-hardening list, even though it looks
> from the headers like you sent it there. Regardless, on to my late
> reply...
>
> > I'm looking for any tasks that I could contribute in
> > kernel-hardening areas. As I'm working for Linaro,
> > arm/arm64-related items (or arch-specific implementation
> > of more generic features) would be better fitted, but I'm
> > open to broader topics, including complementary tasks
> > for other guys.
>
> Awesome! Yeah, it'll be great to have you helping. Are there any areas
> you especially enjoy working on?
>
> > Do you have any suggestions about such items for me
> > to start small (or can be even big :) with?
>
> I think a great area would be looking at arm and arm64 support for
> catching atomic_t wrap-around. This kind of protection would have
> stopped many of the public attacks from last year, since accidents
> with refcounting on atomic_t tend to be a precursor to use-after-free
> vulnerabilities.
>
> This idea has been implemented in PaX/Grsecurity for a while now as
> PAX_REFCOUNT. An earlier effort to extract it was started but he ran
> out of time to work on it.


Sorry about not communicating better about this.  I started working on v3
(porting to linux-next) a few days ago and have the code moved, but still
have to work through a few compile issues.

If you're interested in helping, take a look:

https://github.com/dwindsor/linux-next/tree/strict-refcount-v3

I'll continue working through this, but help would certainly be appreciated.

Thanks,
David

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [kernel-hardening] Re: Self introduction
  2016-09-27  0:29   ` David Windsor
@ 2016-09-27  2:29     ` Kees Cook
  2016-09-27  6:50       ` Reshetova, Elena
  0 siblings, 1 reply; 5+ messages in thread
From: Kees Cook @ 2016-09-27  2:29 UTC (permalink / raw)
  To: kernel-hardening; +Cc: AKASHI Takahiro

On Mon, Sep 26, 2016 at 5:29 PM, David Windsor <dave@progbits.org> wrote:
> Hi,
>
>
> On Mon, Sep 26, 2016 at 1:17 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> On Sun, Sep 11, 2016 at 11:53 PM, AKASHI Takahiro
>> <takahiro.akashi@linaro.org> wrote:
>> > Hi Kees and all,
>>
>> Hi! Sorry for not replying sooner -- this email seemed to strangely
>> not make its way into the kernel-hardening list, even though it looks
>> from the headers like you sent it there. Regardless, on to my late
>> reply...
>>
>> > I'm looking for any tasks that I could contribute in
>> > kernel-hardening areas. As I'm working for Linaro,
>> > arm/arm64-related items (or arch-specific implementation
>> > of more generic features) would be better fitted, but I'm
>> > open to broader topics, including complementary tasks
>> > for other guys.
>>
>> Awesome! Yeah, it'll be great to have you helping. Are there any areas
>> you especially enjoy working on?
>>
>> > Do you have any suggestions about such items for me
>> > to start small (or can be even big :) with?
>>
>> I think a great area would be looking at arm and arm64 support for
>> catching atomic_t wrap-around. This kind of protection would have
>> stopped many of the public attacks from last year, since accidents
>> with refcounting on atomic_t tend to be a precursor to use-after-free
>> vulnerabilities.
>>
>> This idea has been implemented in PaX/Grsecurity for a while now as
>> PAX_REFCOUNT. An earlier effort to extract it was started but he ran
>> out of time to work on it.
>
>
> Sorry about not communicating better about this.  I started working on v3
> (porting to linux-next) a few days ago and have the code moved, but still
> have to work through a few compile issues.
>
> If you're interested in helping, take a look:
>
> https://github.com/dwindsor/linux-next/tree/strict-refcount-v3
>
> I'll continue working through this, but help would certainly be appreciated.

No worries, thanks for the heads-up! I think getting everyone on the
same page will be good. We can all compare notes when Intel posts
patches too.

-Kees

-- 
Kees Cook
Nexus Security

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [kernel-hardening] Re: Self introduction
  2016-09-27  2:29     ` Kees Cook
@ 2016-09-27  6:50       ` Reshetova, Elena
  2016-09-27 16:46         ` Kees Cook
  0 siblings, 1 reply; 5+ messages in thread
From: Reshetova, Elena @ 2016-09-27  6:50 UTC (permalink / raw)
  To: kernel-hardening; +Cc: AKASHI Takahiro, Liljestrand Hans, Kees Cook

> Sorry about not communicating better about this.  I started working on 
> v3 (porting to linux-next) a few days ago and have the code moved, but 
> still have to work through a few compile issues.
>
> If you're interested in helping, take a look:
>
> https://github.com/dwindsor/linux-next/tree/strict-refcount-v3
>
> I'll continue working through this, but help would certainly be appreciated.

Hi David!

We have started to work on this about 3 weeks ago and currently have working code with additional tests. Sorry for not letting you know, I guess everyone thought that you are not working on this anymore. 
Just yesterday Hans figured out the proper explanantion for PERCPU_COUNT_BIAS change, so we will be posting series hopefully today-tomorrow after writing better commit messages. 

Best Regards,
Elena.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [kernel-hardening] Re: Self introduction
  2016-09-27  6:50       ` Reshetova, Elena
@ 2016-09-27 16:46         ` Kees Cook
  0 siblings, 0 replies; 5+ messages in thread
From: Kees Cook @ 2016-09-27 16:46 UTC (permalink / raw)
  To: Reshetova, Elena; +Cc: kernel-hardening, AKASHI Takahiro, Liljestrand Hans

On Mon, Sep 26, 2016 at 11:50 PM, Reshetova, Elena
<elena.reshetova@intel.com> wrote:
>> Sorry about not communicating better about this.  I started working on
>> v3 (porting to linux-next) a few days ago and have the code moved, but
>> still have to work through a few compile issues.
>>
>> If you're interested in helping, take a look:
>>
>> https://github.com/dwindsor/linux-next/tree/strict-refcount-v3
>>
>> I'll continue working through this, but help would certainly be appreciated.
>
> Hi David!
>
> We have started to work on this about 3 weeks ago and currently have working code with additional tests. Sorry for not letting you know, I guess everyone thought that you are not working on this anymore.
> Just yesterday Hans figured out the proper explanantion for PERCPU_COUNT_BIAS change, so we will be posting series hopefully today-tomorrow after writing better commit messages.

Great! Yeah, I think having verbose and clear commit messages will be
an important part of this series.

-Kees

-- 
Kees Cook
Nexus Security

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-09-27 16:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20160912065318.GH16712@linaro.org>
2016-09-26 17:17 ` [kernel-hardening] Re: Self introduction Kees Cook
2016-09-27  0:29   ` David Windsor
2016-09-27  2:29     ` Kees Cook
2016-09-27  6:50       ` Reshetova, Elena
2016-09-27 16:46         ` Kees Cook

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.