2

I have a question, How would secure boot be implemented in a virtulized environment, say XEN hypervisor with multiple guest OS's including Windows 8 guest VM? does the guest VM need access to the hardware validation as well?

Arabisc
  • 21
  • 1
  • You would simply disable the secure boot option in a virtualized environment. At least until the virtualized environment supported secure boot. Why is everyone so worried about Secure Boot? – Ramhound Jul 05 '12 at 18:30

1 Answers1

2

A virtualised environment could would be easier to handle in this case.

Firstly, in order to load any operating system, you need to emulate boot. So a VM implementation such as Intel VT only implements CPU emulation; the rest is up to the vm software. Everything must either be emulated or passed through with hardware support.

Boot is no exception - and as most VM solutions currently emulate MBR-based BIOSes there is no reason for them not to be able to emulate EFI boot either. The EFI spec is publicly available and GPT-partitioned disks such as are required to EFI boot with Windows have been creatable for a while now.

Now the question is - how does secure boot work? Well, without diving too deep into the specification, the concept is that the binaries you wish to boot are signed with a private key and the corresponding public key is shipped with the hardware. I'm not yet sure to what extent a full x509/PKCS trust chain is in place, but I believe that's the aim.

Given an executable the hardware is asked to boot, secure boot means very simply that it will check the signature(s) on that executable and if they match its internally trusted certificates and the signatures remain valid, great, they can boot. If not, the EFI shell simply tells the user "sorry mate, can't boot that, don't like it" and bam, out you go.

So from the point of view of guest operating systems, life is easy getting things to boot - just allow it and don't check the signatures.

Things get more complicated when it comes to the OSes ability to establish a channel* to the hardware, however - I believe (I've not read that bit of the spec thoroughly, but I have read the GPT layout part. I can quote GPT layouts to you in my sleep!) operating systems will communicate with the EFI shell should they wish to notify it of changes to their environment, replace keys etc. This would need to be emulated correctly; a failure to do so would undoubtedly break the host OS assuming it requires and expects the protocol to exist.

If Windows 8 is going to insist upon secure boot and the ability to interact with the hardware, that'll all require correct emulation. However, OSes that merely require getting started it'll make no difference to.

  • I agree. Secure boot in a virtualised environment shouldn't be too big a problem. Virtualisation just extends the chain of trust. If your hypervisor bootloader was trusted to launch, you then trust the hypervisor to only allow trustworthy guest VMs (and their boot loaders) to be run. Emulating EFI is one way of doing this. The big thing about Secure Boot is getting the initial step sorted. – jplyle Jul 06 '12 at 16:50