[plug] Help needed - hackers/crackers and monolithic kernels

[Rod]

well microsoft started down that road with NT (true microkernel), and
real world speed issues caused them to start hacking things straight 
into the kernel (monolithic)...

it all well and good to specify all these different layers, with
different validations... but when your talking to the gfx card one pixel
at a time, and require 35 fps minimum to get a usable app ........

On Fri, 2005-08-05 at 12:28 +0800, Cameron Patrick wrote:
> Shayne O'Neill wrote:
> 
> > Truth be told, most of the kernel 'sploits are more to do with buffer
> > smashes, locking shenanigans and other out-of-bound value type stuff.
> > Something no design except good design can prevent.
> 
> Sure, but if you had the kernel code following the "principle of least
> privilege" in the same way that most userland code {does, should do,
> can be made to do} then a buffer smash in, say, the USB driver could
> only affect USB devices, not give complete access to the whole
> system.  Whether any popular micro-kernel design actually _does_ this
> I have no idea.
> 
> Given that most recent Linux sploits that I know about have taken
> advantage of things like system calls which didn't check their
> arguments or bugs in interpreting the header fields of executables --
> stuff which by its nature needs access to poke stuff into random bits
> of system memory -- I'm not really sure how effective that kind of
> kernel-level privilege separation would actually be.
> 
> Cameron.
> 
> 
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au