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.
