[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Feb 2017 22:53:05 +0530
From: Vaishali Thakkar <vaishali.thakkar@...cle.com>
To: Kees Cook <keescook@...omium.org>
Cc: Eddie Kovsky <ewk@...ovsky.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Getting started
On Saturday 04 February 2017 05:43 AM, Kees Cook wrote:
> On Thu, Feb 2, 2017 at 8:28 PM, Vaishali Thakkar
> <vaishali.thakkar@...cle.com> wrote:
>> On Friday 03 February 2017 08:41 AM, Eddie Kovsky wrote:
>>>
>>> On 01/30/17, Kees Cook wrote:
>>>>
>>>> On Mon, Jan 30, 2017 at 5:41 AM, Vaishali Thakkar
>>>> <vaishali.thakkar@...cle.com> wrote:
>>>>>
>>>>> On Monday 30 January 2017 12:13 AM, Eddie Kovsky wrote:
>>>>>
>>>>>> I'm interested in helping out with this project.
>>>>>>
>>>>>> I have a few small patches in the kernel. I just finished the Eudyptula
>>>>>> Challenge and I'm looking for places where I can continue to
>>>>>> contribute.
>>>>
>>>>
>>>> Hi! Welcome to the list. :)
>>>>
>>>>>> I've been reading the list for several months now. I think I have a
>>>>>> general
>>>>>> understanding of the development process. Is there a specific TODO item
>>>>>> I
>>>>>> could start off with?
>>>>
>>>>
>>>> What areas of the kernel are you the most familiar with, and/or what
>>>> things are you interested in working on? That could help me tailor
>>>> some suggestions.
>>>>
>>>>> Here, is one TODO list:
>>>>>
>>>>> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
>>>>>
>>>>> Although I think few people are already working on some of these things.
>>>>> May be you can also check the archives of a mailing list.
>>>>
>>>>
>>>> The list is a bit terse (it's mostly been a brain dump as things come
>>>> up), but yeah, if you see something there and want to know more, just
>>>> ask. I'm happy to expand on any of them.
>>>>
>>>
>>> I noticed there's been some activity recently with HARDENED_USERCOPY.
>>> And I looked over how mm/usercopy.c was merged in from the grsecurity
>>> patch. I'm curious about this TODO item:
>>>
>>> Identify and extend HARDENED_USERCOPY to other usercopy functions
>>> (e.g. maybe csum_partial_copy_from_user, csum_and_copy_from_user,
>>> csum_and_copy_to_user, csum_partial_copy_nocheck?)
>>>
>>> It doesn't look like anyone is working on this task right now. But it's
>>> not
>>> obvious (to me) what needs to happen to make progress with this. Would
>>> this
>>> be a good task to start off with?
>>
>>
>> Hi,
>>
>> You may want to read this thread:
>> https://patchwork.kernel.org/patch/9409557/
>>
>> Kees, may be we should remove this item from the TODO list?
>
> Hm, yeah, or rename it to "find any other APIs that look like
> copy_to/from_user()". I think Mark already looked through these. Were
> there any remaining?
AFAIK, no. May be get_user, put_user. But I guess it makes sense to
change them after uaccess unification work.
Previously I found few API functions but they were eventually calling
copy_from_user.
> As for a thing to work about how about this:
> - provide mechanism to check for ro_after_init memory areas, and
> reject structures not marked ro_after_init in vmbus_register()
>
> The idea here would be to provide a mechanism functions can call to
> verify that their arguments are const or ro_after_init. I think it'd
> look a lot like the stuff in kernel/extable.c like
> kernel_text_address(), but it'd need to ask "is this variable in the
> rodata section? (Which is complicated by dealing with module rodata
> sections.)
>
> Then vmbus_register() could be modified to require that its arguments
> are const or ro_after_init.
>
> -Kees
>
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.
