Date: Mon, 11 Jan 2016 09:44:49 +0000 From: "Reshetova, Elena" <elena.reshetova@...el.com> To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "keescook@...omium.org" <keescook@...omium.org> Subject: RE: Introduction and task request >On 01/06/2016 12:57 AM, Kees Cook wrote: > On Mon, Dec 21, 2015 at 3:16 AM, Reshetova, Elena > <elena.reshetova@...el.com> wrote: >>>> What would be the reasonable task for me to do? >> >>> I always suggest people work on stuff that interests them. Do you >>> have any specific areas you like working on, or exploits you'd like to see >>> stopped? >> >> I guess ideally people subscribed to this list want all exploits to >> be stopped >> :) But seriously I don't have any preference at least for now. Since >> I will have to learn a lot in this area I want to start from >> something which would be a reasonable and useful for this project >> piece of work, that's why I was asking for suggestions. >> >>>> I am quite a newbie in proper kernel development work (but not a >>>> newbie in platform security), so please as initial task do not >>>> through to me the biggest dead animal out there with the task to revive >>>> it. >> >>> Heh, understood. We'll be happy to assist you through whatever parts >>> you might want help with. >> >> Thank you! >> >>>> It is going to be a learning exercise for me at least at the >>>> beginning, but I am hoping to learn fast and start bringing value >>>> to the project. >> >>> I had mentioned PAX_USERCOPY earlier. I'm not sure how much work >>> that'll be, but extracting it would be the first step, and you can >>> go from there. There's no one actively working on it at the moment, >>> and it would be very nice to have. >> >> Casey is taking care of that, so I will leave it to him. >> >>> Or perhaps looking into the prior BPF_HARDEN work (currently this >>> just disables eBPF, but it used to try to defend against trivial >>> heap-sprays). >> >> This sounds smth that I can look into. I will be back when I have >> something reasonable ready or researched enough for sensible >> questions/discussion points. I will be away for long holidays until >> Jan 10, but hoping to return with plenty of energy :) > > The original name was JIT_HARDEN, prior to grsecurity's 3.16 patches > (which just disable JIT entirely): > https://github.com/slashbeast/grsecurity-scrape/blob/master/test/grsec > urity-3.0-3.15.5-201407170639.patch > > I think it'd be nice to have the the JIT hardening feature, since it > does block heap-sprayed immediate values and probably other stuff, but > I haven't studied it. >Was on my todo list as well for some time, but if you have some cycles in >spare, go for it. We recently discussed that it would be nice if it could be >done on a more generic level, in the sense to do [e]BPF insns rewrite for >blinding, so that each JIT would not >need to add up even more complexity >and/or duplicate efforts. Do you have any pointers for this discussion that I can read it also? Best Regards, Elena. Download attachment "smime.p7s" of type "application/pkcs7-signature" (7586 bytes)
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.