User: Password:
|
|
Subscribe / Log in / New account

2.6.32.9 Release notes

2.6.32.9 Release notes

Posted Feb 23, 2010 0:27 UTC (Tue) by nix (subscriber, #2304)
In reply to: 2.6.32.9 Release notes by jimparis
Parent article: 2.6.32.9 Release notes

It almost makes me wish for a microkernel... but, of course, all *that*
would do would be to convert a limited set of arbitrary code execution
holes into DoS attacks, introduce a pile of additional complexity that
would have holes of its own, and add a good bit of performance bashing.

What we really need is a better language. The surface for most of these
holes (null pointer dereference, integer and buffer overflow holes, at
least) could be reduced to that tiny subset of the kernel implemented in
assembler. Wire something like the pi calculus into the language and even
races would be automatically detectable. (Obviously we can't eliminate all
DoS attacks, ever, even with formally proven perfect hardware and an ideal
language. That class of holes will always be with us.)

But for better or worse Linux is written in C, dammit, so these holes will
keep on coming. Until we find a way to avoid all mistakes I don't see a
way to stop them, though sparse and friends can at least slow them down, a
bit. Blaming people for introducing holes when writing in a language like
this is like blaming people for tripping when walking backwards,
blindfolded, over rocky ground, in a blizzard, during an earthquake.


(Log in to post comments)

2.6.32.9 Release notes

Posted Feb 23, 2010 6:36 UTC (Tue) by error27 (subscriber, #8346) [Link]

Most of the security bugs listed here could have been found through static code checking. Our tools are not good enough yet, but in two years they will be.

2.6.32.9 Release notes

Posted Feb 23, 2010 21:55 UTC (Tue) by nix (subscriber, #2304) [Link]

We have the notable advantage that the kernel is written in a stereotyped
subset of C (as is true of any program that's not written by a frothing
madman). So the tools can use that, and (as sparse and GCC do) can rely on
user annotations, as well as erring on the side of paranoia.

So, yes, I was being excessively depressing.

Process calculus... will not eliminate bugs

Posted Feb 24, 2010 3:28 UTC (Wed) by dps (subscriber, #5725) [Link]

I know quite a bit about process calculus, although my choice of poison is CSP. The concurrency workbench is CCS, if I remember correctly. FDR, which may be available to developers in academia, handles CSP. Do you know of anything similar for pi-calculus?

You could, of course, follow my PhD thesis and prove a general result about a class of systems and limit yourself to that class of system. You can even write frameworks which make it almost impossible to do anything else. (I could say more but wont.)

Unfortunately whatever you do there is the problem of arguing that the kernel code corresponds to the process calculus or has the things your general proof required.

99.98% of the time concurrency just adds locking and context switches and therefore reduces system performance. The best approach the other 0.02% of the time is a more difficult question.

Process calculus... will not eliminate bugs

Posted Feb 24, 2010 8:30 UTC (Wed) by nix (subscriber, #2304) [Link]

Unfortunately whatever you do there is the problem of arguing that the kernel code corresponds to the process calculus or has the things your general proof required.
Exactly. Without an automated prover the thing is mostly useless for actually reducing bug count: and when was the last time you encountered an automated prover for any but the most toy of languages that actually was automated? They tend to need so much assistance that they become far more a burden than a help, unless you're doing something hyper-life-critical.

I was musing on the theoretical bound when I should have been thinking about reality...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds