[kernel-hardening] Looking for something to WORK ON

[kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi guys,

I want to start with linux kernel development and looking for some project
where I can contribute. I was looking at
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project which
asked to introduce myself on the list if I am looking for some work (thats
what I am doing :) ). It would be highly appreciated if any of you guys
have something where I can contribute.

Best,
Shubham Bansal

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

Re: [kernel-hardening] Looking for something to WORK ON

[Sandy Harris]

Shubham Bansal <illusionist.neo@gmail.com> wrote:

> I want to start with linux kernel development and looking for some project
> where I can contribute.

Nearly all crypto and the address randomisation that is part of kernel
hardening depend on good random numbers, for Linux on the random(4)
driver. Getting it initialised early enough & well enough is an
extremely tricky problem. Several people have proposed solutions but
AFAIK none are complete and it might benefit from having fresh eyes
take a look, especially if you have a good background in crypto or
math.

Not all discussion is here; other relevant lists include
linux-crypto@vger.kernel.org and cryptography@metzdowd.com. People to
look for include the maintainer, tytso@mit.edu, the main person
working on the problem here, keescook@chromium.org, two guys who have
proposed drive rewrites that partly solve the problem, me and
smueller@chronox.de, and one with a lot of excellent comments,
jsd@av8n.com.

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi Sandy,

On Wed, Jul 6, 2016 at 8:44 PM, Sandy Harris <sandyinchina@gmail.com> wrote:

> Shubham Bansal <illusionist.neo@gmail.com> wrote:
>
> > I want to start with linux kernel development and looking for some
> project
> > where I can contribute.
>
> Nearly all crypto and the address randomisation that is part of kernel
> hardening depend on good random numbers, for Linux on the random(4)
> driver. Getting it initialised early enough & well enough is an
> extremely tricky problem. Several people have proposed solutions but
> AFAIK none are complete and it might benefit from having fresh eyes
> take a look, especially if you have a good background in crypto or
> math.
>
I have a basic understanding of crypto as I just graduated. But it sound
really interesting to work on. I am happy to work on it if you think it
would be good, But I must tell you that I have to read a lot for this.

>
> Not all discussion is here; other relevant lists include
> linux-crypto@vger.kernel.org and cryptography@metzdowd.com.

Subscribed.

> People to
> look for include the maintainer, tytso@mit.edu, the main person
> working on the problem here, keescook@chromium.org,

Should I mail them to get the update and how can I start contributing ?

> two guys who have
> proposed drive rewrites that partly solve the problem, me and
> smueller@chronox.de, and one with a lot of excellent comments,
> jsd@av8n.com.
>
Would it be possible to work with you on this ? I would try my best. I
would need some help from your side though.

Looking forward to hearing back from you. I would like to get started with
it soon.


Thanks,
Shubham Bansal

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

Re: [kernel-hardening] Looking for something to WORK ON

[Stephan Mueller]

Am Sonntag, 10. Juli 2016, 22:12:53 CEST schrieb Shubham Bansal:

Hi Shubham,

> Hi Sandy,
> 
> On Wed, Jul 6, 2016 at 8:44 PM, Sandy Harris <sandyinchina@gmail.com> wrote:
> > Shubham Bansal <illusionist.neo@gmail.com> wrote:
> > > I want to start with linux kernel development and looking for some
> > 
> > project
> > 
> > > where I can contribute.
> > 
> > Nearly all crypto and the address randomisation that is part of kernel
> > hardening depend on good random numbers, for Linux on the random(4)
> > driver. Getting it initialised early enough & well enough is an
> > extremely tricky problem. Several people have proposed solutions but
> > AFAIK none are complete and it might benefit from having fresh eyes
> > take a look, especially if you have a good background in crypto or
> > math.
> 
> I have a basic understanding of crypto as I just graduated. But it sound
> really interesting to work on. I am happy to work on it if you think it
> would be good, But I must tell you that I have to read a lot for this.
> 
> > Not all discussion is here; other relevant lists include
> > linux-crypto@vger.kernel.org and cryptography@metzdowd.com.
> 
> Subscribed.
> 
> > People to
> > look for include the maintainer, tytso@mit.edu, the main person
> > working on the problem here, keescook@chromium.org,
> 
> Should I mail them to get the update and how can I start contributing ?
> 
> > two guys who have
> > proposed drive rewrites that partly solve the problem, me and
> > smueller@chronox.de, and one with a lot of excellent comments,
> > jsd@av8n.com.
> 
> Would it be possible to work with you on this ? I would try my best. I
> would need some help from your side though.
> 
> Looking forward to hearing back from you. I would like to get started with
> it soon.

My code is in the kernel at crypto/jitterentropy.c. It is completely 
standalone and does not require anything, provided the intended architecture 
has either random_get_entropy() or get_cycles implemented. I have tested it on 
bare metal without a kernel. Thus, it can be operational as early as you need 
it.

To make it fully standalone, you have to:

- compile jitterentropy.c and the helper functions listed at the top in 
jitterentropy.c and implemented in jitterentropy_kcapi.c (note, 
jent_fips_enabled is not needed for your purpose)

- statically allocate the memory obtained in jent_entropy_collector_alloc

- ensure serialization as necessary

I strongly suggest that you call jent_entropy_init to ensure that the timer 
has a sufficient high resolution before you collect entropy with 
jent_read_entropy.

Note, I am currently getting help from a big chip vendor tracking down the 
root cause that beyond the analysis of chapter 6.1 in my report.

Ciao
Stephan

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Wed, Jul 6, 2016 at 10:40 AM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> Hi guys,
>
> I want to start with linux kernel development and looking for some project
> where I can contribute. I was looking at
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project which asked
> to introduce myself on the list if I am looking for some work (thats what I
> am doing :) ). It would be highly appreciated if any of you guys have
> something where I can contribute.
>
> Best,
> Shubham Bansal

Welcome to the fun! :)

What things are you generally interested in? Do you have familiarity
with a specific architecture (or do you want to _gain_ familiarity
with a specific architecture)?

There's a small list of stuff that is related to the larger project
pieces that I try to keep up to date, of varying difficulty:

http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#Specific_TODO_Items

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi Kees,

Sorry for the late reply. I am having some problems with arranging a lot of
mails from the list.

On Wed, Jul 6, 2016 at 11:05 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Jul 6, 2016 at 10:40 AM, Shubham Bansal
> <illusionist.neo@gmail.com> wrote:
>> Hi guys,
>>
>> I want to start with linux kernel development and looking for some
project
>> where I can contribute. I was looking at
>> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project which
asked
>> to introduce myself on the list if I am looking for some work (thats
what I
>> am doing :) ). It would be highly appreciated if any of you guys have
>> something where I can contribute.
>>
>> Best,
>> Shubham Bansal
>
> Welcome to the fun! :)
>
> What things are you generally interested in?
Well, I don't have any preference as such. I am open to any work that is
related to security. I have just graduated from the college. I have
background in Crypto, Reverse engg. and exploit development. But if you
need a specific topic, I would say I want to add some features from
grsecurity to main linux kernel.
> Do you have familiarity
> with a specific architecture (or do you want to _gain_ familiarity
> with a specific architecture)?
I have a good familiarity with x86,x86-64 but I also know arm. Although,
its not a problem if there is a need, I will read about it.
>
> There's a small list of stuff that is related to the larger project
> pieces that I try to keep up to date, of varying difficulty:
>
>
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#Specific_TODO_Items

All of these sounds interesting to me. Although I didn't fully understand
some of the TODO items but few of these which I think I would like to work :

   - Move kernel stack to vmap area
   - Split thread_info off of kernel stack
   - Convert remaining BPF JITs to eBPF JIT (with blinding)
   - Write lib/test_bpf.c tests for eBPF constant blinding

But, I can work on other things also, whatever you think is appropriate. I
would prefer working on challenging project though.

Hoping for a quick reply. I want to start working as soon as possible.
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security

Thanks,
Shubham Bansal

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

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Sun, Jul 10, 2016 at 12:04 PM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> Hi Kees,
>
> Sorry for the late reply. I am having some problems with arranging a lot of
> mails from the list.

No worries! Glad to have you interested in the discussions. :)

>
> On Wed, Jul 6, 2016 at 11:05 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Jul 6, 2016 at 10:40 AM, Shubham Bansal
>> <illusionist.neo@gmail.com> wrote:
>>> Hi guys,
>>>
>>> I want to start with linux kernel development and looking for some
>>> project
>>> where I can contribute. I was looking at
>>> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project which
>>> asked
>>> to introduce myself on the list if I am looking for some work (thats what
>>> I
>>> am doing :) ). It would be highly appreciated if any of you guys have
>>> something where I can contribute.
>>>
>>> Best,
>>> Shubham Bansal
>>
>> Welcome to the fun! :)
>>
>> What things are you generally interested in?
>
> Well, I don't have any preference as such. I am open to any work that is
> related to security. I have just graduated from the college. I have
> background in Crypto, Reverse engg. and exploit development. But if you need
> a specific topic, I would say I want to add some features from grsecurity to
> main linux kernel.

That's ultimately where a lot of the work comes from: most of the
interesting protections have an implementation in the grsecurity
patch, but tends not to be in a form that is easily upstreamed.

>> Do you have familiarity
>> with a specific architecture (or do you want to _gain_ familiarity
>> with a specific architecture)?
>
> I have a good familiarity with x86,x86-64 but I also know arm. Although, its
> not a problem if there is a need, I will read about it.

If you want to poke at tricky/hard arch-specific issues, I'd love to
see ARMv8.1's PAN emulated on ARMv8.0. That one looks to be possible,
but tricky to find all the right ways to handle it.

If you're really feeling adventurous, I'd love to see the PaX's UDEREF
feature on x86_64 implemented in upstream.

>> There's a small list of stuff that is related to the larger project
>> pieces that I try to keep up to date, of varying difficulty:
>>
>>
>> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#Specific_TODO_Items
>
> All of these sounds interesting to me. Although I didn't fully understand
> some of the TODO items but few of these which I think I would like to work :
>
> Move kernel stack to vmap area

This one is under way by Andy Lutomirski for x86, but it'd be great to
see it done on arm and arm64 or other architectures.

> Split thread_info off of kernel stack

This is in progress for x86 too, but again, we need it for other architectures.

> Convert remaining BPF JITs to eBPF JIT (with blinding)

This would be nice for gaining BPF performance on the architectures
that don't support the JIT currently.

> Write lib/test_bpf.c tests for eBPF constant blinding

And this is good for testing the eBPF JIT blinding -- right now it's
kind of a manual check, and that makes me nervous since it's harder to
notice regressions.

(I've added Daniel Borkmann and Elena Reshetova to CC, since they
could help direct you with the BPF work.)

> But, I can work on other things also, whatever you think is appropriate. I
> would prefer working on challenging project though.

If you can solve the PAN emulation on ARMv8.0, that would be very
valuable -- most newer phones and tablets are moving to arm64, and
none are ARMv8.1, so they only have PXN and no PAN (where as 32-bit
arm can do full PAN emulation with Domains right now, so there's this
weird gap where we're actually going to regress in memory protections
for a few years until everything is shipping with ARMv8.1 devices).

> Hoping for a quick reply. I want to start working as soon as possible.

Hopefully this is quick enough. :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi,

On Tue, Jul 12, 2016 at 12:22 AM, Kees Cook <keescook@chromium.org> wrote:

> On Sun, Jul 10, 2016 at 12:04 PM, Shubham Bansal
> <illusionist.neo@gmail.com> wrote:
> > Hi Kees,
> >
> > Sorry for the late reply. I am having some problems with arranging a lot
> of
> > mails from the list.
>
> No worries! Glad to have you interested in the discussions. :)
>
> >
> > On Wed, Jul 6, 2016 at 11:05 PM, Kees Cook <keescook@chromium.org>
> wrote:
> >> On Wed, Jul 6, 2016 at 10:40 AM, Shubham Bansal
> >> <illusionist.neo@gmail.com> wrote:
> >>> Hi guys,
> >>>
> >>> I want to start with linux kernel development and looking for some
> >>> project
> >>> where I can contribute. I was looking at
> >>> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project which
> >>> asked
> >>> to introduce myself on the list if I am looking for some work (thats
> what
> >>> I
> >>> am doing :) ). It would be highly appreciated if any of you guys have
> >>> something where I can contribute.
> >>>
> >>> Best,
> >>> Shubham Bansal
> >>
> >> Welcome to the fun! :)
> >>
> >> What things are you generally interested in?
> >
> > Well, I don't have any preference as such. I am open to any work that is
> > related to security. I have just graduated from the college. I have
> > background in Crypto, Reverse engg. and exploit development. But if you
> need
> > a specific topic, I would say I want to add some features from
> grsecurity to
> > main linux kernel.
>
> That's ultimately where a lot of the work comes from: most of the
> interesting protections have an implementation in the grsecurity
> patch, but tends not to be in a form that is easily upstreamed.
>
Okay. I can try to add those protections to the main kernel.

>
> >> Do you have familiarity
> >> with a specific architecture (or do you want to _gain_ familiarity
> >> with a specific architecture)?
> >
> > I have a good familiarity with x86,x86-64 but I also know arm. Although,
> its
> > not a problem if there is a need, I will read about it.
>
> If you want to poke at tricky/hard arch-specific issues, I'd love to
> see ARMv8.1's PAN emulated on ARMv8.0. That one looks to be possible,
> but tricky to find all the right ways to handle it.
>
> If you're really feeling adventurous, I'd love to see the PaX's UDEREF
> feature on x86_64 implemented in upstream.
>
Okay. I can work on PaX's UDEREF feature now (if it's needed?) and keep on
reading about the ARMv8.0's PAN emulation. I will pick up the ARMv8.0's PAN
emulation later when I have enough knowledge about it.

>
> >> There's a small list of stuff that is related to the larger project
> >> pieces that I try to keep up to date, of varying difficulty:
> >>
> >>
> >>
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#Specific_TODO_Items
> >
> > All of these sounds interesting to me. Although I didn't fully understand
> > some of the TODO items but few of these which I think I would like to
> work :
> >
> > Move kernel stack to vmap area
>
> This one is under way by Andy Lutomirski for x86, but it'd be great to
> see it done on arm and arm64 or other architectures.
>

> > Split thread_info off of kernel stack
>
> This is in progress for x86 too, but again, we need it for other
> architectures.
>
> > Convert remaining BPF JITs to eBPF JIT (with blinding)
>
> This would be nice for gaining BPF performance on the architectures
> that don't support the JIT currently.
>
I can work on this if its needed. I want to pick up the arm related
features later when I have enough knowledge about the arm.

>
> > Write lib/test_bpf.c tests for eBPF constant blinding
>
> And this is good for testing the eBPF JIT blinding -- right now it's
> kind of a manual check, and that makes me nervous since it's harder to
> notice regressions.
>
> (I've added Daniel Borkmann and Elena Reshetova to CC, since they
> could help direct you with the BPF work.)
>
> > But, I can work on other things also, whatever you think is appropriate.
> I
> > would prefer working on challenging project though.
>
> If you can solve the PAN emulation on ARMv8.0, that would be very
> valuable -- most newer phones and tablets are moving to arm64, and
> none are ARMv8.1, so they only have PXN and no PAN (where as 32-bit
> arm can do full PAN emulation with Domains right now, so there's this
> weird gap where we're actually going to regress in memory protections
> for a few years until everything is shipping with ARMv8.1 devices).
>
 I am not confident about my knowledge of arm as of now but if needed I can
pick it up.

>
> > Hoping for a quick reply. I want to start working as soon as possible.
>
> Hopefully this is quick enough. :)
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security
>
So overall I have 3 options :

   - PaX's UDEREF feature - I want to work on this if its needed
   - PAN emulation on ARMv8.0 - My second preference would be this.
   - Convert remaining BPF JITs to eBPF JIT (with blinding) - Happy to do
   it if need
   - Move kernel stack to vmap area for arm - Want to keep it for later.

Let me know what you would suggest. I am still a beginner so don't know how
much work and knowledge they would need. I don't want to stuck in the
middle if the things get tough.


Best,

Shubham Bansal

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

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Tue, Jul 12, 2016 at 9:25 AM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> So overall I have 3 options :
>
> PaX's UDEREF feature - I want to work on this if its needed

This is a large project.

> PAN emulation on ARMv8.0 - My second preference would be this.

This sounds like it requires more research?

> Convert remaining BPF JITs to eBPF JIT (with blinding) - Happy to do it if
> need

I think this has value and there are folks that can help direct you
through this. Since you're new to kernel development, maybe start here
to get a sense of the amount of work needed, and then go from there?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Looking for something to WORK ON

[Mark Rutland]

On Tue, Jul 12, 2016 at 01:17:02PM -0400, Kees Cook wrote:
> On Tue, Jul 12, 2016 at 9:25 AM, Shubham Bansal
> <illusionist.neo@gmail.com> wrote:
> > PAN emulation on ARMv8.0 - My second preference would be this.
> 
> This sounds like it requires more research?

FWIW, Catalin has been prototyping this, so I suspect a version will
appear after the merge window.

Thanks,
Mark.

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Tue, Jul 12, 2016 at 1:36 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jul 12, 2016 at 01:17:02PM -0400, Kees Cook wrote:
>> On Tue, Jul 12, 2016 at 9:25 AM, Shubham Bansal
>> <illusionist.neo@gmail.com> wrote:
>> > PAN emulation on ARMv8.0 - My second preference would be this.
>>
>> This sounds like it requires more research?
>
> FWIW, Catalin has been prototyping this, so I suspect a version will
> appear after the merge window.

Ah, that is excellent news! Thanks for the update!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi,

> So overall I have 3 options :
> >
> > PaX's UDEREF feature - I want to work on this if its needed
>
> This is a large project.
>
I am happy to do it. Do you have anything where I can start ? I might need
someone who could guide me through it. It would be great if you could.

>
> > PAN emulation on ARMv8.0 - My second preference would be this.
>
> This sounds like it requires more research?
>
> > Convert remaining BPF JITs to eBPF JIT (with blinding) - Happy to do it
> if
> > need
>
> I think this has value and there are folks that can help direct you
> through this. Since you're new to kernel development, maybe start here
> to get a sense of the amount of work needed, and then go from there?
>
Okay. I will start here. I will keep the PAX's UDREF feature in the
background and start working on this. I will reach out to Daniel Borkmann
and Elena Reshetova for the starting pointers.

Daniel , Elena : Any update/help from your side is highly appreciated. If
you want I can start another thread with "Converting BPF JITs to eBPF JIT"
Subject, where we can discuss it.

Best,
Shubham Bansal

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

Re: [kernel-hardening] Looking for something to WORK ON

[Daniel Borkmann]

Hi Shubham,

On 07/13/2016 09:37 AM, Shubham Bansal wrote:
> Hi,
>
>> So overall I have 3 options :
>>>
>>> PaX's UDEREF feature - I want to work on this if its needed
>>
>> This is a large project.
>>
> I am happy to do it. Do you have anything where I can start ? I might need
> someone who could guide me through it. It would be great if you could.
>
>>
>>> PAN emulation on ARMv8.0 - My second preference would be this.
>>
>> This sounds like it requires more research?
>>
>>> Convert remaining BPF JITs to eBPF JIT (with blinding) - Happy to do it
>> if
>>> need
>>
>> I think this has value and there are folks that can help direct you
>> through this. Since you're new to kernel development, maybe start here
>> to get a sense of the amount of work needed, and then go from there?
>>
> Okay. I will start here. I will keep the PAX's UDREF feature in the
> background and start working on this. I will reach out to Daniel Borkmann
> and Elena Reshetova for the starting pointers.

Feel free to check out slides etc that are mostly located here:

   https://github.com/iovisor/bpf-docs

Also, Documentation/networking/filter.txt in the kernel tree provides some
info as a starting point, an example of eBPF JIT can be found here arch/x86/net/
in kernel tree.

To give you a basic overview what JITs are still classic BPF (cBPF) ones:

$ git grep -n "select HAVE_CBPF_JIT"
arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT

... and which are eBPF (ppc64 one should get merged next window I believe):

$ git grep -n "select HAVE_EBPF_JIT"
arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES
arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if X86_64

Cheers,
Daniel

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi Daniel,

I have read about the EBPF and BFP. I wanted to start contributing. Do you
have any place for me to start with ?
I mailed you regarding the same few months ago but didn't get the reply.

Best,
Shubham Bansal

On Wed, Jul 13, 2016 at 2:32 PM, Daniel Borkmann <daniel@iogearbox.net>
wrote:

> Hi Shubham,
>
> On 07/13/2016 09:37 AM, Shubham Bansal wrote:
>
>> Hi,
>>
>> So overall I have 3 options :
>>>
>>>>
>>>> PaX's UDEREF feature - I want to work on this if its needed
>>>>
>>>
>>> This is a large project.
>>>
>>> I am happy to do it. Do you have anything where I can start ? I might
>> need
>> someone who could guide me through it. It would be great if you could.
>>
>>
>>> PAN emulation on ARMv8.0 - My second preference would be this.
>>>>
>>>
>>> This sounds like it requires more research?
>>>
>>> Convert remaining BPF JITs to eBPF JIT (with blinding) - Happy to do it
>>>>
>>> if
>>>
>>>> need
>>>>
>>>
>>> I think this has value and there are folks that can help direct you
>>> through this. Since you're new to kernel development, maybe start here
>>> to get a sense of the amount of work needed, and then go from there?
>>>
>>> Okay. I will start here. I will keep the PAX's UDREF feature in the
>> background and start working on this. I will reach out to Daniel Borkmann
>> and Elena Reshetova for the starting pointers.
>>
>
> Feel free to check out slides etc that are mostly located here:
>
>   https://github.com/iovisor/bpf-docs
>
> Also, Documentation/networking/filter.txt in the kernel tree provides some
> info as a starting point, an example of eBPF JIT can be found here
> arch/x86/net/
> in kernel tree.
>
> To give you a basic overview what JITs are still classic BPF (cBPF) ones:
>
> $ git grep -n "select HAVE_CBPF_JIT"
> arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
> arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
> arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
>
> ... and which are eBPF (ppc64 one should get merged next window I believe):
>
> $ git grep -n "select HAVE_EBPF_JIT"
> arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
> arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK &&
> HAVE_MARCH_Z196_FEATURES
> arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if X86_64
>
> Cheers,
> Daniel
>

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

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Wed, Jan 11, 2017 at 4:46 AM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
>
> On Wed, Jul 13, 2016 at 2:32 PM, Daniel Borkmann <daniel@iogearbox.net>
> wrote:
>> Feel free to check out slides etc that are mostly located here:
>>
>>   https://github.com/iovisor/bpf-docs
>>
>> Also, Documentation/networking/filter.txt in the kernel tree provides some
>> info as a starting point, an example of eBPF JIT can be found here
>> arch/x86/net/
>> in kernel tree.
>>
>> To give you a basic overview what JITs are still classic BPF (cBPF) ones:
>>
>> $ git grep -n "select HAVE_CBPF_JIT"
>> arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
>> arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
>> arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>> arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
>>
>> ... and which are eBPF (ppc64 one should get merged next window I
>> believe):
>>
>> $ git grep -n "select HAVE_EBPF_JIT"
>> arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
>> arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK &&
>> HAVE_MARCH_Z196_FEATURES
>> arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if X86_64
>>
>> Cheers,
>> Daniel
>
> Hi Daniel,
>
> I have read about the EBPF and BFP. I wanted to start contributing. Do you
> have any place for me to start with ?
> I mailed you regarding the same few months ago but didn't get the reply.

Daniel may have more ideas, but I would say taking a CBPF jit and
converting it to an EBPF jit would be the best thing to start with.

Doing ARM first might be easiest to tackle?

-Kees

-- 
Kees Cook
Nexus Security

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Hi Kees,

I would have already started working on it since we last talked but before
that I wanted to check if anybody else is also not working on the same
thing. Otherwise it would be waste of time.

Anyways. I will start working on it. No point in postponing in.

Thanks,
Shubham

On Jan 12, 2017 2:59 AM, "Kees Cook" <keescook@chromium.org> wrote:

> On Wed, Jan 11, 2017 at 4:46 AM, Shubham Bansal
> <illusionist.neo@gmail.com> wrote:
> >
> > On Wed, Jul 13, 2016 at 2:32 PM, Daniel Borkmann <daniel@iogearbox.net>
> > wrote:
> >> Feel free to check out slides etc that are mostly located here:
> >>
> >>   https://github.com/iovisor/bpf-docs
> >>
> >> Also, Documentation/networking/filter.txt in the kernel tree provides
> some
> >> info as a starting point, an example of eBPF JIT can be found here
> >> arch/x86/net/
> >> in kernel tree.
> >>
> >> To give you a basic overview what JITs are still classic BPF (cBPF)
> ones:
> >>
> >> $ git grep -n "select HAVE_CBPF_JIT"
> >> arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
> >> arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
> >> arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> >> arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
> >>
> >> ... and which are eBPF (ppc64 one should get merged next window I
> >> believe):
> >>
> >> $ git grep -n "select HAVE_EBPF_JIT"
> >> arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
> >> arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK &&
> >> HAVE_MARCH_Z196_FEATURES
> >> arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if
> X86_64
> >>
> >> Cheers,
> >> Daniel
> >
> > Hi Daniel,
> >
> > I have read about the EBPF and BFP. I wanted to start contributing. Do
> you
> > have any place for me to start with ?
> > I mailed you regarding the same few months ago but didn't get the reply.
>
> Daniel may have more ideas, but I would say taking a CBPF jit and
> converting it to an EBPF jit would be the best thing to start with.
>
> Doing ARM first might be easiest to tackle?
>
> -Kees
>
> --
> Kees Cook
> Nexus Security
>

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

Re: [kernel-hardening] Looking for something to WORK ON

[Daniel Borkmann]

On 01/11/2017 11:12 PM, Shubham Bansal wrote:
> Hi Kees,
>
> I would have already started working on it since we last talked but before
> that I wanted to check if anybody else is also not working on the same
> thing. Otherwise it would be waste of time.
>
> Anyways. I will start working on it. No point in postponing in.

Very sorry for the late reply, Shubham, seems I missed your earlier email. :/
Afaik, nobody is working on that, so would be nice to tackle this.

> On Jan 12, 2017 2:59 AM, "Kees Cook" <keescook@chromium.org> wrote:
>
>> On Wed, Jan 11, 2017 at 4:46 AM, Shubham Bansal
>> <illusionist.neo@gmail.com> wrote:
>>>
>>> On Wed, Jul 13, 2016 at 2:32 PM, Daniel Borkmann <daniel@iogearbox.net>
>>> wrote:
>>>> Feel free to check out slides etc that are mostly located here:
>>>>
>>>>    https://github.com/iovisor/bpf-docs
>>>>
>>>> Also, Documentation/networking/filter.txt in the kernel tree provides
>> some
>>>> info as a starting point, an example of eBPF JIT can be found here
>>>> arch/x86/net/
>>>> in kernel tree.
>>>>
>>>> To give you a basic overview what JITs are still classic BPF (cBPF)
>> ones:
>>>>
>>>> $ git grep -n "select HAVE_CBPF_JIT"
>>>> arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
>>>> arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
>>>> arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>>>> arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
>>>>
>>>> ... and which are eBPF (ppc64 one should get merged next window I
>>>> believe):
>>>>
>>>> $ git grep -n "select HAVE_EBPF_JIT"
>>>> arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
>>>> arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK &&
>>>> HAVE_MARCH_Z196_FEATURES
>>>> arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if
>> X86_64
>>>>
>>>> Cheers,
>>>> Daniel
>>>
>>> Hi Daniel,
>>>
>>> I have read about the EBPF and BFP. I wanted to start contributing. Do
>> you
>>> have any place for me to start with ?
>>> I mailed you regarding the same few months ago but didn't get the reply.
>>
>> Daniel may have more ideas, but I would say taking a CBPF jit and
>> converting it to an EBPF jit would be the best thing to start with.
>>
>> Doing ARM first might be easiest to tackle?
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Nexus Security
>>
>

Re: [kernel-hardening] Looking for something to WORK ON

[Shubham Bansal]

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

Great. I just started working on it.

Best,
Shubham Bansal

On Thu, Jan 12, 2017 at 4:09 AM, Daniel Borkmann <daniel@iogearbox.net>
wrote:

> On 01/11/2017 11:12 PM, Shubham Bansal wrote:
>
>> Hi Kees,
>>
>> I would have already started working on it since we last talked but before
>> that I wanted to check if anybody else is also not working on the same
>> thing. Otherwise it would be waste of time.
>>
>> Anyways. I will start working on it. No point in postponing in.
>>
>
> Very sorry for the late reply, Shubham, seems I missed your earlier email.
> :/
> Afaik, nobody is working on that, so would be nice to tackle this.
>
>
> On Jan 12, 2017 2:59 AM, "Kees Cook" <keescook@chromium.org> wrote:
>>
>> On Wed, Jan 11, 2017 at 4:46 AM, Shubham Bansal
>>> <illusionist.neo@gmail.com> wrote:
>>>
>>>>
>>>> On Wed, Jul 13, 2016 at 2:32 PM, Daniel Borkmann <daniel@iogearbox.net>
>>>> wrote:
>>>>
>>>>> Feel free to check out slides etc that are mostly located here:
>>>>>
>>>>>    https://github.com/iovisor/bpf-docs
>>>>>
>>>>> Also, Documentation/networking/filter.txt in the kernel tree provides
>>>>>
>>>> some
>>>
>>>> info as a starting point, an example of eBPF JIT can be found here
>>>>> arch/x86/net/
>>>>> in kernel tree.
>>>>>
>>>>> To give you a basic overview what JITs are still classic BPF (cBPF)
>>>>>
>>>> ones:
>>>
>>>>
>>>>> $ git grep -n "select HAVE_CBPF_JIT"
>>>>> arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
>>>>> arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
>>>>> arch/powerpc/Kconfig:131:       select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
>>>>> arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
>>>>>
>>>>> ... and which are eBPF (ppc64 one should get merged next window I
>>>>> believe):
>>>>>
>>>>> $ git grep -n "select HAVE_EBPF_JIT"
>>>>> arch/arm64/Kconfig:64:  select HAVE_EBPF_JIT
>>>>> arch/s390/Kconfig:131:  select HAVE_EBPF_JIT if PACK_STACK &&
>>>>> HAVE_MARCH_Z196_FEATURES
>>>>> arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if
>>>>>
>>>> X86_64
>>>
>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>
>>>> Hi Daniel,
>>>>
>>>> I have read about the EBPF and BFP. I wanted to start contributing. Do
>>>>
>>> you
>>>
>>>> have any place for me to start with ?
>>>> I mailed you regarding the same few months ago but didn't get the reply.
>>>>
>>>
>>> Daniel may have more ideas, but I would say taking a CBPF jit and
>>> converting it to an EBPF jit would be the best thing to start with.
>>>
>>> Doing ARM first might be easiest to tackle?
>>>
>>> -Kees
>>>
>>> --
>>> Kees Cook
>>> Nexus Security
>>>
>>>
>>
>

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

Re: [kernel-hardening] Looking for something to WORK ON

[Valdis.Kletnieks]

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

On Sun, 10 Jul 2016 21:34:29 +0530, Shubham Bansal said:

> Hi Kees,
>
> Sorry for the late reply. I am having some problems with arranging a lot of
> mails from the list.

If you're not sure where to start, try picking up all the patches we've got
so far, applying them to a reasonably recent kernel, and seeing what breaks.

As far as I know, I'm the only crash test dummy at the moment, so having
somebody else testing with a kernel config different than what I have
on my laptop would be valuable.  So far I've identified that ptrace()
and some (but not all) variants of setsockopt() have issues with Kees's
usercopy patches.

Kees:  Am I the only guy who's trying this on a SLAB rather than SLUB box?

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

Re: [kernel-hardening] Looking for something to WORK ON

[Kees Cook]

On Mon, Jul 11, 2016 at 3:05 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sun, 10 Jul 2016 21:34:29 +0530, Shubham Bansal said:
>
>> Hi Kees,
>>
>> Sorry for the late reply. I am having some problems with arranging a lot of
>> mails from the list.
>
> If you're not sure where to start, try picking up all the patches we've got
> so far, applying them to a reasonably recent kernel, and seeing what breaks.
>
> As far as I know, I'm the only crash test dummy at the moment, so having
> somebody else testing with a kernel config different than what I have
> on my laptop would be valuable.  So far I've identified that ptrace()
> and some (but not all) variants of setsockopt() have issues with Kees's
> usercopy patches.
>
> Kees:  Am I the only guy who's trying this on a SLAB rather than SLUB box?

I think you're doing the bulk of the SLAB testing (though I'd
encourage you to drop the whitelist testing for now, since I want to
make sure the rest of the series is solid first). I've done limited
testing (mostly with boot and lkdtm) on SLAB, SLUB, and SLOB (and the
earlier SLOB series failed so badly for me that I dropped SLOB support
entirely).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security