On Wed, Nov 06, 2002 at 10:36:40AM +0800, John Summerfield was heard to remark: > 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?
I don't mean 'corrupt /usr/lib/libwhatever.so'. That is still hard to do. What I mean is that if an app is linked to a library, and that library opens a file in read-write mode, then the app also has full read-write to that file. There is nothing the library can do to keep the app at bay. In general, the app can corrupt the RAM that the library is using, including the libraries stack. This started out as a discussion about stack smashing, after all. > BTW IA32 has four protection levels enforced in hardware. I believe the > problem is that Linux doesn't use them all. I don't know the intel arch at all. I know powerpc, mostly. true blue ... > Any apache modules Again, I think you misunderstood. What I mean to say is that "a misbehaving apache module can write any bytes whatsoever that it wants to the socket that is connected to the surfer's web browser". Among other things. The structure I describe could be used (i beleive) to prevent this kind of "unauthorized access". Today, you cannot make a distinction between trusting apache itself, and trusting any apache module, since they both run in the same address space, and therefore have full read and write access to that address space. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
