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
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 ru...@mrbrklyn.com wrote:
On
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
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
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
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
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
+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
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:
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
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,
@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
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
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
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
@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.
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
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
18 matches
Mail list logo
