-
The most widely deployed mobile virtualization solution
Data Sheets
Open Kernel Labs Blog
June 29, 2009
Competitor FUD: Device Drivers
When talking to prospective customers, we frequently get told stuff along the lines of "your competitors claim X", where X turns out to be total nonsense. Certainly nothing they would dare to raise in public.
I guess I can understand why this happens. They are in a difficult situation: having to compete against superior technology that's been widely deployed for years. Not an enviable position to be in! Still, not a valid excuse for making things up.
It's always hard to defend against such behind-the-back badmouthing, and one might be tempted to do the same. But that isn't my style. So I decided to take those claims head-on. If you have heard similar ones, please let me know. You don't even need to tell me where it's coming from (I can generally tell anyway).
The FUD I'd like to address today regards device drivers. Some competitor claims that when using OKL4 to virtualize an OS, all the guest's device drivers need to be ported, if not re-engineered. This, of course, strikes a chord with prospective customers, as device drivers are tricky pieces of software that are expensive to write and modify.
Fortunately (for us, not for the competition), that claim is complete bogus. A device driver that is part of a guest OS (like Linux or Symbian) will function without any modifications when that OS is virtualized on top of OKL4. We know: we do it all the time.
And, why shouldn't it? Let's look at how a driver operates. As far as virtualization is concerned, what is relevant is the interaction of the driver with the hardware. This happens by reading from and writing to device registers. In embedded platforms, these device registers are normally memory-mapped, meaning that the driver accesses them via normal load and store instructions.
In an OS that runs native on the hardware, the driver is normally part of the kernel (runs in privileged mode) and thus has direct access to physical memory (with or without involvement of the MMU), including the device registers. When that OS is virtualized on OKL4, the driver's memory accesses are subject to virtual-memory translation, So, all we need to do is map those device register into the guest's address space, and the driver can operate as normal: issuing loads and stores to access device registers.
This isn't rocket science by any stretch of imagination, it's in fact pretty straightforward. Any virtualization provider who cannot do this without resorting to pseudo-virtualization doesn't know what they are doing and would be better off writing accounting software.
What those competitors don't like (or maybe don't get?) is that OKL4 offers you two ways to run drivers, as shown in the figure on the right. The one is what I have just described: a driver is left (unmodified) inside its host OS. The advantage is zero porting cost. The drawback is that you need to trust the guest with that particular device. This is fine in many cases, but in others creates a security hole. If the correct operation of the device is essential for the security of some other subsystem, then leaving the driver inside its original host makes that host part of the trusted computing base (TCB), notwithstanding the fact that it is running in user mode.
For those cases, OKL4 provides the option of running the device driver isolated, in its own Secure HyperCellTM. This removes any guest OS from the TCB of a subsystem relying on the device, but comes at the cost that now the driver has to be ported to run in a lightweight, native OKL4 environment.
So, porting drivers isn't a requirement, it's an option for achieving a higher degree of security, Like it or not.
Posted by Gernot Heiser on June 29 at 02:57 AM
blog comments powered by Disqus
About Gernot Heiser:
Gernot Heiser, Co-founder and Consulting Scientist, never thought he would be in the business world. Prior to NICTA's creation in 2003, Dr Heiser was a full-time faculty member at the University of New South Wales. However, this die-hard academic couldn’t pass up the opportunity to see the commercialization of this research. Gernot still loves teaching, almost as much as he loves good wine and good food. And anyone will tell you that Gernot knows his wine.