Get involved

Get involved

[Romain Perier]

Hi,

I have discussed briefly with Kees on IRC, who has suggested to me to
say hello here :) .
As part of the debian kernel team (still a padawan), I would like to
be more involved on upstream on security related topics.

Kees confirmed that the todolist at
http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work
is up-to-date.

Which task would you recommend (I was mostly involved on SoC related
tasks on upstream in the mainline kernel) ?

I am on ##linux-hardened on IRC (nick: rperier)

Thanks,
Regards,
Romain

Re: Get involved

[Romain Perier]

Hi,

I will probably take the task "WARN on kfree() of ERR_PTR range" , and
then help to port to refcount_t   (I plan to use linux-next).
I have asked for an account to jmorris, so I can mark the task as "WIP".

Regards,
Romain

Le mar. 4 juin 2019 à 19:08, Romain Perier <romain.perier@gmail.com> a écrit :
>
> Hi,
>
> I have discussed briefly with Kees on IRC, who has suggested to me to
> say hello here :) .
> As part of the debian kernel team (still a padawan), I would like to
> be more involved on upstream on security related topics.
>
> Kees confirmed that the todolist at
> http://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Work
> is up-to-date.
>
> Which task would you recommend (I was mostly involved on SoC related
> tasks on upstream in the mainline kernel) ?
>
> I am on ##linux-hardened on IRC (nick: rperier)
>
> Thanks,
> Regards,
> Romain

Re: Get involved

[Shyam Saini]

Hi Roman,

> I will probably take the task "WARN on kfree() of ERR_PTR range" , and
> then help to port to refcount_t   (I plan to use linux-next).
> I have asked for an account to jmorris, so I can mark the task as "WIP".


I'm already on that task, would you mind to proceed with some other task.
Kees suggested me this task sometime ago.
I'll be sending patches this weekend.

Thanks a lot,
Shyam

Re: Get involved

[Romain Perier]

Hi,

Okay, np. I will select another one then :) (hehe that's the game ;) )

@Kees: do you have something in mind (as a new task) ?

Thanks,
Regards,
Romain


Le ven. 7 juin 2019 à 20:04, Shyam Saini <mayhs11saini@gmail.com> a écrit :
>
> Hi Roman,
>
> > I will probably take the task "WARN on kfree() of ERR_PTR range" , and
> > then help to port to refcount_t   (I plan to use linux-next).
> > I have asked for an account to jmorris, so I can mark the task as "WIP".
>
>
> I'm already on that task, would you mind to proceed with some other task.
> Kees suggested me this task sometime ago.
> I'll be sending patches this weekend.
>
> Thanks a lot,
> Shyam

Re: Get involved

[Kees Cook]

On Fri, Jun 07, 2019 at 08:16:42PM +0200, Romain Perier wrote:
> Hi,

Hi! Sorry for the late reply: I've been travelling this week. :P

> Okay, np. I will select another one then :) (hehe that's the game ;) )
> 
> @Kees: do you have something in mind (as a new task) ?

Shyam, you'd also started FIELD_SIZEOF refactoring, but never sent a v2
patch if I was following correctly? Is there one or the other of these
tasks you'd like help with?  https://patchwork.kernel.org/patch/10900187/

Romain, what do you think about reviewing NLA code? I'd mentioned a
third task here:
https://www.openwall.com/lists/kernel-hardening/2019/04/17/8

Quoting...


- audit and fix all misuse of NLA_STRING

This is a following up on noticing the misuse of NLA_STRING (no NUL
terminator), getting used with regular string functions (that expect a
NUL termination):
https://lore.kernel.org/lkml/1519329289.2637.12.camel@sipsolutions.net/T/#u

It'd be nice if someone could inspect all the NLA_STRING
representations and find if there are any other problems like this
(and see if there was a good way to systemically fix the problem).



For yet another idea would be to get syzkaller[1] set up and enable
integer overflow detection (by adding "-fsanitize=signed-integer-overflow"
to KBUILD_CFLAGS) and start finding and fixes cases like this[2].

Thanks and let me know what you think!

-Kees

[1] https://github.com/google/syzkaller/blob/master/docs/linux/setup.md
[2] https://lore.kernel.org/lkml/20180824215439.GA46785@beast/


-- 
Kees Cook

Re: Get involved

[Shyam Saini]

Hi Kees,

>
> Hi! Sorry for the late reply: I've been travelling this week. :P

> > Okay, np. I will select another one then :) (hehe that's the game ;) )
> >
> > @Kees: do you have something in mind (as a new task) ?
> Shyam, you'd also started FIELD_SIZEOF refactoring, but never sent a v2
> patch if I was following correctly? Is there one or the other of these
> tasks you'd like help with?  https://patchwork.kernel.org/patch/10900187/

sorry for being too late.

You assigned me 3 tasks
1) FIELD_SIZEOF
2) WARN on kfree() of ERR_PTR range
3) NLA_STRING

I'll send patches for task 1 and 2 today or tomorrow.

If Roman is taking NLA_STRING task, I'd pick some other once i send
patches for 1 and 2.


> Romain, what do you think about reviewing NLA code? I'd mentioned a
> third task here:
> https://www.openwall.com/lists/kernel-hardening/2019/04/17/8
>
> Quoting...
>
>
> - audit and fix all misuse of NLA_STRING
>
> This is a following up on noticing the misuse of NLA_STRING (no NUL
> terminator), getting used with regular string functions (that expect a
> NUL termination):
> https://lore.kernel.org/lkml/1519329289.2637.12.camel@sipsolutions.net/T/#u
>
> It'd be nice if someone could inspect all the NLA_STRING
> representations and find if there are any other problems like this
> (and see if there was a good way to systemically fix the problem).
>
>
>
> For yet another idea would be to get syzkaller[1] set up and enable
> integer overflow detection (by adding "-fsanitize=signed-integer-overflow"
> to KBUILD_CFLAGS) and start finding and fixes cases like this[2].
>
> Thanks and let me know what you think!
>
> -Kees
>
> [1] https://github.com/google/syzkaller/blob/master/docs/linux/setup.md
> [2] https://lore.kernel.org/lkml/20180824215439.GA46785@beast/
>
>
> --
> Kees Cook

Re: Get involved

[Romain Perier]

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

Hi,

Thanks for these details.

Yeah if this is okay for you , I will pick the task for NLA_STRING . I can
mark it as WIP on the Wiki.

Regards,
Romain

Le sam. 8 juin 2019 à 08:02, Shyam Saini <mayhs11saini@gmail.com> a écrit :

> Hi Kees,
>
> >
> > Hi! Sorry for the late reply: I've been travelling this week. :P
>
> > > Okay, np. I will select another one then :) (hehe that's the game ;) )
> > >
> > > @Kees: do you have something in mind (as a new task) ?
> > Shyam, you'd also started FIELD_SIZEOF refactoring, but never sent a v2
> > patch if I was following correctly? Is there one or the other of these
> > tasks you'd like help with?
> https://patchwork.kernel.org/patch/10900187/
>
> sorry for being too late.
>
> You assigned me 3 tasks
> 1) FIELD_SIZEOF
> 2) WARN on kfree() of ERR_PTR range
> 3) NLA_STRING
>
> I'll send patches for task 1 and 2 today or tomorrow.
>
> If Roman is taking NLA_STRING task, I'd pick some other once i send
> patches for 1 and 2.
>
>
> > Romain, what do you think about reviewing NLA code? I'd mentioned a
> > third task here:
> > https://www.openwall.com/lists/kernel-hardening/2019/04/17/8
> >
> > Quoting...
> >
> >
> > - audit and fix all misuse of NLA_STRING
> >
> > This is a following up on noticing the misuse of NLA_STRING (no NUL
> > terminator), getting used with regular string functions (that expect a
> > NUL termination):
> >
> https://lore.kernel.org/lkml/1519329289.2637.12.camel@sipsolutions.net/T/#u
> >
> > It'd be nice if someone could inspect all the NLA_STRING
> > representations and find if there are any other problems like this
> > (and see if there was a good way to systemically fix the problem).
> >
> >
> >
> > For yet another idea would be to get syzkaller[1] set up and enable
> > integer overflow detection (by adding
> "-fsanitize=signed-integer-overflow"
> > to KBUILD_CFLAGS) and start finding and fixes cases like this[2].
> >
> > Thanks and let me know what you think!
> >
> > -Kees
> >
> > [1] https://github.com/google/syzkaller/blob/master/docs/linux/setup.md
> > [2] https://lore.kernel.org/lkml/20180824215439.GA46785@beast/
> >
> >
> > --
> > Kees Cook
>

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

Re: Get involved

[Shyam Saini]

On Sat, Jun 8, 2019 at 1:47 PM Romain Perier <romain.perier@gmail.com> wrote:
>
> Hi,
>
> Thanks for these details.
>
> Yeah if this is okay for you , I will pick the task for NLA_STRING . I can mark it as WIP on the Wiki.
yes, I'm okay with it

Thanks!!

Get involved

[Oscar Carter]

Hi, my name is Oscar. I would like to get involved in the kernel self protection
project because I love the software security and I think this is one of the most
challenging fields.

I have experience in microcrontrollers and working with low level software, but
my experience with the linux kernel development is a few commits in the staging
area.

For now, and due to my low experience with the linux kernel code and software
security, I do not care about the area and task to be done. What I pretend is to
help this great community and improve my knowledge and skills in this
challenging field.

So, I would like to know if I can be assigned to some task that suits me. I've
taken a look at https://github.com/KSPP/linux/issues but I don't know which task
to choose and if something else is working on it.

Thanks,

Oscar Carter

RE: Get involved

[Gote, Nitin R]

Hi Jann,

Thank you for the input.
I have started working on these and I will send a patch for review soon.

Best Regards,
Nitin Gote. 

-----Original Message-----
From: Jann Horn [mailto:jannh@google.com] 
Sent: Tuesday, June 18, 2019 5:06 PM
To: Gote, Nitin R <nitin.r.gote@intel.com>
Cc: Kees Cook <keescook@chromium.org>; Kernel Hardening <kernel-hardening@lists.openwall.com>; Shyam Saini <mayhs11saini@gmail.com>
Subject: Re: Get involved

On Tue, Jun 18, 2019 at 1:20 PM Gote, Nitin R <nitin.r.gote@intel.com> wrote:
>
> Hi Kees,
>
> I would like to be involved on upstream on security related topics.
> I'm planning to work on below items from KSPP to do list:
>         1. deprecate strcpy() in favor of strscpy().
>         2. deprecate strlcpy() in favor of strscpy().
>         3. deprecate strncpy() in favor of strscpy(), strscpy_pad(), or str2mem_pad().
>
> I'm thinking of following approach for above items :
>
> Approach 1 : Do we need to blindly replace strcpy() or strlcpy() or strncpy() with strscpy() in entire linux kernel tree ?
>                  (This approach is time consuming as lots of changes 
> need to do in single patch or multiple patch)

Linus wrote at <https://lore.kernel.org/lkml/CA+55aFwHCPnPf_xs6GJu37UBvg_BSiFPH2uQps7qNNFV8Ej-SA@mail.gmail.com/>:

| I wrote a longish merge message about why - but it boils down to me 
| hating the mindless trivial conversion patches. Which were not in the 
| pull request, but I want to make it clear to everybody that I have 
| absolutely zero interest in seeing such patches. I want to encourage 
| judicious use of strscpy() in new code, or in code that gets modified 
| because it is buggy or is updated for other reasons (and thus thought 
| about and tested), but I am *not* going to accept patches that do mass 
| conversions of strlcpy or strncpy to the new interface.

From the "longish merge message" at
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30c44659f4a3e7e1f9f47e895591b4b40bf62671>:

| Every time we introduce a new-and-improved interface, people start 
| doing these interminable series of trivial conversion patches.
|
| And every time that happens, somebody does some silly mistake, and the 
| conversion patch to the improved interface actually makes things worse.
| Because the patch is mindnumbing and trivial, nobody has the attention 
| span to look at it carefully, and it's usually done over large 
| swatches of source code which means that not every conversion gets tested.
|
| So I'm pulling the strscpy() support because it *is* a better interface.
| But I will refuse to pull mindless conversion patches.  Use this in 
| places where it makes sense, but don't do trivial patches to fix 
| things that aren't actually known to be broken.

Unless Linus changed his mind about that in the years since then, you probably don't want to spend your time writing a patch Linus doesn't want.

> Approach 2 : Do we need to implement script or some mechanism which checks for functions likes strcpy(), strlcpy() or strncpy() and
>                  throw some deprecate error, if these functions found and suggest to use strscpy() ?

It would probably make sense to add warnings for strlcpy() and
strncpy() in scripts/checkpatch.pl.

Re: Get involved

[Jann Horn]

On Tue, Jun 18, 2019 at 1:20 PM Gote, Nitin R <nitin.r.gote@intel.com> wrote:
>
> Hi Kees,
>
> I would like to be involved on upstream on security related topics.
> I'm planning to work on below items from KSPP to do list:
>         1. deprecate strcpy() in favor of strscpy().
>         2. deprecate strlcpy() in favor of strscpy().
>         3. deprecate strncpy() in favor of strscpy(), strscpy_pad(), or str2mem_pad().
>
> I'm thinking of following approach for above items :
>
> Approach 1 : Do we need to blindly replace strcpy() or strlcpy() or strncpy() with strscpy() in entire linux kernel tree ?
>                  (This approach is time consuming as lots of changes need to do in single patch or multiple patch)

Linus wrote at <https://lore.kernel.org/lkml/CA+55aFwHCPnPf_xs6GJu37UBvg_BSiFPH2uQps7qNNFV8Ej-SA@mail.gmail.com/>:

| I wrote a longish merge message about why - but it boils down to me
| hating the mindless trivial conversion patches. Which were not in the
| pull request, but I want to make it clear to everybody that I have
| absolutely zero interest in seeing such patches. I want to encourage
| judicious use of strscpy() in new code, or in code that gets modified
| because it is buggy or is updated for other reasons (and thus thought
| about and tested), but I am *not* going to accept patches that do mass
| conversions of strlcpy or strncpy to the new interface.

>From the "longish merge message" at
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30c44659f4a3e7e1f9f47e895591b4b40bf62671>:

| Every time we introduce a new-and-improved interface, people start doing
| these interminable series of trivial conversion patches.
|
| And every time that happens, somebody does some silly mistake, and the
| conversion patch to the improved interface actually makes things worse.
| Because the patch is mindnumbing and trivial, nobody has the attention
| span to look at it carefully, and it's usually done over large swatches
| of source code which means that not every conversion gets tested.
|
| So I'm pulling the strscpy() support because it *is* a better interface.
| But I will refuse to pull mindless conversion patches.  Use this in
| places where it makes sense, but don't do trivial patches to fix things
| that aren't actually known to be broken.

Unless Linus changed his mind about that in the years since then, you
probably don't want to spend your time writing a patch Linus doesn't
want.

> Approach 2 : Do we need to implement script or some mechanism which checks for functions likes strcpy(), strlcpy() or strncpy() and
>                  throw some deprecate error, if these functions found and suggest to use strscpy() ?

It would probably make sense to add warnings for strlcpy() and
strncpy() in scripts/checkpatch.pl.

RE: Get involved

[Gote, Nitin R]

Hi Kees,

I would like to be involved on upstream on security related topics.
I'm planning to work on below items from KSPP to do list:
	1. deprecate strcpy() in favor of strscpy().
	2. deprecate strlcpy() in favor of strscpy().
	3. deprecate strncpy() in favor of strscpy(), strscpy_pad(), or str2mem_pad().

I'm thinking of following approach for above items :

Approach 1 : Do we need to blindly replace strcpy() or strlcpy() or strncpy() with strscpy() in entire linux kernel tree ?
	         (This approach is time consuming as lots of changes need to do in single patch or multiple patch)

Approach 2 : Do we need to implement script or some mechanism which checks for functions likes strcpy(), strlcpy() or strncpy() and 
	         throw some deprecate error, if these functions found and suggest to use strscpy() ? 

Could you please provide some point on these ? 

If none of above approach is correct, Could you please give some idea, So that I can start work on mentioned items ?
One more question, Is there any CI is maintained for KSPP ? If yes, how to check CI current status ?

Thanks and Regards,
Nitin Gote.

-----Original Message-----
From: Shyam Saini [mailto:mayhs11saini@gmail.com] 
Sent: Saturday, June 8, 2019 11:32 AM
To: Kees Cook <keescook@chromium.org>
Cc: Romain Perier <romain.perier@gmail.com>; Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: Get involved

Hi Kees,



>
> Hi! Sorry for the late reply: I've been travelling this week. :P

> > Okay, np. I will select another one then :) (hehe that's the game ;) 
> > )
> >
> > @Kees: do you have something in mind (as a new task) ?
> Shyam, you'd also started FIELD_SIZEOF refactoring, but never sent a 
> v2 patch if I was following correctly? Is there one or the other of 
> these tasks you'd like help with?  
> https://patchwork.kernel.org/patch/10900187/

sorry for being too late.

You assigned me 3 tasks
1) FIELD_SIZEOF
2) WARN on kfree() of ERR_PTR range
3) NLA_STRING

I'll send patches for task 1 and 2 today or tomorrow.

If Roman is taking NLA_STRING task, I'd pick some other once i send patches for 1 and 2.


> Romain, what do you think about reviewing NLA code? I'd mentioned a 
> third task here:
> https://www.openwall.com/lists/kernel-hardening/2019/04/17/8
>
> Quoting...
>
>
> - audit and fix all misuse of NLA_STRING
>
> This is a following up on noticing the misuse of NLA_STRING (no NUL 
> terminator), getting used with regular string functions (that expect a 
> NUL termination):
> https://lore.kernel.org/lkml/1519329289.2637.12.camel@sipsolutions.net
> /T/#u
>
> It'd be nice if someone could inspect all the NLA_STRING 
> representations and find if there are any other problems like this 
> (and see if there was a good way to systemically fix the problem).
>
>
>
> For yet another idea would be to get syzkaller[1] set up and enable 
> integer overflow detection (by adding "-fsanitize=signed-integer-overflow"
> to KBUILD_CFLAGS) and start finding and fixes cases like this[2].
>
> Thanks and let me know what you think!
>
> -Kees
>
> [1] 
> https://github.com/google/syzkaller/blob/master/docs/linux/setup.md
> [2] https://lore.kernel.org/lkml/20180824215439.GA46785@beast/
>
>
> --
> Kees Cook