Safety in Kernel Development

[Kenneth Adam Miller]

@nick Ah! Cool, well thank you. Module signing protects against a different
set of attack vectors than what I'm interested in. Like in the case of
heartbleed, it didn't matter that traffic was encrypted because once an
attack gains execution control they can wait until the payload is
decrypted. Likewise, it doesn't matter that you can have the kernel only
load signed modules-if an attacker gains execution control flow they can
execute with ROP/JIT-ROP or whatever payload they send. So I still need
language based security.

@Victor Thank you so much. Gosh, it seems like there's some kind of
psychological resistance to adopting language based approaches to security.
They really aren't so bad. Thank you for the tip about the selftest
framework.

Some of the other real questions I have about using Rust (I don't care what
language really) specifically concern binary format constraints and typing
mechanism expressiveness. I am concerned that compilers other than gcc (C
specifically) will not produce code specific to the kernel as needed, and
that later upgrades of the compiler backends (Rust with LLVM) might lead to
code produced for userland being executed in a kernel context. This might
not sound bad at first, but I fear it would lead to things like userland
protection mechanisms stumbling over implicit assumptions not held in
kernel land or otherwise kernel code requirements. Also, I don't know that
I can codify the restrictions of kernel programming in the typing mechanism
to ensure that issues not present in userland are appropriately addressed.
Interrupt handling and re-entrancy are things I really don't think that
userland code addresses much.

Does anybody have any thoughts? It really can be any language, utility, or
mechanism to make kernel code harder to break.

On Tue, Aug 18, 2015 at 9:52 AM, Victor Rodriguez <vm.rod25 at gmail.com>
wrote:

> On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller
> <kennethadammiller at gmail.com> wrote:
> > Ok- so I know that C is the defacto standard for kernel development. What
> > I'm not saying is that we should all move away from it or that it should
> be
> > adopted internally. What I am saying is related to security concerns in
> > developing a kernel driver. What may come of it may generally allow for
> > better quality, but that's a separate topic.
> >
> >
> > So kernel programming is very hard. It has both a high bar to entrance
> and
> > even just getting code to compile and run is not really any guarantee at
> all
> > that you've done a good job of authoring a kernel driver. I don't really
> > believe that things like Klee really find all errors, but I think that a
> > defense in depth approach would be good. So, when I can get my kernel
> object
> > to compile, I know that I can test that it runs, but I would also like to
> > have the confidence to know that it won't leak kernel memory or other
> > resources and for that matter will not deference an invalid pointer.
> >
> > Things like Rust allow for better type safety help. In userland programs,
> > SFI is good as a passive backup to type safety but I don't think that
> SFI is
> > applicable to kernel land because the execution boundaries are not set up
> > under a specific virtual memory scheme. CFI would also be good, but I
> don't
> > know of any compiler implementation that I can use off the shelf in a
> kernel
> > programming environment.
> >
> > I guess the best option IMHO is some way to codify the restrictions and
> > semantics of operation somehow into an expressive language that can be
> > checked at compile time. So, in the case of re-entrancy, I'd like an
> error
> > at compilation time that could just prevent the entrance of bad code. In
> our
> > case, we'd rather have some good code than a lot of bad code.
> >
> > Does anybody have any recommendations? Or shared interest?
>
>
> Security in Kernel matters . I am Clera Linux OS developer and we care
> a lot about security . How much as much that we check 100 times the
> security of the OS per day.
>
> There are many ways to check the security , the standard CVE list is
> the first place to check . We do have a tool that check that:
>
> https://github.com/ikeydoherty/cve-check-tool/
>
> However what you are asking for is a way to prevent the coder to
> create security holes in the driver he is creating, thats the question
> right ? . I think is a fair question and despite the fact that there
> are some efrors to check quality in the kernel like LTSI test suite
> and internal test suite in kernel
>
> Linux Kernel Selftest Framework
>
>
> Hope it helps
>
> Regards
>
> Victor Rodriguez
> clearlinux.org
>
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/fe0cbc96/attachment-0001.html