[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7D98C4BB-62FA-4393-B24A-E213FB340A94@digitalocean.com>
Date: Thu, 26 Sep 2019 09:57:58 -0500
From: Tianlin Li <tli@...italocean.com>
To: Kees Cook <keescook@...omium.org>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: Introduction and get involved
> On Sep 24, 2019, at 6:12 PM, Kees Cook <keescook@...omium.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
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
