Date: Sat, 28 Jan 2017 04:03:01 +0900 From: Hoeun Ryu <hoeun.ryu@...il.com> To: Kees Cook <keescook@...omium.org> 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 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. > > >>> 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 ? > >> 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 ? > > >> Let me know if that sounds good to you, and thanks! > >> > > > > It sounds good, of course. I can work on it. > > Your help during my struggle for it will be appreciated. > > Cool, let us know how we can help. :) > > > -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.