Deploying Encrypted Images for Confidential Computing

blog.hansenpartnership.com

3 pointsusr11064 comments

> The most obvious gap is that EFI booting systems don’t go straight from the OVMF firmware to the OS, they have to go via an EFI bootloader (grub, usually)

Why is that? We have used the EFI stub, which is part of the Linux kernel for quite a while. There is no need for a separate boot loader. Admittedly our systems are closer to embedded Linux than to big servers. What are the cases where you absolutely need grub (or another loader) today?

you need something that can decrypt the kernel from the encrypted image and then load it. OVMF + the efi stub can't do that whereas grub can read the luks format.

Why do you need to encrypt the kernel? It should not contain any secrets and it can he signed.

the encryption of the image isn't just about protecting secrets, it's also about making sure the host owner can't tamper with the image. If the kernel isn't part of the encrypted image, it can be substituted by the host owner and the new version could leak any secret they chose.

Signing, as I said in the article, is a possible solution but it's more complex to implement than simply putting everything into the encrypted image to assure being both confidential and tamper proof.

Reply on news.ycombinator.com