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@xxxxxxxxxx> wrote: > On 12 February 2018 at 23:01, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Sat, Feb 10, 2018 at 11:18 AM, Ahmed Soliman >> <ahmedsoliman0x666@xxxxxxxxx> 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.
