How can I protect a VM build e.g. with LinuxKit, if my host system is compromised? Are there methods available or am I always at the host's mercy? And is it possible to isolate what's going on inside the VM from the host in order to avoid data leakages?

  • Do you mean protecting the guest by using something like this? – user Jul 31 at 17:43

Using a traditional virtualization model, all components of the hypervisor and guest share physical hardware components. In this case, any attempt at protecting the VM from the host is purely obfuscation, and not by any means genuine protection.

In order to protect a VM from a compromised hypervisor, you will in fact need hardware support for this software isolation. With the growing popularity of cloud computing, a number of technologies have in fact been developed to specifically address this.

The technology which most accurately reflects a traditional virtualization model from the idea of a malicious hypervisor is most likely AMD's Secure Encrypted Virtualization. This technology is managed with KVM/QEMU infrastructure which you may already be familiar with for server virtualization.

SEV relies on hardware support to be able to encrypt the memory contents of a running VM. A request is made specifically to AMD's Secure Processor to encrypt an individual VM and it is done so using a key which is not held by the user or known anywhere outside of this inaccessible coprocessor.

Keep in mind that SEV doesn't necessarily support encrypting the image the VM boots from at rest, if that is a concern. That still may mean user input or some form of multi-factor authentication is required to initially decrypt the VM contents during boot if they are encrypted with LUKS or something like that - however, after booting, the contents will remain protected with SEV.

Other technologies exist to perform similar tasks of creating a secure "Trusted Execution Environment" or TEE within a potentially malicious or compromised host operating system. Intel offers SGX, or Software Guard Extensions, to create TEEs (or "enclaves") on Intel hardware. SGX is generally intended to be used for more specific tasks than full operating system virtualization, instead being designed for things like key generation and data encryption/secret storage which can serve as a component used to protect and validate execution of other steps which happen outside of the TEE. I recommend this paper if you're looking for a comparison between SGX and SEV.

Similar technologies are also in use on mobile devices, such as ARM's TrustZone, which is sometimes used to protect features such as device encryption and authentication via fingerprint from the potential of being compromised by the host.

In summary, yes, you can absolutely isolate a VM or TEE from compromised host hardware, but it requires the hardware it's running on to be designed to offer such protection.

  • TEEs like TrustZone are a physical part of the processor loaded with a firmware to provide a few cryptographic functions. The resources available in a TEE are nowhere enough to execute a VM. Also, SGX cannot be used to create a TEE. I do not know of SEV, but from what I just read about it, I do not think you can use it to isolate a VM either. – A. Hersean Aug 5 at 8:56
  • SGX provides more than a "few cryptographic functions" and can be used to create a secure enclave in which a TEE can be made, but is not provided by Intel. See: SgxElide: Enabling Enclave Code Secrecy via Self-Modification. It can also serve as a host for a library OS, similar VM, see: Graphene-SGX. SEV can be used to isolate and encrypt a VM. That is both its stated intention and functional implementation. – svartedauden Aug 5 at 19:15
  • That's not exactly what I stated. Maybe we do not agree on the definition of TEE. Other than that, I stand by my statement that you cannot execute a VM in a physically isolated TEE. I suggest you read the attempts done by Open Whisper Systems to use SGX to isolate the Signal servers from their host: the practical protection offered by SGX is rather limited. – A. Hersean Aug 7 at 10:03

VM's are an abstraction we refer to for convenience. The underlying reality is that it's all code running on the host. You can protect a non running VM file with encryption, but a running VM client is running on the host, with host memory and host CPU. The host has access to everything.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.