Re: [PATCH v3 2/2] KVM: SEV: Configure "ALLOWED_SEV_FEATURES" VMCB Field

Sean Christopherson
2025-02-18T16:38:57Z

On Mon, Feb 17, 2025, Naveen N Rao wrote:
> On Thu, Feb 13, 2025 at 04:55:13PM -0800, Sean Christopherson wrote:
> > On Thu, Feb 13, 2025, Kim Phillips wrote:
> > > On 2/11/25 3:46 PM, Sean Christopherson wrote:
> > > > On Mon, Feb 10, 2025, Tom Lendacky wrote:
> > > > > On 2/7/25 17:34, Kim Phillips wrote:
> >
> > Third, letting userspace opt-in to something doesn't necessarily mean giving
> > userspace full control. Which is the entire reason I asked the question about
> > whether or not this can break userspace. E.g. we can likely get away with only
> > making select features opt-in, and enforcing everything else by default.
> >
> > I don't think RESTRICTED_INJECTION or ALTERNATE_INJECTION can work without KVM
> > cooperation, so enforcing those shouldn't break anything.
> >
> > It's still not clear to me that we don't have a bug with DEBUG_SWAP. AIUI,
> > DEBUG_SWAP is allowed by default. I.e. if ALLOWED_FEATURES is unsupported, then
> > the guest can use DEBUG_SWAP via SVM_VMGEXIT_AP_CREATE without KVM's knowledge.
>
> In sev_es_prepare_switch_to_guest(), we save host debug register state
> (DR0-DR3) only if KVM is aware of DEBUG_SWAP being enabled in the guest
> (via vmsa_features). So, from what I can tell, it looks like the guest
> will end up overwriting host state if it enables DEBUG_SWAP without
> KVM's knowledge?

Yes, that's what I'm effectively "asking".

> Not sure if that's reason enough to enforce ALLOWED_SEV_FEATURES for
> DEBUG_SWAP :)
>
> If ALLOWED_SEV_FEATURES is not supported, we may still have to
> unconditionally save the host DR0-DR3 registers.

Yes, that's my understanding of the situation. If the CPU supports DEBUG_SWAP,
KVM must assume the guest can enable it without KVM's knowledge.