Linas Vepstas wrote: >I didn't say it wasn't enormous. Its not tiny, but I'm not sure >its that big either.
Well, for a start, you can't really do program calls in home space mode (which is where Linux user mode runs), so you'd need to fundamentally redesign the whole kernel/user space model (and there's not much room for changes here unless you want to go back to a model where kernel pages are mapped into the user address space) ... > Depends on how easy you want to make >it for the app developer. Certainly a prototype would not do this >to everything, not by default. If you were to default it in the >wrong way, it would be enormous, and it would break many (most?) >apps. Indeed. However, if you need to significantly change your apps to make use of these hypothetical security features, then you could just as well change the apps to use existing mechanisms, like just using multiple processes ... >In some ways, I suppose this is possible today, but its hard & makes you >jump through loops. Client-server loops, in particular. Complex >IPC setups. Haven't you ever noticed how few apps actually use >traditional IPC (semaphores, shmem, etc?) That's because its hard, >its complexity, its crap that the app developer has to design, >and it takes a lot of effort. So System V IPC is crap, that's no big news ;-) Use pipes and/or shared mmap instead, and you'll see lots of applications that do that. (See e.g. the recently introduced 'privilege separation' feature of OpenSSH.) >Today, the only kind of >address-space security that unix has is that one process cannot >corrupt the address space of another process. Thus, if you want to >have address-space security, you *must* write multiple-process apps, >which means you *must* use IPC to coordinate the processes. Ugh. So what *is* that mechanism that is: - significantly easier to use than multiple processes / IPC - worth while for application programmers to implement even though they restrict themselves to a single platform - actually implementable in the Linux framework? I still don't quite see how this is supposed to work. One main point why just function calls are so much easier to use than IPC is that you can pass pointers to complex data structures back and forth. If you really implement some sort of strict memory protection, that won't work any more. So how do inter-protection-region calls pass parameters, and why is this then still significantly easier than IPC? Furthermore, if the protection is supposed to be enforced against adversary efforts (and not just some feature to catch bugs, like e.g. mprotect), then there needs to be a protection barrier set up by some agent outside of the process itself. E.g. you don't just switch the PSW key (the callee could just switch it back), but you need to actually change the PSW key *mask*, i.e. perform a program call or the like. This needs kernel help to set up program call numbers, entry tables etc. How it that kernel help to be triggered? What authentication mechanism protects access to these features? I don't think the S/390 hardware features are a 'magic bullet' that solves all these security problems. The real problem is to come up with an interface that actually provides these features in a sane way; the hardware might then be used to implement them in a more efficent way, maybe. (Other platforms provide similar features b.t.w. E.g. one could imagine a facility that uses call gates or task gates to implement inter-library calls. This would involve about the complexity and need the same sort of kernel help as using program calls in Linux for S/390 user space ...) Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
