AMD EPYC security.sev and ...policy.es

Hi, I am trying to better understand how AMD EPYC CPU’s memory and register encryption behave under incus. I have several EPYC CPU servers under my control - 1st, 2nd and 3rd-gen. I can enable both SEV and SEV-ES in the bios and activate via grub entries - that all seems to work as expected, e.g. an EPYC ROME CPU with memory encryption enabled in the bios:

andrew@skywalker:~$ sudo dmesg | grep -i sev
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-6.1.0-25-amd64 root=/dev/mapper/skywalker–vg-root ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.sev_es=1
[ 0.016664] Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-25-amd64 root=/dev/mapper/skywalker–vg-root ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.sev_es=1
[ 100.804918] ccp 0000:4a:00.1: sev enabled
[ 100.856562] ccp 0000:4a:00.1: firmware: direct-loading firmware amd/amd_sev_fam17h_model31h.sbin
[ 100.882669] ccp 0000:4a:00.1: SEV firmware update successful
[ 100.955501] ccp 0000:4a:00.1: SEV API:0.24 build:20
[ 101.123351] SEV enabled (ASIDs 256 - 509)
[ 101.123366] SEV-ES enabled (ASIDs 1 - 255)

So, if I set security.sev=true in an incus vm (be it from iso or images:), I can boot it up and drop to a shell via the agent, I can see the expected:

root@SEV-ES:~# dmesg | grep -i sev
[ 0.067721] Memory Encryption Features active: AMD SEV
[ 1.813811] systemd[1]: Hostname set to SEV-ES.
[ 2.688072] SVM: KVM is unsupported when running as an SEV guest

So far so good. Now if I reset security.sev and “instead” enable security.sev.policy.es=true & restart the VM, I get the following (unexpected) output from the agent terminal:

andrew@skywalker:~$ incus config set SEV-ES security.sev=
andrew@skywalker:~$ incus config set SEV-ES security.sev.policy.es=true
andrew@skywalker:~$ incus start SEV-ES
andrew@skywalker:~$ incus exec SEV-ES bash
root@SEV-ES:~# dmesg | grep -i sev
[ 1.891571] systemd[1]: Hostname set to SEV-ES

Nothing about memory encryption?

So I tried also setting both security.sev=true and security.sev.policy.es=true and the VM fails to boot:

andrew@skywalker:~$ incus config set SEV-ES security.sev=true
andrew@skywalker:~$ incus config set SEV-ES security.sev.policy.es=true
andrew@skywalker:~$ incus start SEV-ES
Error: Failed setting reboot action: Failed setting actions: Monitor is disconnected
Try incus info --show-log SEV-ES for more info
andrew@skywalker:~$ incus info --show-log SEV-ES
Name: SEV-ES
Status: STOPPED
Type: virtual-machine
Architecture: x86_64
Created: 2024/10/05 09:44 EDT
Last Used: 2024/10/05 13:41 EDT

Log:

cpus are not resettable, terminating

Googling the above output gives me little additional information and I quickly get a little lost.

I believed that security.sev=true gives memory only encryption, and security.sev.policy.es=true gives both memory and register encryption (based on googling), and to me that seems logical. Is my understanding off or am I misinterpreting the (lack of) output?

There’s not much to find on this via google - an old lxd 5.13 release/video (useful, thanks Stephane!) and a little in the docs. Memory encryption itself seems very easy to implement via incus and it is certainly more than I will ever need, I am just a little surprised at the output I got via a vm with security.sev.policy.es=true (i.e. nothing evident inside the vm) and the fact that it failed to start with security.sev=true and security.sev.policy.es=true.

I did all of this with Debian 12 vm’s. Whether installed via iso or from images:, I got the same output.

Can anyone point me to a better understanding of this, and what if anything I am doing wrong; why does (i) security.sev.policy.se=true seem to turn memory (and register) encryption off inside the vm (ii) setting security.sev=true works as expected (i.e. memory only encryption), and (iii) setting both to true results in vm failing to start?

THANK YOU

Andrew

Yeah, you do need security.sev=true for security.sev.policy.es=true to be meaningful, but that seems to be hitting some interesting issue within QEMU…

We’re waiting on a grant here to have additional test systems that we can do daily AMD SEV testing on as our current support was implemented as a one off using a loaned system.

I do have access to a number of AMD EPYC systems but they are production systems where SEV is currently disabled…

1 Like

Thanks for the fast reply, as usual! I am just glad it wasn’t me this time (that’s a first I think…). :slight_smile:

I’d be happy to do some beta-testing if it’s useful for your development efforts.

Hi sir.

Has there been any deliberate change to EPYC CPU securirty.sev logic in the latest incus release? I ask because for some strange reason I have lost the ability to launch a vm with security.sev=true - which differs from incus 6.7 (maybe 6.6 - I can’t honestly remember precisely). E.g. this on an AMD Milan platform running Bookworm:

andrew@obiwan:~$ sudo journalctl -b | grep -ie encrypted -ie sev
Dec 17 23:22:07 obiwan kernel: Command line: BOOT_IMAGE=/vmlinuz-6.1.0-28-amd64 root=/dev/mapper/obiwan--vg-root ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.sev_es=1
Dec 17 23:22:07 obiwan kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-28-amd64 root=/dev/mapper/obiwan--vg-root ro mem_encrypt=on kvm_amd.sev=1 kvm_amd.sev_es=1
Dec 17 23:22:07 obiwan kernel: Key type encrypted registered
Dec 17 23:22:08 obiwan kernel: ccp 0000:22:00.1: sev enabled
Dec 17 23:22:08 obiwan kernel: ccp 0000:22:00.1: firmware: direct-loading firmware amd/amd_sev_fam19h_model01h.sbin
Dec 17 23:22:08 obiwan kernel: ccp 0000:22:00.1: SEV firmware update successful
Dec 17 23:22:08 obiwan kernel: ccp 0000:22:00.1: SEV API:1.55 build:21
Dec 17 23:22:08 obiwan kernel: SEV enabled (ASIDs 254 - 509)
Dec 17 23:22:08 obiwan kernel: SEV-ES enabled (ASIDs 1 - 253)

Everything looks enabled on the host:-

incus launch images:debian/12 t1 --vm -c security.sev=true

(wait for more than enough time for the machine to init, then:)

andrew@obiwan:~$ incus shell t1
Error while executing alias expansion: incus exec t1 -- su -l
Error: VM agent isn't currently running

That’s an interesting error that google doesn’t recognize. Also:

andrew@obiwan:~$ incus info t1
Name: t1
Status: RUNNING
Type: virtual-machine
Architecture: x86_64
PID: 3509142
Created: 2024/12/20 10:33 EST
Last Used: 2024/12/20 10:34 EST
Started: 2024/12/20 10:33 EST

Resources:
  Processes: -1
  Disk usage:
    root: 11.62KiB
  Network usage:
    eth0:
      Type: broadcast
      State: UP
      Host interface: tapd681e66b
      MAC address: 00:16:3e:a8:cc:65
      MTU: 1500
      Bytes received: 263B
      Bytes sent: 0B
      Packets received: 1
      Packets sent: 0
      IP addresses:

Incus list shows the instance running, but it’s unreachable (no network). Unsetting security.sev and it works, but with an odd hostname so something went weird:

andrew@obiwan:~$ incus stop t1 -f && incus config set t1 security.sev=false && incus start t1
andrew@obiwan:~$ incus shell t1
root@distrobuilder-bee561ad-ba8e-4965-8824-c92c64e3b0ab:~# 

And it’s actually changed the /etc/hostname:

root@distrobuilder-bee561ad-ba8e-4965-8824-c92c64e3b0ab:~# cat /etc/hostname
distrobuilder-bee561ad-ba8e-4965-8824-c92c64e3b0ab

It’s as if setting security.sev is somehow changing the very way incus installs the OS?

Obviously that’s very unexpected. Looking at the firmware screen of the VM after I reset .sev=false shows nothing immediately obvious to my two brain cells. Secureboot is still enabled, the drive is listed as normal. Setting security.secureboot=false at launch gives the same behavior, so it doesn’t seem to be that.

The running vm, even though inaccessible, is working a CPU core @100% so it’s trying to do something very quickly.

Any pointers appreciated. I don’t rule out I have done something dumb, but I did get the same behavior off another Epyc Naples server, so if it’s me, I have broken several servers (rare but not impossible - I am gifted). :slight_smile:

V/R and THANK YOU

Andrew

Nope, we haven’t changed anything on our side that should affect this.
My guess is that it may be a kernel change on the host or in the guest maybe?

Even on the QEMU front, I believe we picked up a bugfix release on their side (9.0.2) but haven’t done a significant version bump yet (9.2.0 is out but is causing a few issues).

1 Like