can a guest-owner verify svsm? #15
Comments
Both the SVSM contents and the BIOS/firmware contents, are measured. You can instrument Qemu with error_report() calls around the calls to sev_snp_launch_update() to see everything that is measured and the VMPL level at which they are measured. For example:
And the SVSM BSP is measured at VMPL0 in KVM during LAUNCH_FINISH processing. |
yes, but the guest is running at VMPL1, so it can't request a report for VMPL0. |
maybe it's just me misunderstanding how this works, but isnt the measurement a single hash? so if the CSP provides OVMF, there's no way for the user to verify the svsm. a change in the svsm is indistinguishable from a change in OVMF so the guest owner still has no idea if its their svsm |
The "at VMPL0" or "at VMPL1" is purely related to what the VMPL permission flags get set to when the pages are measured. Even though the guest is running at VMPL1 it gets the measurement for the full launch, which will contain the SVSM info. The report will just contain VMPL1 for the level that the report was issued. |
yes, see the comment after that. the measurement from that point is already mixed with OVMF, so doesn't verify the svsm itself. Or it would only in the rare scenario that the guest owner controls the firmware, in which case i'm not sure why we need different permission levels? should svsm perhaps have an interface so that the lower levels can request an attestation ? |
It's likely that the CSP will also provide the SVSM, too. But if the CSP allows you to supply the SVSM, then wouldn't the CSP also likely allow you to supply the OVMF as well? But if they don't, then, yes, you wouldn't be able to which changed. |
You still need something at a higher VMPL to provide security for, as an example, a vTPM.
I'm not sure what that will tell you different than requesting an attestation at the current VMPL. But, if you want to attest a specific service, like a vTPM, that is likely to have a protocol function to request an attestation that would include the vTPM EK and SRK public keys within the attestation report data (this is being talked about currently on the linux-coco mailing list). |
|
OVMF contains bringup that's specific to the CSP, so it's very inconvenient to ask the customer to verify each new revision. see this specific comment for details (google/go-sev-guest#20 (comment)) we're a much smaller CSP than google, so we could do that, but it's unlikely that this will become a standard. i was hoping that the guest owner could supply something that runs at higher privilege than OVMF, that is able to make policy decisions purely on page content, rather than having to understand the underlying CSP infrastructure. but i'm unsure if this is possible at all? the docs are very confusing, specifically this sentence at page 43
this indicates that a report for VMPL0 would be different than for VMPL1, but the SP only has a single measurement, right? |
It would be different only in the sense of the VMPL level identified in the report. The measurement calculated at launch will be the same regardless of the VMPL making the attestation request. The VMPL level is there so that you can know which level created the report. Since the SVSM erases the VMPCK0 key (which represents VMPL0), then the guest can never generate an attestation report that it declares comes from VMPL0. Only the SVSM would be able to generate an attestation report that reports it is from VMPL0. |
this makes sense. thanks for all the explanations. If i understand correctly, the only way to solve the specific customer demand is to have the svsm communicate with the guest owner prior to loading OVMF. similar to how attestation worked pre-snp. is that something we could specify in the spec (GHCB maybe?) or should we go away and implement something proprietary? |
I'm not sure what that would involve or how we could get through that. With Qemu at least, OVMF is mapped as pflash and mapped read-only. If the SVSM was to read and load the BIOS it would have to kind of override that pflash behavior while "loading" the BIOS. Would an attestation report with the hash of the loaded BIOS for the report data be enough to be able to discern changes in OVMF vs SVSM? These would be good questions to bring up on the mailing list (see last paragraph). As for the SVSM, it will definitely have dependencies on how it interacts with the hypervisor - considering it will be needed to perform live migration. So I'm not sure you would really want customers to be able to supply their own versions. But that's completely up to you. You might want to sign-up for the linux-coco mailing list (https://subspace.kernel.org/lists.linux.dev.html) where we are discussing SVSM-related stuff, including the first version of the SVSM specification (though mostly the focus has been on vTPM right now). |
there's a fundamental thing i still don't understand about SNP, and i was assuming SVSM solves that, but i cant figure out how.
in a cloud environment, a guest owner can typically not supply their own firmware (OVMF, vTPM)
and the common solution appears to be that the identityblock is signed by the CSP,
and the guest owner verifies that that signature came from a known good CSP key.
i was assuming with the svsm stack, it's actually svsm that gets attested, but it looks like its still the entire firmware.
even tho svsm has higher privilege than the next firmware, the guest owner can't really verify that a specific expected version of svsm was loaded.
did i fundamentally misunderstand what problem svsm actually solves?
The text was updated successfully, but these errors were encountered: