> How do we avoid this? > 1. We can advise that the guest parses the certificate and the > attestation report to determine if their TCBs match expectations and > retry if they're different because of a bad luck data race. > 2. We can add a new global lock that KVM holds from CCP similar to > sev_cmd_lock to sequentialize req_certs, attestation reports, and > SNP_COMMIT. KVM releases the lock before returning to the guest. > SNP_COMMIT must now hold this lock before attempting to grab the sev_cmd_lock. > > I think probably 2 is better. > Actually no, we shouldn't hold a global lock and only release it if user space returns to KVM in a specific way, unless we can ensure it will be unlocked safely on fd close. -- -Dionna Glaze, PhD, CISSP, CCSP (she/her)
