Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VMSA_GPA = 0xFFFFFFFFF000 is 48-bit, confused.... #3

Open
JustPlay opened this issue Jul 17, 2022 · 3 comments
Open

VMSA_GPA = 0xFFFFFFFFF000 is 48-bit, confused.... #3

JustPlay opened this issue Jul 17, 2022 · 3 comments

Comments

@JustPlay
Copy link

https://github.com/IBM/sev-snp-measure/blob/90f6e59831d20e44d03d5ee19388f624fca87291/sevsnpmeasure/gctx.py#L40

in the code, VMSA_GPA = 0xFFFFFFFFF000, but 0xFFFFFFFFF000 is 48-bits, not 52-bits

when launch sev-snp vm, we use cbitpos=51,reduced-phys-bits=1, so i think it use 51-bit (0-50) physical address space, with cbit=1, so should VMSA_GPA = 0xFFFFFFFFFF000 ?

@dubek
Copy link
Member

dubek commented Jul 18, 2022

I agree, this value is only 48-bits. I also see the same value in snp-digest-rs:

https://github.com/slp/snp-digest-rs/blob/0e5a787e99069944467151101ae4db474793d657/src/main.rs#L86

Note that with the current value I'm able to successfully verify launch digests of SNP guests, so the question is why the PSP is using this 48-bit value when filling the PAGE_INFO (SNP spec table 67).

Section 8.17.2.2 of the SNP spec says:

• GPA: The gPA of the 4 KB page. The firmware uses the RMP.GPA of the page.

Maybe the spec should be a bit clearer.

And in the host kernel, the RMP setting of the VMSA page is set with gpa = (u64)-1 (second argument in this call):

https://github.com/AMDESE/linux/blob/3a15da8647b99d147ed3ae8daf7cfdb19b20d83c/arch/x86/kvm/svm/sev.c#L2188

@tlendacky
Copy link

Section 8.17.2 provides some further detail. The input GPA must be page aligned (CMDBUF_SNP_LAUNCH_UPDATE structure, byte offset 0x10, bits 11:0 must be zero) and the second from the last paragraph of that section states "the guest physical address space is limited according to CPUID Fn80000008_EAX and thus the GPAs used by the firmware in measurement calculation are equally limited".

Given that information and that CPUID Fn80000008_EAX[PhysAddrSize]=0x30:
-1 == 0xFFFFFFFFFFFFFFFF => 0xFFFFFFFFF000 is used as the VMSA GPA during measuring.

I think the hypervisor patches should be made a bit clearer by performing this actual transformation of the supplied address.

@tlendacky
Copy link

Sorry, I confused the SPA and the GPA in the first part of that last response. The spec should probably be updated to clarify that the GPA will be page aligned and thus bits 11:0 will be zero.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants