Safety in Kernel Development

Safety in Kernel Development

[Kenneth Adam Miller]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/166b9b6f/attachment.html 

Safety in Kernel Development

[Robert P. J. Day]

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
========================================================================

Safety in Kernel Development

[Kenneth Adam Miller]

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
> ========================================================================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/a5a82341/attachment-0001.html 

Safety in Kernel Development

[Victor Rodriguez]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

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 <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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/c7de9dc7/attachment.html 

Safety in Kernel Development

[Kenneth Adam Miller]

@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 at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/fe0cbc96/attachment-0001.html 

Safety in Kernel Development

[leo kirotawa]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 

----------------------------------------------
Le?nidas S. Barbosa (Kirotawa)
blog: corecode.wordpress.com

Safety in Kernel Development

[Kenneth Adam Miller]

@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:
> http://twitter.com/rpjday
> >> LinkedIn:
> http://ca.linkedin.com/in/rpjday
> >> ========================================================================
> >>
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
> --
>
> ----------------------------------------------
> Le?nidas S. Barbosa (Kirotawa)
> blog: corecode.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/3801d13d/attachment.html 

Safety in Kernel Development

[Victor Rodriguez]

+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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
>
> --
>
> ----------------------------------------------
> Le?nidas S. Barbosa (Kirotawa)
> blog: corecode.wordpress.com
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Safety in Kernel Development

[Kenneth Adam Miller]

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 at 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 at kernelnewbies.org
> >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >>
> >
> >
> >
> > --
> >
> > ----------------------------------------------
> > Le?nidas S. Barbosa (Kirotawa)
> > blog: corecode.wordpress.com
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/1ab52256/attachment-0001.html 

Safety in Kernel Development

[Greg KH]

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

Safety in Kernel Development

[Valdis.Kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/08abba6f/attachment.bin 

Safety in Kernel Development

[Ruben Safir]

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

Safety in Kernel Development

[Ruben Safir]

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.

Safety in Kernel Development

[Kenneth Adam Miller]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150818/5daeb229/attachment.html 

Safety in Kernel Development

[Ruben Safir]

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.

Safety in Kernel Development

[Ruben Safir]

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

Safety in Kernel Development

[Kenneth Adam Miller]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150819/04b03484/attachment.html