Hello world! Student interested in getting involved.

Hello world! Student interested in getting involved.

[Ahmed Soliman]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

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
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, And I use hand tweaked Gentoo! I have 1 documentation kernel
patch \o/.

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.

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.

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.
Also what directories that I should start exploring, this is extremely
important for me. I was past google summer of code student. And the best
assistance my mentors ever provided me is the folder or code files that
Should play with.

Kind regards.
Ahmed.

[-- Attachment #2: Type: text/html, Size: 2415 bytes --]

Re: Hello world! Student interested in getting involved.

[Kees Cook]

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.

> Also what directories that I should start exploring, this is extremely
> important for me. I was past google summer of code student. And the best
> assistance my mentors ever provided me is the folder or code files that
> Should play with.

This tends to be very interest-specific. For example, if you're
looking at memory layouts, arch/*/mm/ tends to be the place to look.
If you interested in ELF execution, that'd be kernel/fork.c and
fs/binfmt_elf.c. Usercopy hardening is include/linux/uaccess.h,
mm/usercopy.c, and arch/*/include/asm/uaccess.h, etc.

-Kees

-- 
Kees Cook
Pixel Security

Re: Hello world! Student interested in getting involved.

[Ard Biesheuvel]

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.

Re: Hello world! Student interested in getting involved.

[Ahmed Soliman]

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.

Re: Hello world! Student interested in getting involved.

[Kees Cook]

On Sat, Feb 17, 2018 at 7:22 AM, Ahmed Soliman
<ahmedsoliman0x666@gmail.com> wrote:
> 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 think it's good to experiment with kernel hardening via hypervisors.
There isn't any particular direction defined for this approach, with
lots of different things getting tried (e.g. Samsung KNOX). One
problem with the hypervisor-control of memory protections is things
like kprobes, modules, etc, that need to do dynamic rewriting of
kernel text.

> 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.

I would develop against Linus's latest release tag (e.g. currently
v4.15), unless you have some overwhelming reason to base on a
subsystem tree.

-Kees

-- 
Kees Cook
Pixel Security

Re: Hello world! Student interested in getting involved.

[Mark Rutland]

On Wed, Feb 21, 2018 at 01:44:27PM -0800, Kees Cook wrote:
> On Sat, Feb 17, 2018 at 7:22 AM, Ahmed Soliman
> <ahmedsoliman0x666@gmail.com> wrote:
> > 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 think it's good to experiment with kernel hardening via hypervisors.
> There isn't any particular direction defined for this approach, with
> lots of different things getting tried (e.g. Samsung KNOX). One
> problem with the hypervisor-control of memory protections is things
> like kprobes, modules, etc, that need to do dynamic rewriting of
> kernel text.

FWIW, a while back, we had an intern prototype some stage-2 W^X
protections for KVM guests on arm64. For kprobes, modules, and other
things requiring text modification, we locked those down late in the
boot process, which seemed like a reasonable tradeoff.

One big issue was static keys, since those need to be flipped
occasionally. We modified those to have two patchable branches rather
than one, so that we could fall back to a slow path that read a variable
when text modification was disabled.

We didn't end up posting those patches because there were a number of
open questions about the hypervisor ABI (e.g. how we could discover that
the hypervisor provided this feature). For arm64, we'll need to do some
FW standards work for that -- I'm not sure what the deal is for x86.

Thanks,
Mark.