From: shearerje_at_comcast.net
Date: Sat Feb 28 2004 - 15:20:22 PST
I love it, I hate it. I love Denali because time and again I have fought the battle that security needs to be designed in, not strapped on. Denali starts by completely isolating a service in its own VM and not allowing it to do anything outside this boundary. Then Denali provides only those interfaces that it WANTS the service to have. This is far more robust than the WindowBox approach of starting with a wide-open OS and then trying to define what it DOESN’T want the service to have. I hate Denali because, in it’s zeal to control everything, it virtualizes the timer and, ohmygod, batches it with the other interrupts. The only projects I ever work on are embedded near-real-time applications, and these can’t possibly work in Denali. This is not what Denali was designed for, but I can’t help seeing the world through MY requirements.
What Denali IS designed for is multiplexing a thousand or so different services that require minimal data exchange between them and that are loaded following the 90/10 rule (10% of the services do 90% of the work and vise versa) or, more formally, a Zipf distribution (that is, if the services are enumerated along one axis of a log-log plot and the frequency of invocation is enumerated along the other axis, then the distribution forms a straight negatively sloped line). Denali multiplexes these services while protecting the platform from the services and the services from each other, and bounding each service’s resource consumption. It does this by running each service in its own VM, narrowing the API to system resources and, as mentioned above, virtualizing the interrupts.
Denali uses a FIFO gatekeeper to control introduction of services into the system, placing each one in its own VM, and then uses a round-robin scheduler to manage context switching between VMs. Each VM has its own virtual memory space in which the application and any “guest” OS must run. This means either the applications and guest OS share the same memory space or the VM includes a light-weight virtual memory management unit (the Denali team made one not long before the paper was written).
Denali subscribes to the “economy of mechanism” approach to security and so offers stripped down and simplified APIs to the system resources. This includes emulating simplified I/O devices, hiding BIOS and segmentation hardware, and more-or-less hiding those x86 instructions that behave differently in user mode then in kernel mode. One effect of this is that Denali does not (and is not intended to) run unmodified legacy guest operating systems. This makes sense to me. As a point of reference, Disco was supposed to run commodity operating systems and failed (recall that in Disco the OS’s HAL needed to be modified, so it was not truly “commodity” any more). Denali does, however, add two new virtual instructions not found in the x86; VM idle and timeout, and VM terminate. Thus, while a legacy OS might not work, a new OS can be created that uses Denali to good effect (E.g., the Ilwaco OS).
Denali virtualizes and batches all interrupts, passing them to the VM during its next regularly scheduled service window rather than performing out of sequence VM context switches. This delays interrupt delivery but greatly reduces the context switch overhead that would result from 1000 different VMs trying to service their interrupts all at once.
This archive was generated by hypermail 2.1.6 : Sat Feb 28 2004 - 15:20:28 PST