[jeroenhd]

Secure boot on a cloud machine is pretty useless, there's nothing stopping the hypervisor from injecting code into the running machine. Theoretically virtual machine memory is encrypted, but you'll just have to trust the hypervisor's word for it. You can try to verify the boot chain all the way to the hardware keys, but if the hypervisor just replaces your `JNE` with a `NOP` you'll have a hard time automating your protections.

I suppose you can transfer the keys out of the machine over the network (and hope the hypervisor doesn't replace the socket buffers just before transmission) and verify them off site, but guest machines will always be just that: guests on a host that has all the power.

[comex]

That is not the case for the latest CPU extensions for encrypted VMs, AMD SEV-SNP and Intel TDX, which are designed to allow remote attestation based on a key hidden in the CPU that the hypervisor does not get access to.

The hypervisor only ever sees the VM’s memory in encrypted form, and it’s integrity-checked by the CPU to prevent replay attacks.

[immibis]

SGX has been bypassed with hypervisor access. I'm sure the new extensions are different, but have similar fundamental flaws.

Besides, a nation-state actor can compel Intel to disclose your CPU's key.

[kuschku]

The Hetzner server used here was a dedicated, physical server.