Consider support for AMD's SEV for Ryzen PRO (4750U) Laptop

[dylangerdaly]

The problem you're addressing (if any) According to CPUID, my laptop's Ryzen 7 4750U supports AMD's SEV.

AMD's SEV encrypts memory per VM (appVM/domU)

Uses one key per virtual machine to isolate guests and the hypervisor from one another. The keys are managed by the AMD Secure Processor. SEV requires enablement in the guest operating system and hypervisor. The guest changes allow the VM to indicate which pages in memory should be encrypted. The hypervisor changes use hardware virtualization instructions and communication with the AMD Secure processor to manage the appropriate keys in the memory controller.

Separating the all-powerful dom0 from just reaching into appVM's memory, this is greatly desirable.

According to this CPUID function the Ryzen 7 4750U supports SEV:

0x8000001f[eax]:
        Bit[0] indicates support for SME
        Bit[1] indicates support for SEV
0x8000001f[ebx]:
        Bits[5:0]  pagetable bit number used to activate memory
                   encryption
        Bits[11:6] reduction in physical address space, in bits, when
                   memory encryption is enabled (this only affects
                   system physical addresses, not guest physical
                   addresses)

[user@dom0 ~]$ sudo cpuid -r -1 -l 0x8000001f
CPU:
   0x8000001f 0x00: eax=0x0001000f ebx=0x0000012f ecx=0x0000000e edx=0x00000001

EAX is 0x0001000f

That's bit 0-3 and 16, meaning SEV is indeed supported.

Describe the solution you'd like Either Xen or Qubes add support for SEV, this requires changes on both the Hypervisor (Xen) and Guest OS's

Where is the value to a user, and who might that user be? I really don't think I need to answer this.

Describe alternatives you've considered Nil

Additional context Nil

Relevant documentation you've consulted https://developer.amd.com/sev/ https://www.kernel.org/doc/html/v5.6/x86/amd-memory-encryption.html https://www.cpu-monkey.com/en/cpu-amd_ryzen_7_pro_4750u-1356

Related, non-duplicate issues

[iamahuman]

If SEV support is implemented, we shall also encrypt individual Qubes volumes; otherwise Dom0 can inject malicious code into the VM anytime and exfiltrate private data from it. This means that it would be mainly useful only for DisposableVMs; AppVMs need to eventually save the encryption key when shutting down, which will be (of course) passed to Dom0.

Overall this issue would be better off tracked in Xen, unless Qubes is switching to KVM.

[dylangerdaly]

It's my understanding the encryption key used to encrypt memory is ephemeral, indeed the Guest OS is encrypting and decrypting memory pages, however dom0 isn't aware of what the key is, it only acts as a gateway/communicator to AMD's PSP, appVMs shouldn't be saving encryption keys for memory pages because they're ephemeral.

It's my understanding the entire point of SEV and SEV-ES is to separate the hypervisor from other appVMs.

Indeed persistent data becomes the problem, Qubes would need to implement changes to it's LVM storage layer to enable per-AppVM persistent data, it's possible to do this now with cryptsetup within a appVM.

Sent from ProtonMail mobile

-------- Original Message -------- On Oct 7, 2020, 2:53 AM, iamahuman wrote:

If SEV support is implemented, we shall also encrypt individual Qubes volumes; otherwise Dom0 can inject malicious code into the VM anytime and exfiltrate private data from it. This means that it would be mainly useful only for DisposableVMs; AppVMs need to eventually save the encryption key when shutting down, which will be (of course) passed to Dom0.

Overall this issue would be better off tracked in Xen, unless Qubes is switching to KVM.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[iamahuman]

It's my understanding the encryption key used to encrypt memory is ephemeral, indeed the Guest OS is encrypting and decrypting memory pages, however dom0 isn't aware of what the key is, it only acts as a gateway/communicator to AMD's PSP, appVMs shouldn't be saving encryption keys for memory pages because they're ephemeral.

Memory encryption keys shall of course be ephemeral; there's obviously no point in storing them anywhere other than inside the CPU.

Indeed persistent data becomes the problem, Qubes would need to implement changes to it's LVM storage layer to enable per-AppVM persistent data, it's possible to do this now with cryptsetup within a appVM.

Please excuse my ignorance. Does AMD CPUs support something like Intel TXT but which can also provide a secure way for VMs to store disk encryption keys persistently without leaking them to the hypervisor?

[andrewdavidwong]

AMD's SEV encrypts memory per VM (appVM/domU)

It's worth noting that, in Xen, dom0 is also a VM. (It's dom0, but it's still a dom.)

Separating the all-powerful dom0 from just reaching into appVM's memory, this is greatly desirable.

Wait, why is that desirable? In Qubes, dom0 ultimately has control over all domUs, and it would seem that many aspects of Qubes are based on this design principle. Changing such a fundamental thing in Qubes would surely involve more than just enabling SEV, wouldn't it? Moreover, it's unclear what the benefit would be. Keeping in mind that Qubes is a single-user system, what is the use case for having a domU whose memory is protected from dom0? If anything, that seems potentially dangerous in the case of untrusted domUs (of which there are almost always some, e.g., sys-net and sys-usb).

On the other hand, the opposite is clearly desirable: protecting dom0's memory from domUs. In particular, recent speculative execution vulnerabilities threaten to expose passphrases and encryption keys used in dom0 (e.g., for LUKS disk encryption and the screenlocker), so measures to mitigate this are important.

Either Xen or Qubes add support for SEV, this requires changes on both the Hypervisor (Xen) and Guest OS's

My sense is that this should probably be in the Xen tracker rather than here, but I'll leave that up to @marmarek.

[iamahuman]

AMD's SEV encrypts memory per VM (appVM/domU)

It's worth noting that, in Xen, dom0 is also a VM. (It's dom0, but it's still a dom.)

AMD SEV only applies to hardware-accelerated virtual machines, limiting it to HVM and PVH in Xen. As of October 2020, support for PVH mode in Xen dom0 is experimental (HVM is not useful here), and stub domains are still limited to PV.* (Eventually we'd like to transition exclusively to HVM/PVH anyway for other aspects of security.)

Separating the all-powerful dom0 from just reaching into appVM's memory, this is greatly desirable.

Wait, why is that desirable?

In case of Dom0 compromise, it is theoretically possible to keep some sensitive ephemeral data in VMs protected. Anything beyond that would require supplementary technologies which resemble Intel SGX and/or TXT.

Besides, it might mitigate some specific kind of microarchitectural vulnerabilites which allows a malicious VM to exfiltrate confidental data from other VMs, since each VM can use a different key.

In Qubes, dom0 ultimately has control over all domUs, and it would seem that many aspects of Qubes are based on this design principle.

Indeed. AMD64 Architecture Programmer’s Manual states that:

It is important to note that SEV mode therefore represents a departure from the standard x86 virtualization security model, as the hypervisor is no longer able to inspect or alter all guest code or data. The guest page tables, managed by the guest, may mark data memory pages as either private or shared, thus allowing selected pages to be shared outside the guest. Private memory is encrypted using a guest-specific key, while shared memory is accessible to the hypervisor.

As you have commented, SEV is not useful if we assume dom0, CPU and the host hardware never to be compromised.

Note that in case of dom0 intrusion, adversaries can still shut down, destroy or corrupt data of encrypted VMs. Essentially, SEV only implements the confidentality aspect of the CIA triad.

Changing such a fundamental thing in Qubes would surely involve more than just enabling SEV, wouldn't it?

Yes. Effectively taking advantage of protection provided by SEV requires at minimum:

• Encryption of all block devices, including swap devices.
• Disallowing arbitrary shell command (and code) execution requests from dom0. Either:
  • Reject commands from any VM, or
  • Move qrexec host and policy agent to a designated domU.
• Restructuring existing codebase not to blindly trust data from dom0.
• If accepting input from the user, somehow enforce separation of GuiVM and dom0, and receive user input via some secure channel.
• Finding some secure way to store persistent data on VM shutdown without trusting dom0.

Moreover, it's unclear what the benefit would be. Keeping in mind that Qubes is a single-user system, what is the use case for having a domU whose memory is protected from dom0?

Possibly protecting against some kind of inter-VM covert channels, and minimizing impact of dom0 intrusion.

If anything, that seems potentially dangerous in the case of untrusted domUs (of which there are almost always some, e.g., sys-net and sys-usb).

Yes, it is. #2417 also becomes unusable in this case.

[iamahuman]

On the other hand, the opposite is clearly desirable: protecting dom0's memory from domUs. In particular, recent speculative execution vulnerabilities threaten to expose passphrases and encryption keys used in dom0 (e.g., for LUKS disk encryption and the screenlocker), so measures to mitigate this are important.

It is, although implementing this via SEV will only be possible one day when dom0 becomes a PVH VM.

Meanwhile, SME is undoubtly desirable for Qubes. This however also requires patches to Xen, which again are better tracked in upstream.

[marmarek]

As of October 2020, only PV mode is supported for Xen dom0

Not exactly true - experimental PVH dom0 is already available.

and stub domains.

This unfortunately is still the case. Although hopefully not that hard to implement (we do plan to contribute this part to Xen, when the time allows).

Encryption of all block devices, including swap devices.

Something on the roadmap for a long time already but for a different reason - see "Storage Domain" in arch pdf. But for this to be realistic, we need dom0 (or similar entity - see domB proposal on xen-devel) bootable without access to the hard drive (which will be isolated in separate domain).

* and receive user input via some secure channel.

This is very problematic point in practice. None of currently (publicly) available technologies provide confidentiality or even just integrity of communication with external (intput/output) devices. We have some ideas for workarounds, see #2518 for example.

In summary: this is interesting research direction, but there is a looong way for it to provide meaningful value, leaving alone the support in Xen itself (or using KVM instead).

[marmarek]

And one more comment: our general direction is to take as much data processing away from dom0 as possible (reduce dom0 attack surface), not necessary limit dom0 permissions (reduce impact of dom0 compromise). While the latter is not a bad idea in general, and can be pursued in parallel, the former is much more generic and applicable to more use cases (for example benefits also non-AMD SEV-ES compatible systems).

[tasket]

I also think SEV is a valuable contribution to security, but I share the reservations of others here about the role of dom0/admin. The greatest threats come from the domUs, so it would make sense to deploy SEV so as to prevent domU side-channel attacks against other domains; I believe this would be easier and quicker to implement in addition to being more impactful.

Protecting VMs against dom0 runs counter to Qubes design, IMHO. Components that have been identified as trusted should remain that way.

[marmarek]

I've updated the title, as it is far more involved task, than just flipping a switch.

[brendanhoar]

Protecting VMs against dom0 runs counter to Qubes design, IMHO. Components that have been identified as trusted should remain that way.

Agreed.

Though...there is potential applicability of SEV to anti-forensics efforts, in that dom0 should retain as little knowledge as possible of domU VM content e.g. after VM shutdown. Whether or how SEV fits into that category (or not) is unclear to me at this time.

B

[Geblaat]

The new generation of SEV, SEV-SNP now also provides integrity protection and some other features: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf