[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jLSrN6xCu+wYCXYj1z4sxC3J_FUNiF9B2opf9Ureh3_KA@mail.gmail.com>
Date: Fri, 27 Jan 2017 12:47:16 -0800
From: Kees Cook <keescook@...omium.org>
To: Hoeun Ryu <hoeun.ryu@...il.com>
Cc: Richard Weinberger <richard@....at>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: I'd like to contribute to this project.
On Fri, Jan 27, 2017 at 11:03 AM, Hoeun Ryu <hoeun.ryu@...il.com> wrote:
> On Fri, Jan 27, 2017 at 6:36 AM Kees Cook <keescook@...omium.org> wrote:
>>
>> On Thu, Jan 26, 2017 at 6:49 AM, Hoeun Ryu <hoeun.ryu@...il.com> wrote:
>> > On Thu, Jan 26, 2017 at 4:41 AM, Kees Cook <keescook@...omium.org> wrote:
>> >> On Wed, Jan 25, 2017 at 6:01 AM, Hoeun Ryu <hoeun.ryu@...il.com> wrote:
>> >>> Hi. I'm Hoeun Ryu.
>> >>
>> >> Hi! Nice to meet you!
>> >>
>> >>> I've been reading arm/arm64 and mm/fs kernel code for the last few years.
>> >>> I stumbled upon the wiki page for this project and found this project seems
>> >>> very interesting.
>> >>> I think I can start to contibute to this project from porting small parts of
>> >>> PAX/GRSEC features that you guys haven't worked on yet.
>> >>
>> >> Sure, that would be very welcome. Are there features you're especially
>> >> interested in?
>> >>
>> >
>> > I tried to find out what features PAX/GRKERNSEC provides reading
>> > grsecurity wiki pages and the patch file today.
>> > It might take a week or two to find adequate features for me to tackle.
>> > But my guess after few hours of a brief investigation is `Deter
>> > exploit bruteforcing (GRKERNSEC_BRUTE)`
>> > Do you think the feature is worth it to you guys ? If not, please
>> > recommend others.
>>
>> I'd really like to see this, yes. There have been attempts in the past
>> that got derailed. I strongly think it should be part of the kernel
>> (and not glibc, as got proposed):
>>
>> https://lkml.org/lkml/2014/12/24/306
>>
>> I think it's worth trying it again.
>
> Ok. I will start to investigate the history of Richard's try for the
> feature and GRKERNSEC_BRUTE itself and how I can narrow the gap
> between the opinions.
Sounds good! Feel free to bounce ideas off this list too. :)
>> >>> I'd like to start from something trivial so I can do it in my free time.
>> >>> It's also ok to work with someone who are working on a big patch series if
>> >>> you need help.
>> >>
>> >> Just looking through the list of things on the wiki, how about this?
>> >> - add zeroing of copy_from_user on failure test to test_usercopy.c
>> >>
>> >> The issue here is that when a copy_from_user() call fails (for
>> >> whatever reason), the kernel is supposed to clear the destination
>> >> buffer with zeros to make sure nothing is accidentally exposed later
>> >> (if, say, it is copied back to userspace at a later time). We saw a
>> >> few instances where this protective copying wasn't happening, but
>>
>> >> there was no regression test for it.
>> >>
>
> What are the few instances? Invaild sized accesses ?
> You mean that the regression is performance degradation ?
Sorry, meant just a test for a regression in behavior. As in, what
happens if you do something like this:
char buf[1024];
memset(buf, 'A', sizeof(buf));
copy_from_user(buf, NULL, sizeof(buf));
That copy_from_user() will fail (invalid address NULL), and the
contents of buf should be zeroed by the failing copy_from_user(). Some
architectures weren't doing this correctly, so making sure we add this
kind of a test to lib/test_usercopy.c would add some good coverage for
bugs we've fixed in the past.
>
>> >> Adding a test to lib/test_usercopy.c for the zeroing would be nice to
>> >> have, and should be a relatively small change.
>> >>
>
> What can be the test cases ?
> Performing copy_to/from_user against different kind of src/dst like
> stack, slab and simple kmalloc()ed pages and checking
> if the results are what they should be ?
> Or just checking if zeroing is done by comparing the content of memory to 0 ?
See my above example. A failed copy_from_user should zero the entire
length of the buffer that was passed in.
-Kees
--
Kees Cook
Nexus Security
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.
