Event details
How can we ensure that
- UEFI updates
- Reset of Secure Boot keys
- changing mainboard in case of events (like BMC defect or mainboard defect)
can be compensated?
In these cases I could imagine that the root of trust (PCR / TPM) are invalidated and in result this might prevent VMs from booting.
Lately I had a similar "lesson", without confidential VM, just vTPM enabled on the Hyper-V VMs and they refused booting after an UEFI update which fussed around with my Secure Boot so I had to delete the keys and redeploy them. Can you follow me?
Understood that's is a double-edged sword and trade-offs between confidentially and unexpected things that can happen.
I suppose that CVM are likely used in areas where confidentially comes along with high costs for outages. Thanks for sharing your thoughts!
Vikas_TikooMicrosoft
Great question. Yes things like UEFI or key updates do require care in ensuring secure boot will still work. Secure boot is however an important primitive for Confidential VMs and generally for VMs deployed with Trusted launch. It helps ensure integrity of early boot components. Also since you mentioned UEFI state, wanted to call out that ReFS rollback protection capability relies on UEFI variable store being protected. In Confidential VMs we take measures to protect the UEFI state through authenticated encryption. Hope this helps!