On Tue, Nov 05, 2002 at 08:03:35PM +0000, Alan Cox was heard to remark: > On Tue, 2002-11-05 at 19:04, Linas Vepstas wrote: > > For this to catch on in the mainstream, other CPU architectures > > would need to add similar features as well. But given the recent > > burbling from microsoft and intel about palladium and how cpu arch > > changes can enhance security, (which intel seems to be actually > > working on) I do not think that it is too wild, too early or too > > impractical to engage in this task. > > I don't really see how fiddling with libraries helps you, but enlighten > me
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. Now, for the two core claims: 1) There are some really neat things that can be done with this design, (more below) 2) I beleive that the memory-key system in the 390 architecture is "just right" to be able to do this, and that its (relatively?) straightforward to implement. I have *not* created a working prototype, or dug into it for a few years now, but it seems doable. This feature has been and is used by other applications on the 390, on other operating systems. 3) One cannot really emulate this kind of memory protection, at least not without a big performance hit, which negates the whole point of having it in the first place. However, the changes needed to a CPU arch to support such a thing are simple, minor and doable. Probably in the form of a few extra bits page tables & TLB's and the needed logic to allow/deny read/write access to a page, based on which 'space' the current thread is executing in. 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. 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. c) Today, virtually all client-server IPC is through sockets. There is a lot of CPU overhead to set up a socket, jam data into it, process-switch, pull data out of it, decode it, and get on with business. Never mind the design overhead of having to invent a protocol. If the client and server are on the same machine, then this overhead is 'wasted'. There are cases where this overhead represents 99% of all CPU cycles to accomplish some function (certain DB queries, certain x-window drawing operations etc.). Imagine replacing this IPC with a simple call to a shared library. You're in you're out, you're done. But today, you can't, because any data that the shared library touches cannot be protected from the client, and so one traditionally needs to have a server to keep nasty clients at bay. (Imagine the converse: imagine that the only way a device driver could talk to the linux kernel was through a socket. Imagine how horrible that world would be. Well, that horrible world is called 'client-server computing' when one must live in user-space.) d) Apply one's imagination ... I'm not sure, but I wonder if it might help simplify the design/implementation of 'manditory access controls' (e.g. lomac, the NSA stuff, etc.) used for high-security. --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
msg09211/pgp00000.pgp
Description: PGP signature
