Many of us are now working with virtual firewalls. I did an earlier post regarding the strengths and weaknesses of security within the virtual realm, but today I want to talk about the firewalling possibilities with VMware. There has been a lot of excitement regarding VMware’s relatively new VMsafe API. Specifically, everybody is scrambling to create/deploy fast path firewalls. But are all fast path implementations created equal? Are there security concerns with going with a fast path solution? Let’s dive in and see.

Breakdown of VMsafe

With the release of the VMsafe security API, VMware has enhanced the options available for implementing security within a vSphere environment by permitting vendors to plug directly into the hypervisor at ring 0. VMsafe consists of three components:

• VDDK – Disk block inspection. API has been publically released.
• vCompute – CPU and memory API. Has not been publicly released. Unknown which third parties have access, if any.
• vNetwork – API to monitor/filter between the vNIC and vSwitch. Has not been publicly released. To the best of my knowledge, only  Altor Networks & Reflex Systems have access (two vendors who assisted in the development of the API).

Specifically, I want to speak to the vNetwork API. When controlling network traffic flow within an ESX host, there are two possible implementation, “slow path” and “fast path”.

Slow Path

Slow path is the simplest implementation and the one we have been using for years. Effectively this is just a VM guest, similar to any other VM guest, running on the ESX host. Typically each guest is connected to a unique vSwitch, and each of these vSwitches is connected to a unique vNIC on the firewall. This is similar to a legacy firewall setup, but implemented virtually. The benefit of executing in slow path is that you can run a full blow OS with any libraries or services required to support the firewall.

Fast Path

Fast path is effectively a ring 0 driver that plugs directly into the hypervisor kernel. This allows a third party vendor to leverage the hypervisor for insertion between each vNIC/vSwitch connection. Because a fast path driver is running in kernel context, it adds minimal overhead to the system. The result is code execution within fast path is substantially faster than the same code being executed within slow path (thus the VMware naming convention for each context). Load on the ESX host is minimized, so the end result is you can run far more virtual guests.

Fast Vs Slow

So it sounds like you would want to do everything within fast path, but there are a number of issues. Fast path is a kernel driver plugging into a minimized hypervisor, not a full blow operating system. This limits the libraries and services the firewall has available for controlling traffic flow.  Further, we are plugging in a kernel driver so there needs to be assurances that it does not bloat the hypervisor, increase the attack surface or interfere with other hypervisor functions. VMware performs a code review on all fast path drivers prior to release. So if I could theoretically implement all my code in fast path, I would need VMware approval prior to every patch or feature release.

With this in mind, a vendor claiming “fast path” support is actually going to end up implementing a portion of their code as fast path, a portion as slow path, and then create a connector between the two. How much load is placed on the system will depend on how much of this code is implemented in fast path and how much of it is executed in slow path.

Possible Fast Path Deployments

For example, a vendor could choose to write a fast path driver that simply tunnels all packets back to a slow path implemented firewall. The slow path code then determines if the traffic should be passed or dropped, with passed packets being sent back to the fast path code for insertion into the hypervisor control channel. While this would be the easiest method of deploying fast path, and arguably the safest and most secure, it would provide the least performance benefits. System load would probably not be much better than a full slow path implementation. I see this option as being very attractive to legacy firewall vendors, as it would require the least amount of modification to their existing code while still being able to claim “fast path support”.

Another option would be to use the slow path space for administrative functions with the fast path driver acting as the firewall engine. So for example the firewall administrator would create the policy using an interface running on a slow path VM, which would then push the policy down to a fast path driver. In this setup the fast path driver has a copy of the policy so traffic control can be implemented immediately.  The result is faster traffic handling with minimal system load. The trade off is bulkier code at ring 0.

It is also possible to implement a mixture of the two. For example I could use the fast path driver to implement the firewall policy, but then pass all “accepted” packets back to the slow path system for intrusion checking, virus scanning, or whatever is needed. Acceptable packets are then passed back to the fast path driver for insertion. So in this setup all “dropped” packets are handled via fast path, while accepted packets interact with a slow path component.

As a side note, you need to keep the above info in mind when considering all vNetwork implementations, not just firewalls. The vNetwork API can also be used for policy enforcement, QoS, gathering of network statistics, etc. For example the very first vNetwork implementation was actually VMWare’s Lab Manager. This tool is used for self service provisioning and does not contain a firewall component (this is implemented via vShield).

Summary

While a VMware product that integrates with VMsafe can strictly be a “slow path” implementation, it is highly unlikely that any product can be considered solely a “fast path” implementation. Any fast path product is most likely going to be a hybrid. It is just a matter of how much code exists in the “fast path” space versus the “slow path” space. When a product claims fast path support, you need to dig a bit deeper to analyze the implementation in order to identify any real performance benefits.