[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 Jan 2016 01:11:36 +0100
From: Daniel Borkmann <daniel@...earbox.net>
To: keescook@...omium.org
CC: kernel-hardening@...ts.openwall.com
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/grsecurity-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.
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.
