<div dir="ltr"><div>My interest is clearly on approaches that can be taken to do hardened kernel module development. </div><div><br></div>Excuse me, I didn't say I was interested in editing the linux kernel, and for that matter as I understand the kernel newbies mailing list is general across the entirety of kernel programming, whether editing it directly or writing driver modules. If you read what I wrote closely, I'm not at all interested in changing anybody else's code or in changing the development habits of other people or organizations. What I am interested in is ensuring that the code *I* write is as safe as possible.<div><br></div><div>I don't think it's at all applicable to restrict the conversation to a specific language. I see kernel programming as being very strongly pragmatist in nature. I don't care what you call it, it has to work, and for our requirements it has to be safe as well. I'm not alone in wanting stronger security. Since I don't see any one person given authority to dictate what can or can't be discussed here, I'm just going to go about my business hardening my code and finding others from whom I can learn and share with. <br><br>To me a language is a tool, not an idol. But if you read further into the chain, you can also see I brought in the possibility of a passive Control Flow Integrity approach woven by compiler or alternatively a safer compiler that wouldn't even need to be trusted to emit code that does not segfault or leak memory. </div><div><br></div><div>| "this is not a rational approach"</div><div><br></div><div>I'm very strongly confident the approach of achieving stronger guarantees at the language level are both very rational and pragmatic, and I have the sources and information to back it up. Let me address what I think is the root of the response here however: kmemleak is a good idea and useful tool, and I plan to use it if I can get the time. So I appreciate any helpful mention that has been given here to tools I can use, I just happen to make a note about viability that crossed my mind for that particular tool. We just want the strongest guarantees we can get, so I didn't intend to be snarky.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 18, 2015 at 6:27 PM, Ruben Safir <span dir="ltr"><<a href="mailto:ruben@mrbrklyn.com" target="_blank">ruben@mrbrklyn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/18/2015 09:25 AM, Kenneth Adam Miller wrote:<br>
> Ok- so I know that C is the defacto standard for kernel development.<br>
<br>
<br>
</span>That about sums it up. did you have some question about kernel<br>
development. This is a mailing list on mentoring and skills<br>
developments in writing the Linux Kernel. We know it is written mostly<br>
in C. YOU KNOW it is written in C. So after this, nothing else you<br>
wrote is relevant to THIS mailing list.<br>
<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>
</div></div></blockquote></div><br></div>