eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Google has often touted the various management and security capabilities available with its cloud services as part of an ongoing campaign to convince businesses about the enterprise readiness of its hosted offerings.
Continuing in that vein, the company this week offered some fresh details on the multiple security measures it has in place for hardening the open-source KVM (Kernel-based Virtual Machine) hypervisor at the core of its Compute Engine and Container Engine services.
In a blog, Google’s technical lead manager Andy Honig and senior product manager Nelly Porter outlined seven high-level security controls that Google employs for protecting KVM. They include processes for reducing the attack surface of the hypervisor, code provenance measures for ensuring the integrity of the code running in KVM, controlled software releases and updates and a systematic process for discovering and patching vulnerabilities in the software.
For example, to reduce attack surface on KVM, Google has limited the set of emulated instructions supported by the hypervisor and purged many unused components in it, including certain controllers and legacy drivers.
Similarly, to ensure code provenance Google verifies the integrity of its code all the way from guest virtual machines used by customers to the hypervisor and down to the boot-loader using a custom binary and configuration verification system.
The processes that Google employs to ensure the integrity of its code ensure that machines always boot to a known and previously verified good state, the two Google engineers asserted.
One important measure that Google has taken to mitigate security risks with KVM is to develop and use its own user-space virtual machine monitor and hardware emulator in place of the open source Quick Emulator (QEMU).
About two years ago, a bug in a virtual floppy disk controller in QEMU resulted in a critical vulnerability dubbed VENOM that gave attackers a way to take full administrative control of the underlying operating system that hosted guest machines in a virtual environment.
The custom emulator that Google has developed is far less complex and simpler than QEMU because it is designed for a single architecture and a relatively small number of devices, Honig and Porter wrote.
The in-house emulator does not support the large matrix of host and guest systems that QEMU does or its cross-architecture host and guest configurations. This makes the Google emulator easier to test and protect they said. “QEMU has a long track record of security bugs, such as VENOM, and it’s unclear what vulnerabilities may still be lurking in the code.”
In addition to such measures, Google has also built a substantial set of fuzzing tools to look for vulnerabilities in KVM each time new features and capabilities are added. Google also uses a formal code review process each time it adopts a new version or a feature of KVM. The measures, according to Honig and Porter, have allowed Google to find and fix a total of nine vulnerabilities in KVM over the past three years.
Over the same period, the open source community has found no vulnerabilities in the hypervisor that have impacted the Google Cloud platform, they added.