OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Buffer Overflows
From: Jim Dennis (jimdstarshine.org)
Date: Thu Apr 27 2000 - 02:42:59 CDT

 
> Douglas Ostling wrote:
 
>> On Wed, 26 Apr 2000, Alan Cox wrote:
>>>> How about it - why not implement a kernel solution to enforce memory
>>>> boundaries so people don't have to worry about buffer overflows in their
>>> Well actually I was considering opening a market in flying pigs. Mostly
>>> because it would be more practical
>> How did they do it on MVS, then? With hardware, right? Well, we have
>> hardware controls, also, in the form of protected memory. Look at MVS
>> register allocation.
 
> With a radically different memory architecture and privilege model. Memory
> segments were visible to user processes under MVS. Memory segments are not
> visible to Linux processes, for two very important reasons:
 
> * not all Linux-supported CPUs have segments
> * the UNIX programming model does not allow segments to be visible to user
> processes, beyond the very coarse grained "code segement, data segment,
> stack segment". Solar Designer's OpenWall non-executable stack kernel
> patch is essentially exploiting these segments as much as possible.
 
> So if you succeeded in getting a segmented memory system working on Linux, it
> would:
 
> * not be able to run any existing Linux programs
> * not be able to run on non-x86 hardware
> * be a HELL of a lot of work to build

     1) Offer kernel support and an API
     2) Implement a toolchain (compilers, linkers and libraries)
       that used this API.

 If done write it would be possible to port most existing
 apps with little or no effort. If really done right it should
 allow simple recompiles of unmodified sources. I agree that
 binary compatability seems quite unlikely. I don't know if
 there are conflicts in these design requirements and some
 obscure portions of the POSIX and related specs that would
 make the whole mess infeasible.
 
> Makes StackGuard look attractive, eh? :-)
 
 Crispin, I don't mean offense by this but I don't consider
 StackGuard a "solution." It is a workaround to a fundamental
 design flaw in the common UNIX kernel and toolchain implementations.
 I regret that the workaround is necessary and note that it costs
 a significant amount of performance.

 I'm not sure but it might be better to re-implement most of the
 software that you've tested under StackGuard in Pike. It might
 offer roughly the same performance and benefits (and the
 process of porting it might actually dust some cruft off the
 involved code.
 
 (Have you looked at Pike? Have you done any performance comparisons
 of a Pike program vs the closest equivent C program with and w/o
 Stackguard?).

 I'm not saying that people should avoid your package or approach
 for performance reasons. I am saying that this is more of a workaround
 than a solution. (A solution would be to fix the toolchain to
 make more robust code --- not glue in a canary and checks to see
 if the poor birdie has expired).

 As I say --- I really don't mean to give offense. That's just
 how I see it. 

--
Jim Dennis                                             jdennislinuxcare.com
Linuxcare: Linux Corporate Support Team:            http://www.linuxcare.com

--
Jim Dennis                                             jdennislinuxcare.com
Linuxcare: Linux Corporate Support Team:            http://www.linuxcare.com