Piqued your interest? Bear with me. In a previous post, I promised to revisit the issue of “Fast-path” and “Slow-path” in the VMware vSphere platform.
With vShpere, VMware has released the first commercial implementation of its VMsafe set of APIs. As I have discussed, VMsafe is cool, but not a panacea. VMsafe provides developers two alternatives for where their security code runs – either in the hypervisor itself (ie Fast-path) or in a guest VM (ie Slow-path). As you might infer from the ‘accurate-from-an-engineering-perspective-but-horrible-from-a-marketing-perspective’ names of “Fast-path” and “Slow-path”, code running in Fast-path doesn’t incur the performance overhead of context switching and other activities associated with code running in a guest VM.
To overcome the performance penalties of running something like a firewall or IPS in a guest VM (Slow-path), vendors are looking to take advantage of the Fast-path capabilities of VMsafe. The problem is that putting unmanaged active code directly into the hypervisor is a bad idea just as putting unmanaged binary code directly into the browser was a bad idea with the original implementations of ActiveX inside of Internet Explorer years ago. Capabilities that help the good guys with better performance and access to raw platform capabilities can also be used by the bad guys if access to these capabilities is not carefully considered. We have lived through this already with the browser and are still dealing with the pain.
Let’s learn from our mistakes. Require third party code that will be installed in our virtualization platforms to be highly managed and trustable from the beginning and the platform underneath to be built assuming that attempts will be made to introduce hostile code. For example, require digitally signed code from the vendors and require the platform underneath to support Mandatory Access Controls on the use of APIs and to support whitelisting and blacklisting of code by administrators. And that’s just getting started. I’ve got a whole list of requirements for clients to use when evaluating the security capabilities of virtualization platforms. I’ll be discussing this and more in my session “Securing Virtualization and Virtualizing Security” Tuesday morning here at the Gartner Information Security Summit.
Faster performance? Great! But, I shouldn’t have to compromise the security and integrity of the entire platform (and all hosted workloads) to achieve this.
By the way, this is not just an issue with VMware and VMsafe. Running arbitrary third party code in the “parent” or “Dom0” partitions of Hyper-V and Xen respectively creates similar issues.
Virtualization is a new platform with a chance to do things better and differently. Let’s not repeat the mistakes of the past and allow poorly written or malicious third party code and a platform underneath that enables this without question to jeopardize security.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.