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