kernel-hardening - RE: Get involved

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <12356C813DFF6F479B608F81178A5615869EB0@BGSMSX101.gar.corp.intel.com>
Date: Tue, 18 Jun 2019 10:36:35 +0000
From: "Gote, Nitin R" <nitin.r.gote@...el.com>
To: Kees Cook <keescook@...omium.org>
CC: Kernel Hardening <kernel-hardening@...ts.openwall.com>, Shyam Saini
	<mayhs11saini@...il.com>
Subject: RE: Get involved

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@...il.com] 
Sent: Saturday, June 8, 2019 11:32 AM
To: Kees Cook <keescook@...omium.org>
Cc: Romain Perier <romain.perier@...il.com>; Kernel Hardening <kernel-hardening@...ts.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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.