public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux Kernel Audit Project?
Date: Mon, 17 Jan 2005 13:12:52 -0500	[thread overview]
Message-ID: <41EC0024.9010708@comcast.net> (raw)
In-Reply-To: <1105962233.12709.68.camel@localhost.localdomain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Alan Cox wrote:
> On Llu, 2005-01-17 at 07:40, John Richard Moser wrote:
> 
>>On the same line, I've been graphing Ubuntu Linux Security Notices for a
>>while.  I've noticed that in the last 5, the number of kernel-related
>>vulnerabilities has doubled (3 more).  This disturbs me.
> 
> 
> I've been monitoring the kernel security stuff for a long time too.
> There are several obvious trends and I think most are positive
> 
> - Tools like coverity and sparse are significantly increasing the number
> of flaws found. In particular they are turning up long time flaws in
> code, but they also mean new flaws of that type are being found. People
> aren't really turning these tools onto user space - yet -
> 

These are great, but I don't think such tools could cover all issues,
especially in the kernel (where hardware is a factor).  Perhaps by
hammering a function with every input possible, but eh.

Humans create the tools, humans create the flaws.  Thus, humans create
flaws in the tools.  Humans of course aren't staticly flawed (as the
tools will be), so they or other humans can notice bugs they missed before.

> - We get bursts of holes of a given type. If you plot things like
> "buffer overflow" "structure passed to user space not cleaned" "maths
> overflow check error" against time you'll see they show definite
> patterns with spikes decaying at different rates towards zero.
> 

\o/

> There are also people other than Linus who read every single changeset.
> I do for one.
> 

"Read" and "Audit" are two different things.  I can read a changeset and
see that a[10] got a 20 character string into it; I will NOT see that a
particular execution path 17 function calls long under one obscure but
possible and deliberately activatable condition causes memory corruption.

I thought the purpose of an audit was to sit down and give the code
several long, hard looks from different perspectives; though I've never
done one (I hope to in the future), so I wouldn't know would I?

Maybe I should stop talking before I make myself look stupider...

> Alan

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7AAjhDd4aOud5P8RAlQqAJ9eVwAClqkqMLETCyIFC6UeyKX0ogCfUUwN
2EWlPWnym7IHz4a/bVBQHmU=
=VpA2
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-01-17 18:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-17  7:17 Linux Kernel Audit Project? John Richard Moser
2005-01-17  7:31 ` Alban Browaeys
2005-01-17  7:32 ` Dave Jones
2005-01-17  7:47   ` John Richard Moser
2005-01-17 12:38     ` Adrian Bunk
2005-01-17 18:06       ` John Richard Moser
2005-01-17  7:40 ` John Richard Moser
2005-01-17 12:23   ` Alan Cox
2005-01-17 18:12     ` John Richard Moser [this message]
2005-01-17 18:16     ` Theodore Ts'o
2005-01-17 20:09     ` John Richard Moser
2005-01-17 13:11   ` Diego Calleja
2005-01-17 18:07     ` John Richard Moser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41EC0024.9010708@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox