I've been learning about UEFI Secure Boot. It is designed to prevent malware from infecting the boot process and overwriting the bootloader. It has hardware-level protections to ensure that only a signed, trusted bootloader and OS kernel will be loaded and executed upon boot.
Today, malware can overwrite the Master Boot Record (MBR) with a malicious version, so that every subsequent boots into an evil version of the operating system. UEFI Secure Boot would prevent that, because your machine will only run the bootloader if it is signed, and the attacker's modified bootloader won't have a valid signature. In other words, with UEFI Secure Boot, you should be confident that, once you reboot, you're now running a valid and trusted bootloader and OS kernel. Sometimes people summarize this by saying that UEFI Secure Boot prevents "bootkits". OK, the basic concept makes sense.
I want to understand what stops the following sort of attack. Suppose you are running Windows (for example). Suppose the attacker, who has gotten malware on your machine and wants to ensure he'll stay resident after reboots, modifies the Windows startup configuration to launch a virtual machine (VM). Inside the VM is a modified Windows image -- just like a standard Windows kernel and OS and image, basically a full copy of what is on your machine, except that the kernel has been modified to plant some malware into it. When you boot, this VM is automatically launched, and (suppose) it automatically starts up in full-screen mode.
It seems like this attack subverts the intended goals of UEFI Secure Boot. From the user's perspective, it feels like they are running Windows, in their full desktop environment. What they don't realize is that their entire environment has been infected with malware. Sure, the host operating system is trustworthy (thanks to UEFI Secure Boot), but the guest operating system (within the VM) is malicious, and the user has no obvious way to tell that they are interacting with an evil guest rather than with the host. So, the user will think everything is OK, when actually they are hosed. Connoisseurs of security concepts will recognize this as an attack on "trusted path": the computer booted a trustworthy kernel, but the user has no way to verify that they are interacting with a trustworthy kernel rather than an entirely untrustworthy "evil twin".
Does anything prevent this attack? Or, is this attack technically feasible? If it is feasible, does it violate the security goals or threat model behind UEFI Secure Boot? (More generally, does anyone have a precise statement of the security goals and threat model underlying UEFI Secure Boot, and exactly what it does and doesn't guarantee?)
