EVALUATION ---------------------------------------------------------------------- I gave the paper low marks for originality and technical strength because it is a position paper that does not describe new work, not because I disagree with the notion that software protection mechanisms are both useful, more flexible than hardware mechanisms, and sometimes more suitable for enforcing controls on application-specific high-level abstractions. This notion seems reasonable to me, and I was somewhat surprised to see the authors claim that "much of the operating systems community" disagreed. I'm not familiar with any modern (newer than 1965) multiuser timesharing operating system that doesn't use some software protection mechanisms when appropriate, even if it's only something like /bin/login. Even single-user OS's like Plan 9 terminals use separate process namespaces for protection. The idea of using more adventurous software-based mechanisms can't be too unwelcome in the OS community if the authors of this position paper also got their SPIN paper published at SOSP in the same year. I may be more cautious than the authors in some cases with regard to claims of improved performance. For example, I agree that run-time array-bounds checks in languages like Java provide finer-grained protection than page-based hardware checks. However, if all you want is to protect one process from another, then the hardware checks are apt to perform better than run-time bounds checks done in software. ---------------------------------------------------------------------- The strengths of using software-based protection approaches are stated above. Specifically, software-based approaches allow more fine-grained protection, allow static determination of runtime properties that no longer need to be checked (and thereby improve efficiency), and are more flexible in terms of the policies they can enforce. The weaknesses are not clearly stated in this work, but there certainly are some. Most obviously, the techniques envisioned by the authors to prove the correct enforcement of the described properties are likely to be difficult. In some ways, the coarse level of per-process protection is a nice simplification that we know can work if implemented correctly (albeit, for a smaller set of policies). The more fine-grained the protection policy, the more difficult it will be to prove the correctness of the enforcement mechanism. ---------------------------------------------------------------------- Being a short paper, this gives a good overview on why software mechanisms that enforce security are needed and are more flexible than its hardware counterparts. However, I would like to see some examples a little easier to understand, especially at the end of the paper. ---------------------------------------------------------------------- The 'technical' portions are largely in the references. The overall approach seems solid and believable. The fact that the hardware cannot do everything is a given. That we can statically verify certain program behaviors is as well. ---------------------------------------------------------------------- The authors seem to have arrived at a fairly obvious conclusion; any hardware protection mechanisms must be configured in some way, presumably via software, if they are to be usable in more than a handful of situations. The writing style of the paper strikes me as a contribution to one side of a long-running flame war. It is possible that the paper was needed to bring some sort of reality check to what seems to have been a hot debate, from the tone that was used. To their credit, the authors did state that any software protection mechanisms need to be backed up by another methodÐ either more software or hardware mechanisms. In my view, if the underlying hardware system does not have enough inherent protection mechanisms to be trusted, any software protection is moot. For example, if you do not want your embedded systems software to run on hardware cloned by a competitor, you must have some sort of mechanism hidden in the hardware to enforce your licensing scheme. These types of systems have their own faults, of course, but clearly both hardware and software mechanisms are needed to gain the variety of protections needed. ---------------------------------------------------------------------- 1. A list of some current software security problems which are not solved by hardware protection, and an explanation of why software is a better place to solve these problems. The authors argue that security must be very fine-grained, that hardware-based security cannot be fine-grained, and that software-based security is therefore the answer. 2. The assertion that hardware can't do everything is correct (but pretty obvious), but the implication that software should do everything is not explained. The paper is entirely composed of statements about what the system should do, without any explanation of why or how. A number of software-based-protection related projects are mentioned, but no information about why any of them are particularly important. 3. The authors make a number of weird statements, like, "...our microkernel-based systems seem to crash about as often as our conventional systems. A lot of our friends say the same thing." I'm not aware of any microkernel systems in production -- just research systems. What are they talking about? Certainly, WindowsNT and Mac OS X (which use hybrid microkernels) are better behaved than Windows98 and Mac OS 9, respectively. And why is it that the only example they use is about protecting the contents of one window from another in X? That's either a really contrived example, or they're talking about some problem I'm not familiar with. 4. Why *can't* we have hardware protections for windows? If a lot of the window-drawing work gets farmed out to the GPU, then it'd be trivial to give a window-area the same sort of protections that memory regions or files get. That's not a research idea, but I think it'd be pretty funny. ---------------------------------------------------------------------- Hardware protection is still necessary for keeping programs from reading from and writing to arbitrary locations in memory, so long as programs can attempt to use arbitrary values as ways of naming locations in memory. Software can act as an additional layer for this by abstracting execution away from the hardware (like with Java), but ultimately that additional layer must also be subject to protection, too (the JVM should probably not be given free reign on the underlying resources). I do not really think that the authors believe that hardware protection can be done away with altogether, but it still must be available to provide the "teeth" for software protection to work. Also, at one point the authors defer criticism for compilers as a software protection mechanism with the phrase "not all compilers generate bad code", but nevertheless compilers are also software and subject to attack. If we put a lot of reliance on compilers for security, then compilers will be an even more valuable source of scrutiny for those who wish to break security. ---------------------------------------------------------------------- RESEARCH IDEAS I've got this 8-bit Zilog Z8 Encore microcontroller evaluation board that I've been fooling with. I was thinking about ordering a new one with an Ethernet NIC on it, and then writing a batch-monitor OS for it. The plan was to let it accept batch jobs written in Scheme via E-mail. (Who needs consoles, storage, and swap space when you can get free webmail accounts?) The Z8 Encore chip doesn't have ring, paging or segment protection mechanisms, so whatever security there will be will be up to the software. The top layer of the OS would be a Scheme interpreter, and security would be provided by (1) Scheme's traditional run-time checks and (2) the interpreter wouldn't make "privileged" instructions available to user programs (like "halt" and the stuff for flashing the flash-RAM). So, in a simple way, this is what Bershad's group is talking about, just minus the sexy stuff like proof-carrying code. Of course the icing on the cake would be to mount the device in an empty Inca-Cola can, and call it the "Lambda Can". OK, so I don't get out much. ---------------------------------------------------------------------- Based solely on this paper, which is mostly of motivational value, it is hard to point to specific future work. I think studies into the failures of real systems, both in terms of protection and efficiency, seem to be important for this area. Why do the microkernels discussed by the authors prove insufficient? What policies cannot be enforced by classic OS/hardware methods that are important and interesting? I know there has been work on these areas so I look forward to reading this work. Finally, of course, the programming language techniques used to provide the properties identified by the authors as important are imperative to the success of this approach. The 'technical' portions are largely in the references. The overall approach seems solid and believable. The fact that the hardware cannot do everything is a given. That we can statically verify certain program behaviors is as well. ---------------------------------------------------------------------- Come up with a formalism for expressing high-level notions of security in terms of formal programming language ones. ---------------------------------------------------------------------- In my opinion, the authors seem to have taken a rather narrow view of hardware protection mechanisms. To date, most of the protection mechanisms implemented in hardware have been mostly rigid, coarse, and of somewhat limited value, presumably due to the expense of creating advanced protection mechanisms in hardware. The need to remain backward-compatible with legacy software, and the political and organizational complexity involved with real-world implementations of hardware-assisted protection mechanisms (like DRM and Palladium) seem to have slowed much of this work to date. This does not need to be the case, however; parameterizable and configurable hardware mechanisms could be put into place that would give software-like precision and flexibility to the control of resources. Special-purpose hardware has often contained peculiar mechanisms, such as specially protected memory for isolating crypographic keys from the rest of system memory. As the authors stated, however, to date these hardware mechanisms have largely been all-or-nothing systems. Designing modular, flexible hardware protection mechanisms that can be controlled and adapted by some specially trusted software could bridge the gap between the two worlds. ---------------------------------------------------------------------- The authors make a lot of generalizations about using static checks to optimize away run time checks. I think this could be a great advantage for some systems that rely on run time checks for their protection (like with Perl taint mode, for example). ---------------------------------------------------------------------- The paper does not present any technically new ideas, but rather tries to bring to the forefront the advantages of software based protection and also the limitations of harware mechanisms. The authors make a clear position statement about software being flexible, explicit and precise while hardware is contrasted as being rigid implicit and imprecise. They justify each but in their examples of the different kind of protection mechanisms seem rather obtuse. This can be ignored on the account of the fact that this is a fairly old position paper.