On Sat, 29 Jul 2000, Gary Funck wrote:
> Oxy, excellent summary of the issues relating to the prevention
> of exploits, thanks.
>
> > The problem isn't Intel's fault or any OS's, it's a problem in the C
> > language and compiler. There are 5 fixes:
> >
> > a) write safe code (which has so far proved hard)
> > b) compile with bounds-checking (big performance hit)
>
> What is the level of performance hit, using bounds-checking?
Depends very much on the application. Can be 100% or more. It's actually
probably more of a hit than rewriting something in eg Perl or Python, as
those languages are designed around bounded arrays where in C it's an
afterthought. Oh, and in C, there's the whole issue of pointer aliasing
which means it's only a partial fix.
(C is a stupid language to write large applications in. The vast majority
of bugs in C programs simply don't exist in newer languages. For most of
the things people use computers for today, it's much more important that
something works well than that it work fast.)
> > c) compile with StackGuard, etc. (doesn't stop exploits that corrupt
> > other locals)
> > d) separate the return address stack from the automatic variable stack
> > (ditto)
> > e) use another language (performance)
>
> Might there also be an 'alternate universe' where the damage caused
> by exploit-induced loss of control could be reduced/limited?
Capabilities are a start. But this is an orthogonal problem. If someone
hacks just my account rather than root, to me it's just as bad, no?
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:31 EST