Bug 2040652
| Summary: | RFE: support a way to acquire/extract/construct the initial VMSA content for AMD SEV vCPUs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Daniel Berrangé <berrange> |
| Component: | sevctl | Assignee: | Tyler Fanelli <tfanelli> |
| Status: | CLOSED ERRATA | QA Contact: | zixchen |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.1 | CC: | coli, crobinso, jferlan, jinzhao, juzhang, virt-maint, zhguo |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | 9.1 | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | sevctl-0.3.0-4.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 10:31:18 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2085085 | ||
| Bug Blocks: | |||
This has been discussed in the context of the ConfVirt project, see https://issues.redhat.com/browse/KVMUSRSPC-80 Didn't create a RHEL bug partially because we were lacking details and of course the resource that had the most knowledge left Red Hat. I'll move to sevctl for now and assign to Tyler. These 3 options seems to be the most viable and preferred: - Provide a reference implementation tool based on the documentation for constructing the VMSA content - Provide a supported mechanism in the kernel for dumping the VMSA content - Provide a supported mechanism in QEMU for dumping the VMSA content (unclear it if it technically possible - possibly SEV 'debug' policy bit would allow it) If a sevctl command were to be created for this, I imagine there would still be some support needed (an API?) in qemu or kvm for extracting this that sevctl would use. Is this a correct assumption? upstream code posted: https://github.com/virtee/sevctl/pull/18 AIUI, having a sevctl vmsa dump command will eventually be resolved as part of rebase to new sevctl release Changes have been merged upstream (reverse time order): https://github.com/virtee/sevctl/commit/b98141e2bb85a1459b952a9e2a8e78cda3cf838b (import vmsa from sev crate) https://github.com/virtee/sev/commit/8e032283b404ff919701794622611800061a4a60 (move vmsa extractions into sev crate) https://github.com/virtee/sevctl/commit/b08c571b888a4437860ca3316f4991a052220d04 (vmsa update command) https://github.com/virtee/sevctl/commit/379230bea58c88837a1deb11a34d77d4165a77b7 (vmsa build command) Moving this bug to POST and awaiting the sevctl rebase Test with sevctl-0.3.0-4.el9, sevctl vmsa passed.
Version:
sevctl-0.3.0-4.el9
kernel-5.14.0-121.el9.x86_64
# cat /proc/cpuinfo|grep -i stepping|head -n 1
stepping : 1
# cat /proc/cpuinfo|grep -i mode|head -n 1
model : 1
# cat /proc/cpuinfo|grep -i family|head -n 1
cpu family : 25
# sevctl vmsa build NEW-VMSA0.bin --userspace qemu --family 25 --stepping 1 --model 1 --firmware /usr/share/edk2/ovmf/OVMF.amdsev.fd --cpu 0
# echo $?
0
# sevctl vmsa show NEW-VMSA0.bin
{
"es": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"cs": {
"selector": 61440,
"attrib": 155,
"limit": 65535,
"base": 4294901760
},
"ss": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"ds": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"fs": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"gs": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"gdtr": {
"selector": 0,
"attrib": 0,
"limit": 65535,
"base": 0
},
"ldtr": {
"selector": 0,
"attrib": 130,
"limit": 65535,
"base": 0
},
"idtr": {
"selector": 0,
"attrib": 0,
"limit": 65535,
"base": 0
},
"tr": {
"selector": 0,
"attrib": 139,
"limit": 65535,
"base": 0
},
"reserved_1": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"cpl": 0,
"reserved_2": [
0,
0,
0,
0
],
"efer": 4096,
"reserved_3": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"xss": 0,
"cr4": 64,
"cr3": 0,
"cr0": 16,
"dr7": 1024,
"dr6": 4294905840,
"rflags": 2,
"rip": 65520,
"reserved_4": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"rsp": 0,
"reserved_5": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"rax": 0,
"star": 0,
"lstar": 0,
"cstar": 0,
"sfmask": 0,
"kernel_gs_base": 0,
"sysenter_cs": 0,
"sysenter_esp": 0,
"sysenter_eip": 0,
"cr2": 0,
"reserved_6": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"g_pat": 1974748653749254,
"dbgctl": 0,
"br_from": 0,
"br_to": 0,
"last_excp_from": 0,
"last_excp_to": 0,
"reserved_7": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"spec_ctrl": 0,
"reserved_7b": [
0,
0,
0,
0
],
"pkru": 0,
"reserved_7a": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"reserved_8": 0,
"rcx": 0,
"rdx": 10489617,
"rbx": 0,
"reserved_9": 0,
"rbp": 0,
"rsi": 0,
"rdi": 0,
"r8": 0,
"r9": 0,
"r10": 0,
"r11": 0,
"r12": 0,
"r13": 0,
"r14": 0,
"r15": 0,
"reserved_10": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"sw_exit_code": 0,
"sw_exit_info_1": 0,
"sw_exit_info_2": 0,
"sw_scratch": 0,
"reserved_11": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"xcr0": 1,
"valid_bitmap": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"x87_state_gpa": 0
}
[# echo $?
0
# sevctl vmsa update NEW-VMSA0.bin --userspace qemu --family 25 --stepping 1 --model 1 --firmware /usr/share/edk2/ovmf/OVMF.amdsev.fd --cpu 1
# echo $?
0
# sevctl vmsa show NEW-VMSA0.bin
{
"es": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"cs": {
"selector": 61440,
"attrib": 155,
"limit": 65535,
"base": 8388608
},
"ss": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"ds": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"fs": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"gs": {
"selector": 0,
"attrib": 147,
"limit": 65535,
"base": 0
},
"gdtr": {
"selector": 0,
"attrib": 0,
"limit": 65535,
"base": 0
},
"ldtr": {
"selector": 0,
"attrib": 130,
"limit": 65535,
"base": 0
},
"idtr": {
"selector": 0,
"attrib": 0,
"limit": 65535,
"base": 0
},
"tr": {
"selector": 0,
"attrib": 139,
"limit": 65535,
"base": 0
},
"reserved_1": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"cpl": 0,
"reserved_2": [
0,
0,
0,
0
],
"efer": 4096,
"reserved_3": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"xss": 0,
"cr4": 64,
"cr3": 0,
"cr0": 16,
"dr7": 1024,
"dr6": 4294905840,
"rflags": 2,
"rip": 45060,
"reserved_4": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"rsp": 0,
"reserved_5": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"rax": 0,
"star": 0,
"lstar": 0,
"cstar": 0,
"sfmask": 0,
"kernel_gs_base": 0,
"sysenter_cs": 0,
"sysenter_esp": 0,
"sysenter_eip": 0,
"cr2": 0,
"reserved_6": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"g_pat": 1974748653749254,
"dbgctl": 0,
"br_from": 0,
"br_to": 0,
"last_excp_from": 0,
"last_excp_to": 0,
"reserved_7": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"spec_ctrl": 0,
"reserved_7b": [
0,
0,
0,
0
],
"pkru": 0,
"reserved_7a": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"reserved_8": 0,
"rcx": 0,
"rdx": 10489617,
"rbx": 0,
"reserved_9": 0,
"rbp": 0,
"rsi": 0,
"rdi": 0,
"r8": 0,
"r9": 0,
"r10": 0,
"r11": 0,
"r12": 0,
"r13": 0,
"r14": 0,
"r15": 0,
"reserved_10": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"sw_exit_code": 0,
"sw_exit_info_1": 0,
"sw_exit_info_2": 0,
"sw_scratch": 0,
"reserved_11": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"xcr0": 1,
"valid_bitmap": [
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0,
0
],
"x87_state_gpa": 0
}
# echo $?
0
Since sevctl-0.3.0-4.el9 is already tested, move this to VERIFIED Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (sevctl bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8171 |
Description of problem: In order to validate the measurement of a guest configured with AMD SEV-ES, the guest owner needs to know the expected VMSA content for the boot CPU and non-boot CPUs. There is no supported way to extract this content today. Users have hacked this in the past either - Patching the kernel to hexdump into dmesg https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg02830.html - Hooking into the kerenl with systemtap https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg01362.html Neither of these are viable for RHEL customers and so we need to figure out a better option. There are various approaches - Red Hat publish the VMSA content as blobs for each RHEL update - Provide documentation on how to construct the VMSA content based on AMD CPU specifications and OVMF impl - Provide a reference implementation tool based on the documentation for constructing the VMSA content - Provide a supported mechanism in the kernel for dumping the VMSA content - Provide a supported mechanism in QEMU for dumping the VMSA content (unclear it if it technically possible - possibly SEV 'debug' policy bit would allow it) This bug is reported against QEMU, but depending on which of the above approaches is most viable, it can move to another component. QEMU is just picked as an initial placeholder