@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 [off-list ref]
wrote:

On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller
[off-list ref] wrote:

quoted

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

quoted

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

quoted

even just getting code to compile and run is not really any guarantee at

all

quoted

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

quoted

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

quoted

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

quoted

know of any compiler implementation that I can use off the shelf in a

kernel

quoted

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

quoted

at compilation time that could just prevent the entrance of bad code. In

our

quoted

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

quoted

_______________________________________________
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