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