Introduction and get involved

Introduction and get involved

[Tianlin Li]

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

Hello everyone,
My name is Tina. I am working at DigitalOcean Systems/kernel team, focusing on kernel security. I would like to get involved with Kernel Self Protection Project. 
As a new hire, I don’t have much industry experience yet. But I have some research experience about memory virtualization. 

Is there any initial task that I can start with? 
It is going to be a learning exercise for me at the beginning, but I will learn fast and start contributing value to the project. 

Look forward to hearing from you. 

Best regards,
Tina

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

Re: Introduction and get involved

[Kees Cook]

On Fri, Sep 20, 2019 at 01:59:57PM -0500, Tianlin Li wrote:
> Hello everyone,

Hello!

> My name is Tina. I am working at DigitalOcean Systems/kernel team, focusing on kernel security. I would like to get involved with Kernel Self Protection Project. 
> As a new hire, I don’t have much industry experience yet. But I have some research experience about memory virtualization. 

What kinds of things keep you up at night? :) Or rather, what have you
seen that you think needs fixing?

What exactly do you mean by "memory virtualization"? That seems like it
could be a lot of stuff. :) As far as the kernel's memory management
system goes, there's lots of areas to poke at. Is there any portion
you're specifically interested in?

> Is there any initial task that I can start with? 
> It is going to be a learning exercise for me at the beginning, but I will learn fast and start contributing value to the project. 

There has been some recent work on trying to replace dangerous (or
easily misused) APIs in the kernel with safer alternatives. (See the
recent stracpy() API that was proposed[1].)

[1] https://www.openwall.com/lists/kernel-hardening/2019/07/23/16

I've been keeping a (rather terse) TODO list here:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work#Specific_TODO_Items

But I'd like to turn that into an actual bug list on github or the like.

I wonder if working on something like this:
- set_memory_*() needs __must_check and/or atomicity
would be interesting?

The idea there is that set_memory_*() calls can fail, so callers should
likely be handling errors correctly. Adding the "__must_check" attribute
and fixing all the callers would be nice (and certainly touches the
memory management code!)

Welcome!

-Kees

-- 
Kees Cook

Re: Introduction and get involved

[Tianlin Li]

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



> On Sep 24, 2019, at 6:12 PM, Kees Cook <keescook@chromium.org> wrote:
> 
> On Fri, Sep 20, 2019 at 01:59:57PM -0500, Tianlin Li wrote:
>> Hello everyone,
> 
> Hello!
> 
>> My name is Tina. I am working at DigitalOcean Systems/kernel team, focusing on kernel security. I would like to get involved with Kernel Self Protection Project. 
>> As a new hire, I don’t have much industry experience yet. But I have some research experience about memory virtualization. 
> 
> What kinds of things keep you up at night? :) Or rather, what have you
> seen that you think needs fixing?

I don’t have many ideas yet. :) 

> What exactly do you mean by "memory virtualization"? That seems like it
> could be a lot of stuff. :) As far as the kernel's memory management
> system goes, there's lots of areas to poke at. Is there any portion
> you're specifically interested in?

I did some research about tracking memory footprint in VMs/Containers, so I played with page tables/EPT/page fault handlers

>> Is there any initial task that I can start with? 
>> It is going to be a learning exercise for me at the beginning, but I will learn fast and start contributing value to the project. 
> 
> There has been some recent work on trying to replace dangerous (or
> easily misused) APIs in the kernel with safer alternatives. (See the
> recent stracpy() API that was proposed[1].)
> 
> [1] https://www.openwall.com/lists/kernel-hardening/2019/07/23/16
> 
> I've been keeping a (rather terse) TODO list here:
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work#Specific_TODO_Items
> 
> But I'd like to turn that into an actual bug list on github or the like.
> 
> I wonder if working on something like this:
> - set_memory_*() needs __must_check and/or atomicity
> would be interesting?
> 
> The idea there is that set_memory_*() calls can fail, so callers should
> likely be handling errors correctly. Adding the "__must_check" attribute
> and fixing all the callers would be nice (and certainly touches the
> memory management code!)

This is a great starting task for me. So for this task, basically I need to add __must_check attribute to set_memory_*() functions and fix all the callers to make sure they check the return values. Do I understand correctly?

Also I have some other questions:
Is there any requirement for the patches? e.g. based on which kernel version? how many individual patches?

Thanks,
Tina

> Welcome!
> 
> -Kees
> 
> -- 
> Kees Cook


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

Re: Introduction and get involved

[Kees Cook]

On Thu, Sep 26, 2019 at 09:57:58AM -0500, Tianlin Li wrote:
> > On Sep 24, 2019, at 6:12 PM, Kees Cook <keescook@chromium.org> wrote:
> > I've been keeping a (rather terse) TODO list here:
> > https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work#Specific_TODO_Items
> > 
> > But I'd like to turn that into an actual bug list on github or the like.

I've (slowly) started this process now:
https://github.com/KSPP/linux/issues/

> > I wonder if working on something like this:
> > - set_memory_*() needs __must_check and/or atomicity
> > would be interesting?
> > 
> > The idea there is that set_memory_*() calls can fail, so callers should
> > likely be handling errors correctly. Adding the "__must_check" attribute
> > and fixing all the callers would be nice (and certainly touches the
> > memory management code!)
> 
> This is a great starting task for me. So for this task, basically I need to add __must_check attribute to set_memory_*() functions and fix all the callers to make sure they check the return values. Do I understand correctly?

Yup, that's right. I've added that issue with some more details now:
https://github.com/KSPP/linux/issues/7

> Also I have some other questions:
> Is there any requirement for the patches? e.g. based on which kernel version? how many individual patches?

I recommend basing your patches on either the last full release (v5.3
currently) or, if you need something newer, on the -rc2 of the next
release (v5.4-rc2). We are, however, in the middle of the merge window,
so -rc2 doesn't exist yet. :)

The general details on submitting patches apply:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Feel free to post "RFC" patches here to this list first if you want some
initial feedback. (Though I recommend still including maintainers in Cc
to get their feedback too.)

-- 
Kees Cook