[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Oct 2016 11:32:07 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Kees Cook <keescook@...omium.org>
Cc: Colin Vidal <colin@...dal.org>, Andy Lutomirski <luto@...nel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: self introduction
On Mon, Oct 10, 2016 at 1:57 PM, Kees Cook <keescook@...omium.org> wrote:
> On Sun, Oct 9, 2016 at 5:34 AM, Colin Vidal <colin@...dal.org> wrote:
>> My name is Colin Vidal. I am currently a PhD student in computer
>> science. My researches consist on building a dedicated specific
>> language on top of JavaScript in order to handle asynchronous events in
>> a synchronous style. Hence, with a direct relation between the control
>> flow and the instruction flow.
>>
>> Beside my researches, I am taking up the Eudyptula Challenge (task 15
>> submitted). It helps me to have a global view of the kernel
>> (organization, tree, some features), but it is not enough to get
>> involved in serious development. Therefore, I am looking for task I can
>> accomplish to be involved into real kernel development!
>
> Hi! Welcome to the fun! :)
>
> I see there's already a thread getting into the HARDENED_ATOMIC
> effort, though I thought I might bring up some other areas too, in
> case they entice you as well. You've got some background in control
> flow -- have you spent much time in compiler internals? The recent
> addition of the gcc plugin infrastructure means there's a much wider
> ability for the kernel to do compiler tricks now. Two things that come
> to mind for CFI when looking at the existing PaX/Grsecurity gcc
> plugins are the kernexec plugin (which, AIUI, is mainly a weak form of
> SMEP emulation on x86, using simple CFI to keep the high bit set on
> all kernel function calls) which I think would be easy to extract as a
> stand-alone plugin:
>
> https://github.com/linux-scraping/linux-grsecurity/blob/grsec-test/scripts/gcc-plugins/kernexec_plugin.c
>
> And at the other end of the spectrum is the RAP plugin (which does a
> portion of PaX's full RAP, though there appear to be some non-trivial
> kernel changes need to support it, e.g. per-cpu PGD):
>
> https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf
Linus has loudly poo-pooed per-cpu PGD, and I'm not sure I disagree.
It would be *really* nice to find a clean way to do RAP without it.
>
>> I still don't have yet a narrow idea about where I can begin. I like
>> though the idea of kernel self protection. For instance, I find the VM-
>> mapped stack to be really interesting, but I think it is an overkill as
>> a beginning, and a lot of work have already been done on it. On the
>> architecture point-of-view, I have a preference of x86 since I only
>> have this hardware for now, but I can work on ARM and others with QEMU
>> too.
>
> A piece missing from vmap-stack (I think) is having guard pages at
> _both_ ends of the kernel stack. Andy Lutomirski surely knows better
> than I do, but I'm hoping he's working on looking at PCID-based SMAP
> emulation. (Hi Andy!) :)
>
Hi! I'm not presently working on it, and I'm a bit swamped, but maybe soon.
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.
