Re: Could I search mails in lkml.org by date?
The lkml.org provide method to check mails in some day. For example , 2013 May 5th, you can get the mails according to the tips in the webpage, the final url is https://lkml.org/lkml/2013/5/5. There are no much mails in one day. So you can check the mails by search box in webpage or Ctrl+F directly. Besides, google can help you do this job itself , but you should provide suitable keywords. - mudongliang 2015-08-18 13:47 GMT+08:00 Nan Xiao xiaonan830...@gmail.com: Just find this website: http://lists.linuxfoundation.org/mailman/listinfo which has all the mails archived by date, hope it can help someone! Best Regards Nan Xiao On Mon, Aug 17, 2015 at 10:58 AM, Nan Xiao xiaonan830...@gmail.com wrote: Hi Kenneth, Thanks very much for your answer! Best Regards Nan Xiao On Fri, Aug 14, 2015 at 7:12 PM, Kenneth Adam Miller kennethadammil...@gmail.com wrote: You can use Google's powerful search capabilities and its pretty straight forward. Site:lkml.org will restrict you that site, you can pinpoint a lot of different restrictions-there are entire books on Google search capabilities. If you didn't know it though, the advanced search button probably will suit your needs, but you can Google about how to use the other restrictions to see if there's some goodie not in that default form. On Aug 14, 2015 6:06 AM, Nan Xiao xiaonan830...@gmail.com wrote: Hi all, I need to search previous kernel discussion mails to understand a module better. Now, I use https://lkml.org/lkml/last100/ to search key words, but it may dispaly several pages. I want to know if there are some good tips to search mails in lkml.org? For example, sort them according to date, etc. Thanks in advance! Best Regards Nan Xiao ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Newbie help
On 04 Aug, Schrey, Moritz wrote: get a copy of Linux Device Drivers (abbreviated LDD3 here), which is available online. The example code from that book is definitey outdated and will not compile as is since it is based on 2.6.10(?), but finding the errors is a good exercise too. Since the book is widely known, you will also find several repos, which brought the code up to some more recent kernel version. I guess we are all more or less eagerly waiting for LDD4, which should be released in end of November. November is correct, but which year? =) It seems, that unfortunatelly O'Reilly've changed LDD4's release date again. Now it's November 2016 according to their site ( http://shop.oreilly.com/product/0636920030867.do ). Amazon updated information as well - 25. November 2016. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD signature.asc Description: Digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
On 08/18/2015 10:03 AM, Kenneth Adam Miller wrote: @leo If kmemleak is not a language based approach, I ardently question the completeness of such a verification. this is not a rational approach ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [Off-topic] SCM using git
On Tue, Aug 18, 2015 at 3:16 PM, amit mehta gmate.a...@gmail.com wrote: Hello All, This query is not about Linux kernel, but is rather generic query on development framework with git. Since, Linux Kernel project is significantly large, with astonishing number of people involved and large number of branches, I'm assuming that people have faced similar situation and your advice and guidance would be of great help to me. I'm currently pursuing Masters program and also working in a small tech Startup in the IOT domain. I'm involved in Firmware Development on ARM based SOCs and our team comprise three Engineers. We use git for SCM. Since we are in a very early phase and have very little turnaround time, from the requirement to final integration, we do not have a proper review process and hence everyone is allowed to commit in the master branch, or create, delete a branch, or a tag at will. We also do not have much insight into, how long a feature based branch would last. In last couple of months, I've seen some stale branches on which the development stopped quite early and some very active branch as well. Without much insight and probably due to not so well defined process, It is already becoming difficult to properly maintain the code consistency, filtering etc across several branches. For example, I create a feature remote branch (say origin/featureX) on which I continue my development and soon I realize that part (There is no way to pick partial commit) or a full commit that I recently made for the featureX should also go into another branches such as master and say featureY branch as well. But since, my colleague has been working on master, I get conflicts when I try to cherry-pick (At this moment, I do not want to rebase or merge two branches, I only need few of the commits from featureX branch to go into master and featureY). I resolve the conflicts and life goes on, but problem happens again later in future, if the two branches divert too much and a further need for cherry-picking or rebasing or merging is required. The point is that I also believe that it is a very good idea to maintain separate branches, based on feature or some other requirements, but it is also a n00bs nightmare when the conflicts are very high. There are also incidents when somebody forgot to add a particular commit to another branch and realized only later, when he was faced with debugging a issue and had to go through the git history, to figure out the issue. It would be nice, If for example a particular commit can be automatically propagated to other branches in this case. Please pitch in your suggestions, rule of thumb, tools and your way of countering such issue with less pain. Few suggestions: 1. Better to have a proper review process in place, gerrit is one of the best tools I have used so far for reviewing, 2. Keep a master branch always compilable (run able) and merge rights should be only to integrator. once a feature is developed (on a feature branch) and ready to get into master, create a new commit for master branch for merging (of course after validating against the new head) Thanks, Amit ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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
[Off-topic] SCM using git
Hello All, This query is not about Linux kernel, but is rather generic query on development framework with git. Since, Linux Kernel project is significantly large, with astonishing number of people involved and large number of branches, I'm assuming that people have faced similar situation and your advice and guidance would be of great help to me. I'm currently pursuing Masters program and also working in a small tech Startup in the IOT domain. I'm involved in Firmware Development on ARM based SOCs and our team comprise three Engineers. We use git for SCM. Since we are in a very early phase and have very little turnaround time, from the requirement to final integration, we do not have a proper review process and hence everyone is allowed to commit in the master branch, or create, delete a branch, or a tag at will. We also do not have much insight into, how long a feature based branch would last. In last couple of months, I've seen some stale branches on which the development stopped quite early and some very active branch as well. Without much insight and probably due to not so well defined process, It is already becoming difficult to properly maintain the code consistency, filtering etc across several branches. For example, I create a feature remote branch (say origin/featureX) on which I continue my development and soon I realize that part (There is no way to pick partial commit) or a full commit that I recently made for the featureX should also go into another branches such as master and say featureY branch as well. But since, my colleague has been working on master, I get conflicts when I try to cherry-pick (At this moment, I do not want to rebase or merge two branches, I only need few of the commits from featureX branch to go into master and featureY). I resolve the conflicts and life goes on, but problem happens again later in future, if the two branches divert too much and a further need for cherry-picking or rebasing or merging is required. The point is that I also believe that it is a very good idea to maintain separate branches, based on feature or some other requirements, but it is also a n00bs nightmare when the conflicts are very high. There are also incidents when somebody forgot to add a particular commit to another branch and realized only later, when he was faced with debugging a issue and had to go through the git history, to figure out the issue. It would be nice, If for example a particular commit can be automatically propagated to other branches in this case. Please pitch in your suggestions, rule of thumb, tools and your way of countering such issue with less pain. Thanks, Amit ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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 ru...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [Off-topic] SCM using git
On August 18, 2015 5:46:38 AM EDT, amit mehta gmate.a...@gmail.com wrote:
Hello All,
This query is not about Linux kernel, but is rather generic query on
development framework with git. Since, Linux Kernel project is
significantly large, with astonishing number of people involved and
large number of branches, I'm assuming that people have faced
similar situation and your advice and guidance would be of great help
to me.
I'm currently pursuing Masters program and also working in a small
tech Startup in the IOT domain. I'm involved in Firmware Development
on ARM based SOCs and our team comprise three Engineers.
We use git for SCM. Since we are in a very early phase and have
very little turnaround time, from the requirement to final integration,
we do not have a proper review process and hence everyone is allowed
to commit in the master branch, or create, delete a branch, or a tag
at will. We also do not have much insight into, how long a feature
based branch would last. In last couple of months, I've seen some
stale branches on which the development stopped quite early and
some very active branch as well. Without much insight and probably
due to not so well defined process, It is already becoming difficult
to properly maintain the code consistency, filtering etc across
several branches. For example, I create a feature remote branch
(say origin/featureX) on which I continue my development and soon
I realize that part (There is no way to pick partial commit) or a
full commit that I recently made for the featureX should also go into
another branches such as master and say featureY branch as well.
But since, my colleague has been working on master, I get conflicts
when I try to cherry-pick (At this moment, I do not want to rebase
or merge two branches, I only need few of the commits from featureX
branch to go into master and featureY). I resolve the conflicts and
life goes on, but problem happens again later in future, if the two
branches divert too much and a further need for cherry-picking or
rebasing or merging is required.
The point is that I also believe that it is a very good idea to
maintain
separate branches, based on feature or some other requirements, but
it is also a n00bs nightmare when the conflicts are very high. There
are also incidents when somebody forgot to add a particular commit
to another branch and realized only later, when he was faced with
debugging a issue and had to go through the git history, to figure
out the issue. It would be nice, If for example a particular commit
can be automatically propagated to other branches in this case.
Please pitch in your suggestions, rule of thumb, tools and your way
of countering such issue with less pain.
Thanks,
Amit
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Personally, in young code I find long lived branches hard to work with.
For new features I prefer to work first on the integration related
code with a stub that gracefully does nothing or fails.
So at the start of adding a new feature that will be implemented via a
subroutine,write the invoking code a stub that gracefully does
nothing. Often the invoking code and the stub can be written in 10
minutes or less.
Then push/pull that into master immediately.
Then I would use an ifdef to work on a real subroutine to implement
the feature. ie.
#ifndef FEATURE_X_TESTING
/* Declare a a stub to use until the code is stable enough for master */
int new_function() {
return(TRUE);
}
#else
/* This is unstable code I am still writing */
int new_function() {
/* New code */
}
#endif
Then in my local makefile (or via a environment variable, I set
FEATURE_X_TESTING true.
Now my new unstable code will have no negative impact on master, so I
push it to master often. Probably at least once a day.
When I'm ready to first enable it in master, I just define
FEATURE_X_TESTING in master.
Greg
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
+1 to coverity we use that :) On Tue, Aug 18, 2015 at 9:01 AM, leo kirotawa kirot...@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 kennethadammil...@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 rpj...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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.ro...@gmail.com wrote: +1 to coverity we use that :) On Tue, Aug 18, 2015 at 9:01 AM, leo kirotawa kirot...@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 kennethadammil...@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 rpj...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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
Re: Safety in Kernel Development
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 rpj...@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
Re: Safety in Kernel Development
@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 kirot...@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 kennethadammil...@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 rpj...@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
Safety in Kernel Development
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? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller kennethadammil...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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 kennethadammil...@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 rpj...@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
Re: Safety in Kernel Development
@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.ro...@gmail.com wrote: On Tue, Aug 18, 2015 at 8:25 AM, Kenneth Adam Miller kennethadammil...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
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 kennethadammil...@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 rpj...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Safety in Kernel Development
On Tue, Aug 18, 2015 at 09:58:15PM +0800, 慕冬亮 wrote: Since I knew that Linux kernel didn't accept the pax/grsecurity It was never submitted for acceptance, so how could we merge it? greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
