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?
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-) rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*. On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
Since I knew that Linux kernel didn't accept the pax/grsecurity , but wrote its own implement, and some linux developers do not have sense of security, I think linux security will be a problem in the future. - mudongliang 2015-08-18 21:45 GMT+08:00 Kenneth Adam Miller <kennethadammiller@gmail.com> :
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*.
On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 18 Aug 2015 21:58:15 +0800, 慕冬亮 said:
Since I knew that Linux kernel didn't accept the pax/grsecurity , but wrote its own implement, and some linux developers do not have sense of security, I think linux security will be a problem in the future.
The fact that a specific security patch that is very invasive and comes with some large tradeoffs was never submitted in a form suitable for merging is *not* the same thing as kernel developers not having a sense of security. Note that large sections of what used to be in the grsecurity patch *have* been reworked, submitted, and accepted into the kernel.
For memory leaks kernel has a clever mechanism to verify it that you can enable in .config for use [1]. You can also uses Sparse in kernel for static analyze purpose. There are others out there such as coverity scan, coccinelle, etc. [1] https://www.kernel.org/doc/Documentation/kmemleak.txt []'s On Tue, Aug 18, 2015 at 10:45 AM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*.
On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ---------------------------------------------- Leônidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com
@leo If kmemleak is not a language based approach, I ardently question the completeness of such a verification. For example, users of valgrind might make such promises of verification of user land code, but valgrind is limited by it's approach in that execution paths that do not occur cannot be checked. Thanks for that, however-I didn't have it before. Drk is also good if you haven't heard of it :-) On Tue, Aug 18, 2015 at 10:01 AM, leo kirotawa <kirotawa@gmail.com> wrote:
For memory leaks kernel has a clever mechanism to verify it that you can enable in .config for use [1]. You can also uses Sparse in kernel for static analyze purpose.
There are others out there such as coverity scan, coccinelle, etc.
[1] https://www.kernel.org/doc/Documentation/kmemleak.txt
[]'s
On Tue, Aug 18, 2015 at 10:45 AM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*.
On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day <rpjday@crashcourse.ca
wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter:
LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
---------------------------------------------- Leônidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com
+1 to coverity we use that :) On Tue, Aug 18, 2015 at 9:01 AM, leo kirotawa <kirotawa@gmail.com> wrote:
For memory leaks kernel has a clever mechanism to verify it that you can enable in .config for use [1]. You can also uses Sparse in kernel for static analyze purpose.
There are others out there such as coverity scan, coccinelle, etc.
[1] https://www.kernel.org/doc/Documentation/kmemleak.txt
[]'s
On Tue, Aug 18, 2015 at 10:45 AM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*.
On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
---------------------------------------------- Leônidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Has anybody seen the new verified C compiler that came out of inria? I think it's supposed to show that if it does not give a warning, that there can be no segfault. But I'm not sure about leakage and other concerns. On Tue, Aug 18, 2015 at 11:01 AM, Victor Rodriguez <vm.rod25@gmail.com> wrote:
+1 to coverity we use that :)
On Tue, Aug 18, 2015 at 9:01 AM, leo kirotawa <kirotawa@gmail.com> wrote:
For memory leaks kernel has a clever mechanism to verify it that you can enable in .config for use [1]. You can also uses Sparse in kernel for static analyze purpose.
There are others out there such as coverity scan, coccinelle, etc.
[1] https://www.kernel.org/doc/Documentation/kmemleak.txt
[]'s
On Tue, Aug 18, 2015 at 10:45 AM, Kenneth Adam Miller <kennethadammiller@gmail.com> wrote:
Why? That's what the vast majority of the kernel is written in (besides assembler, but what I'm looking for isn't a way to write safe assembler). Plus, tons of people in the kernel development community *must* have some concern or interest in security. I don't care if the kernel is written in C, but I sure would like my kernel module to be safer. If I can get it I don't care what language it's in-it just has to work and *be secure*.
On Tue, Aug 18, 2015 at 9:40 AM, Robert P. J. Day < rpjday@crashcourse.ca> wrote:
On Tue, 18 Aug 2015, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development...
and that's probably where you should have stopped typing. :-)
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
---------------------------------------------- Leônidas S. Barbosa (Kirotawa) blog: corecode.wordpress.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller <kennethadammiller@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
@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@gmail.com> wrote:
On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller <kennethadammiller@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 08/18/2015 09:25 AM, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development.
That about sums it up. did you have some question about kernel development. This is a mailing list on mentoring and skills developments in writing the Linux Kernel. We know it is written mostly in C. YOU KNOW it is written in C. So after this, nothing else you wrote is relevant to THIS mailing list.
My interest is clearly on approaches that can be taken to do hardened kernel module development. 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. 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. 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. | "this is not a rational approach" 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. On Tue, Aug 18, 2015 at 6:27 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
On 08/18/2015 09:25 AM, Kenneth Adam Miller wrote:
Ok- so I know that C is the defacto standard for kernel development.
That about sums it up. did you have some question about kernel development. This is a mailing list on mentoring and skills developments in writing the Linux Kernel. We know it is written mostly in C. YOU KNOW it is written in C. So after this, nothing else you wrote is relevant to THIS mailing list.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 08/18/2015 08:30 PM, Kenneth Adam Miller wrote:
My interest is clearly on approaches that can be taken to do hardened kernel module development.
OK - so that is not this list. This is a list for newbies mentoring and linux kernel development. The only people here that would have any influence on that are here for mentoring purposes only, and not to be pitched your ideas for an overhaul of kernel development.
Ok, agreed. I hadn't known that much - I apologize for getting this to the wrong list. I've not at all proposed any kernel overhaul effort, only how to affect my own code. :) Thank you to all mentors who gave advice. :) On Wed, Aug 19, 2015 at 3:23 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:
On 08/18/2015 08:30 PM, Kenneth Adam Miller wrote:
| "this is not a rational approach"
I'm very strongly confident the approach of achieving stronger guarantees
Off topic
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (8)
-
Greg KH -
Kenneth Adam Miller -
leo kirotawa -
Robert P. J. Day -
Ruben Safir -
Valdis.Kletnieks＠vt.edu -
Victor Rodriguez -
慕冬亮