On Wed, 6 Nov 2002 05:45, you wrote: > > The core idea is actually so simple, its painful. Today, most CPU's > define two memory spaces: the one that the kernel lives in, and the > one that the user-space lives in. When properly designed, there is > nothing a user-space program can do to corrupt kernel memory. One > 'switches' between these memory spaces by making system calls, i.e. > by the SVC instruction. > > The 390 arch has not two, but 16 memory spaces (a 4-bit key) with > this type of protection. (When I did the i370 port, I put the > kernel in space 0 or 1 or someething like that, and user space > programs ran in one of the others.) The partitioning between them > is absolute, and is just like the kernel-space/user-space division > in other archs. The mechanism is independent/orthogonal to the > VM/TLB subsystem (you can have/use virtual memory in any of the > spaces.) > > This then points to a simple, basic idea: suppose one could make > a call to a plain-old shared library, but have that library be > protected behind the same kind of syscall protections that the > kernel has. Then there would be nothing that the caller could do > to corrupt the memory used by the shared library, no more than > (a user-space) caller can corrupt kernel memory.
Am I naive? How does a caller corrupt a shared library on Linux on IA32? Okay, you can do it as root. If you're root you have full privilege _by definition_. So, I imagine you could corrupt L/390 in the same way, even with your protection model. BTW IA32 has four protection levels enforced in hardware. I believe the problem is that Linux doesn't use them all. > > OK, so what neat things can one do with this? > a) Imagine running Apache, and loading some untrusted apache module > which in fact is a trojan horse. Oops. Today, there is nothing > that apache can do to prevent mod_trojan_horse from corrupting > the innards of apache (and by extension, other things, like web > pages). But imagine if apache could run behind a syscall-like > barrier. Then damage done by mod_trojan becomes a lot more > limited, and maybe even completely containable. Any apache modules has to have access to users' data. Doesn't necessarily have to be writeable though, and doesn't have to be owned by the account used to access it. You _can_ secure your webserver now to ensure Apache components can't corrupt static data such as executable scripts, html etc. If your application has to write data, you can still secure it to a large extent by your choices in how to store data (maybe though some DBMS or by running your particular application as a different user (user/group specs in VirtualHost). Note that the Apache 1.3 implementation is a little odd, and it's broken in 2.0, but the design is there. > b) Same scenario as above, but word-substitute apache->kernel and > mod_trojan->device driver. If the linux kernel ran in 'space 2', > but device drivers ran in 'space 3', then nasties can't hurt > the kernel, while still enjoying read-write access to the > bus and other hardware that a legit device driver needs access > to. Could be done now in IA32. As I recall, OS/2 does just that. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the "Linux Support by Small Businesses" list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
