On Fri, Apr 26, 2024 at 05:10:10PM -0700, Sean Christopherson wrote: > On Fri, Apr 26, 2024, Michael Roth wrote: > > On Fri, Apr 26, 2024 at 12:57:08PM -0700, Sean Christopherson wrote: > > > On Fri, Apr 26, 2024, Michael Roth wrote: > > > What is "management"? I assume its some userspace daemon? > > > > It could be a daemon depending on cloud provider, but the main example > > we have in mind is something more basic like virtee[1] being used to > > interactively perform an update at the command-line. E.g. you point it > > at the new VLEK, the new cert, and it will handle updating the certs at > > some known location and issuing the SNP_LOAD_VLEK command. With this > ^^^^^^^^^^^^^^^^^^^ > > interface, it can take the additional step of PAUSE'ing attestations > > before performing either update to keep the 2 actions in sync with the > > guest view. > > ... > > > > without having to bounce through the kernel. It doesn't even require a push > > > model, e.g. wrap/redirect the certs with a file that has a "pause" flag and a > > > sequence counter. > > > > We could do something like flag the certificate file itself, it does > > sounds less painful than the above. But what defines that spec? > > Whoever defines "some known location". And it doesn't need to be a file wrapper, "some known location" is a necessary and simple parameter controlled by the cloud provider, so it's easy to make a tool like virtee aware of those what those parameters should be for any particular environment. But it's not easy to make it aware of a particular providers internal way of synchronizing guests and certs access. We'd be somewhat dependent of those providers either providing hooks to allow for better integration, which is "work" that might encourage them to just brew their own solutions, versus... Providing a simple reference scheme that's clearly defined, and easily adoptable across the board, which is "less work", and makes adoption of common tools/libraries SNP/certs/key management easier because we don't need to directly involve a provider's internal guest management mechanisms into those tools. > e.g. put the cert in a directory along with a lock. Actually, IIUC, there doesn't > even need to be a separate lock file. I know very little about userspace programming, > but common sense and a quick search tells me that file locks are a solved problem. > > E.g. it took me ~5 minutes of Googling to come up with this, which AFAICT does > exactly what you want. > > touch ~/vlek.cert > ( > flock -e 200 > echo "Locked the cert, sleeping for 10 seconds" > sleep 10 > echo "Igor, it's alive!!!!!!" > ) 200< vlek.cert > > touch ~/vlek.cert > ( > flock -s 201 > echo "Got me a shared lock, no updates for you!" > ) 201< vlek.cert > Hmm... I did completely miss this option. But I think there are still some issues here. IIUC you're suggesting (for example): "Management": a) writelock vlek.cert b) perform SNP_LOAD_VLEK and update vlek.cert contents c) unlock vlek.cert "QEMU": a) readlock vlek.cert b) copy cert into guest buffer c) unlock vlek.cert The issue is that after "QEMU" unlocks and return the cert to KVM we'll have: "KVM" a) return from EXT_GUEST_REQ exit to userspace b) issue the attestation report to firmware c) return the attestation report and cert to the guest Between a) and b), "Management" can complete another entire update, but the cert that it passes back to the guest will be stale relative to the key used to sign the attestation report. If we need to take more time to explore other options it's not absolutely necessary to have the kernel solve this now. But every userspace will need to solve it in some way so it seemed like it might be nice to have a simple reference implementation to start with. -Mike
