Re: Hello world! Student interested in getting involved.

[Ahmed Soliman <ahmedsoliman0x666@gmail.com>]

well in this case I tried searching and researching more and I found
the idea for Rootkit blocking using KVM virtualization, it is
described here:
https://kernelnewbies.org/KernelProjects/VirtRootkitBlocker

I CCed to riel
It took me a while to re-learn how to setup kernel developing
environment, via buildroot for generating qemu
images for paravirtualized OS debugging, and learning about mm and KVM (WIP).
I am not sure if this is the right place but I think anti rootkits can
be good hardening technique, I made sure
that no one is working on this (no patches anywhere), and my
team-mates are happy with the idea so I hope we are
ready to start. Just in case anyone tries to drift me off the idea, I
do like it enough so I already talked to my professor
and my team-mates about it. I just wanted to know which tree should I
be working on, should it be the kernel hardening
tree or the tree used for kvm or memory management.
Kind regards.

On 13 February 2018 at 13:38, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 12 February 2018 at 23:01, Kees Cook <keescook@chromium.org> wrote:
>> On Sat, Feb 10, 2018 at 11:18 AM, Ahmed Soliman
>> <ahmedsoliman0x666@gmail.com> wrote:
>>> I am student, currently studying computer and communication engineering, My
>>> relevant academic background is undergraduate level courses in operating
>>> systems, system software, compiler theory, architecture, microprocessors.
>>> Well most of which are outdated stuff anyway but I have some ideas. My real
>>
>> Welcome to the list!
>>
>>> background comes from Playing CTFs in my free time (which is basically 24/7)
>>> doing mainly Reverse engineering and Binary exploitation, I have done 2~3
>>> hello world kernel exploit dev for learning. so I have the basic knowledge,
>>
>> Excellent; CTFs can be extremely educational. There aren't enough
>> kernel CTFs, IMO. :)
>>
>>> And I use hand tweaked Gentoo! I have 1 documentation kernel patch \o/.
>>
>> Hey, that's a good place to start! What was fixed?
>>
>>> I am exploiting the fact that we shall be doing Software Engineering course
>>> This semester, so to enforce myself to get started developing for the
>>> kernel, I was guided here though long searching journey with #kernelnewbies
>>> and approaching many couple of maintainers in general.
>>>
>>> I always experienced people asking me even on kernelnewbies why I want to
>>> write stuff for kernel, well it is just for pure fun and I like doing almost
>>> low level security. And low level security requires being aware with kernel.
>>> Please just don't try to send me off. And I hope no one gets the wrong idea
>>> that I am only doing this for school.
>>
>> You've got the primary element: desire to work on it. :) There aren't
>> a lot of people interested in low level code, and even fewer
>> interested in security, so we'd love to help however we can.
>>
>>> Anyway I am interested in this implementing KASLR for ARM, I just wanted to
>>> make sure that no one is working on that because this is major school
>>> requirement, we are assumed to deliver a self contained "something" that
>>> isn't ours and not someone's else.
>>
>> Ard (now on CC) implemented a first-pass at this already, but it
>> likely needs some more tweaking and running down of any loose ends.
>>
>> See here:
>> http://www.openwall.com/lists/kernel-hardening/2017/08/14/2
>>
>>> The reason I chose this one is that I think that is the only one that I
>>> understand (in a very abstract level) among all of them. so it should be the
>>> easiest way to kick start in my opinion.
>>> Assuming that I am right, I wanted to state that the only ARM32 hardware I
>>> own is raspberry pi zero, and Qemu of course, should that be enough please
>>> do let me know, and I would appreciate any reading materials provided I am
>>> already reading through wiki but there could be hidden gems that I missed.
>>
>> I'll let Ard take over; but between Qemu and real hardware you should
>> be set. One of the tricky parts of arm32 is how many earlier CPU types
>> there were, which can make some aspects more difficult to test. In the
>> worst case, you can just mark it as available on certain hardware.
>>
>
> The latest version of my kaslr branch is feature complete, but I get
> some hard to diagnose boot errors in automated boot testing on
> kernelci.org
>
> However, over the past few months I did not get a single query from
> anyone about how the work was progressing, and KASLR is a rather
> intrusive change, so I am reluctant to spend time and/or endorse
> others doing so for a feature that will require a substantial
> maintenance effort without any real benefit to anyone.