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? 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. - Naveen
