Re: [EXTERNAL] Re: [PATCH 4/4] kvm: svm: Support KVM_SEV_SNP_PAGE_TYPE_VMSA at SNP_LAUNCH_UPDATE

[Jethro Beekman]

On 2026-06-23 23:43, Sean Christopherson wrote:
> On Tue, Jun 23, 2026, Jethro Beekman wrote:
>> On 2026-06-23 16:51, Jon Lange wrote:
>>> On Tuesday, June 23, 2026 6:40 AM, Sean Christopherson wrote:
>>>> On Wed, Jun 17, 2026, Jörg Rödel wrote:
>>>>> On Wed, Jun 17, 2026 at 06:37:52AM -0700, Sean Christopherson wrote:
>>>>>> Ok, so it took us a few times to learn our lesson.  I still don't see that as a
>>>>>> strong argument for new uAPI, especially not for VMSA pages.  I am very firmly
>>>>>> of the opinion that letting anything but the host kernel configure the VMSA is
>>>>>> beyond stupid, but unfortunately we're stuck with AP_CREATION.  Expanding that
>>>>>> surface has a very, very, VERY high bar to get over.
>>>>>
>>>>> The strongest argument in my view (and the main reason we are doing this) is
>>>>> actually the predictable launch measurement. On SEV-SNP this is a requirement
>>>>> to use platform VM-identity features like the ID Block.
>>>>
>>>> And I'm saying that unless KVM *can't* provide a predictable launch measurement,
>>>> which AIUI isn't the case, then the launch measurement *must* be stable across
>>>> kernels because it's part of KVM's ABI.  So as I see it, the issue isn't that
>>>> KVM is inherently unpredictable, it's that we lack tests to validate a thorny,
>>>> subtle piece of KVM's ABI.
>>>
>>> Joerg is suggesting that we need a launch measurement that is stable not
>>> just across multiple launches on the same system, but across multiple
>>> hypervisors.
>>
>> If this is now suddenly an acceptable argument, please also merge https://lkml.org/lkml/2021/4/12/625
> 
> No, that's not how this works.  Dave and Jarkko both have unanswered questions
> regarding the use case.  Answer their questions, and I'm confident you'll get
> traction.
> 
>  : I don't believe we necessarily *WANT* or need Linux to support "all
>  : possible ECREATE, EADD, EEXTEND, EINIT sequences".  Yet, it's what is
>  : being used to justify this series without any other justification.
>  : 
>  : It's going to be a different story if you bring me a real enclave that
>  : *REALLY* wants to do this for good reasons.
> 
> and
> 
>  : What specifically are you referring as the "rest of the world"?
>  : 
>  : That would be mean that there is reviewable workload "out there".
> 
> The start of that thread is *exactly* what's playing out here.  The big difference,
> and why this one's likely getting a different result, is that Jon provided a very
> thorough explanation of exactly what use case Joerg and company want to support.
> The only "assumed knowledge" is why it's desirable for the measurement to be stable
> across hypervisors, but I'm comfortable stitching that together on my own.
> 
> In other words, they aren't asking KVM to support every possible way/time a VMSA
> could be associated with a vCPU, they're asking to extend KVM to support a concrete
> use case, with meaningful real world impact.  In fact, I actually think this series
> is *too* narrowly focused on their use case.
> 
> FWIW, KVM_TDX_INIT_MEM_REGION has almost the exact same ABI that SGX has: pages
> contents are measured immediately after they're added.

Sorry, the argument from Jon/Joerg is no different than the one we made years ago for SGX.

It was previously made abundantly clear that it's the kernel maintainers's stance that it's sufficient to offer a UAPI that allows the creation of a Linux-specific subset of enclaves with a stable measurement encompassing largely the enclave functionality available in the hardware. Or said another way: if you can take your enclave and modify it to work with Linux, albeit with a different measurement, that is acceptable. KVM-SNP is currently at that state: it is currently completely possible to load VMs that were designed with the current Linux VMSA in IGVM format.

A UAPI that allows creation of all architecturally-valid enclaves for purposes of measurement portability was stated as an explicit non-goal. As this is the only stated purpose of this patch set, it should also not be accepted.

--
Jethro Beekman | CTO | Fortanix

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature