search

AMDESE / AMDSEV

AMD Secure Encrypted Virtualization
272 stars 84 forks source link

Does AMD SEV encrypt QEMU disk images? Why should I convert it to NVRAM? #39

Open vgadalov opened 4 years ago

vgadalov commented 4 years ago

Hello, I am student and make research of QEMU images encryption methods. I found AMD SEV very interesting solution. And have simple questions: 1) Does AMD SEV encrypt QEMU disk images? 2) What do you mean by NVRAM in context of QEMU images? 2) Why should I convert my QEMU image to NVRAM using OVMF_VARS and use QCOW2? 3) I found a lot of topics, that QCOW2 is unstable format of images and has 5% performance loss, is it true?

Thanks a lot for your answers in advance, I hope it is not hard to answer for them.

tlendacky commented 4 years ago
  1. No, AMD SEV does not encrypt QEMU disk images.
  2. The NVRAM file is used to hold UEFI information, such as boot order, etc. Each VM should have it's own copy.
  3. Only OVMF supports SEV (e.g. SeaBIOS does not), so you need to use OVMF. You do not have to convert to QCOW2, however, you can use a raw format image if you desire.
  4. I don't have any info about the stability or performance of the QCOW2 format.

Thanks, Tom

vgadalov commented 4 years ago

Thanks for your reply! In my situation, host is unsecured point, and somebody can get access to RAM of this host and take data from RAM (with LUKS decryption keys). Can I solve this problem using AMD SEV or something like that? Thank you in advance!

tlendacky commented 4 years ago

Thanks for your reply! In my situation, host is unsecured point, and somebody can get access to RAM of this host and take data from RAM (with LUKS decryption keys). Can I solve this problem using AMD SEV or something like that? Thank you in advance!

This should be possible. DMA to an SEV guest is done to shared/un-encrypted memory using SWIOTLB to bounce between encrypted and un-encrypted memory. So the disk I/O would be bounced from unencrypted memory to encrypted memory where it would then be decrypted - so you are safe at that point - the disk data is in encrypted memory and the hypervisor would see ciphertext and not the actual data. For the LUKS decryption keys, you would need to obtain them in such a way that they aren't exposed to un-encrypted memory. So you wouldn't want to enter a passphrase, since that would have remains in un-encrypted memory, etc. As long as the LUKS keys remain in encrypted memory, only the guest would be able to read them successfully. The hypervisor would see ciphertext instead of the raw LUKS key. I hope that makes sense.

Thanks, Tom

ME0x1A4 commented 3 years ago

Why is it actually necessary to use OVMF? As far as I understand SEV first marks everything as encrypted. The guest then has to enter long mode to be able to mark pages, i.e. the DMA region as unencrypted for communication. So shouldn't it be possible to boot into an kernel via a bios e.g. Seabios and then make the kernel responsible for entering long mode (which some do anyway)? Or do you need to make some changes to the bios?

I understand why AMD only actively supports OVMF. But for some scenarios OVMF is just too much. Also it takes quite long to boot compared to for example qboot.

codomania commented 3 years ago

The SeaBIOS does not boot in the long mode. SEV requires the DMA to be performed on the shared page. A page can be mapped shared only when the guest is in the long mode.

BTW, seabios uses DMA operation to load the kernel itself.

Based on the community feedback we choose to add the SEV support in the OVMF, but there is nothing hard coded in the SEV firmware or KVM to require OVMF. You should be able to boot any guest BIOS as long as the guest BIOS is SEV enlightened.