Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Jan 2016 09:44:49 +0000
From: "Reshetova, Elena" <>
To: ""
	<>, ""
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
> <> 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):
> 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,

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.