Re: [PATCH 1/4] KVM: nSVM: Reject KVM_SET_NESTED_STATE if L1 has EFER.LMA=1 && EFER.LME=0

[Paolo Bonzini <pbonzini@redhat.com>]

On 8/27/26 19:33, Sean Christopherson wrote:
>>> If anything is wrong, it's the CR0.PG check.  Presumably that got carried forward
>>> from commit c0725420cfdc ("KVM: SVM: Add helper functions for nested SVM").  I
>>> don't see anything in the APM that requires paging to be enabled, and nothing in
>>> that ancient series points at concrete documentation either.
>>
>> Oh yeah you're right, for some reason I thought it was paging not
>> protected mode. Well then, it seems like
>> nested_svm_check_permissions() is also incorrectly checking paging as
>> well, seems like both checks are incorrect? Also, I don't see anything
>> in the APM about checking RFLAGS.VM before VMRUN.
> 
> Presumably it's covered by the !PROTECTED_MODE clause.
> 
>    IF ((MSR_EFER.SVME == 0) || (!PROTECTED_MODE))  // This instruction can only be executed in protected
>      EXCEPTION [#UD]                               // mode with SVM enabled
> 
> Section "1.3.4 Legacy Modes" describes "Protected Mode" and "Virtual-8086 Mode"
> as separate submodes.  And the tables for most instructions differentiate between
> Real, Virtual 8086, and Protected modes when enumerating exceptions.

Right.

As to CR0.PG it does seem incorrect to check it entirely, however note 
that there is this too (15.25.3 Enabling Nested Paging):

	If VMRUN is executed with hCR0.PG cleared to zero and
	NP_ENABLE set to 1, VMRUN terminates with
	#VMEXIT(VMEXIT_INVALID)

which would have to be checked in nested_vmcb_check_controls().

>> If the goal here is to keep the checks here consistent with
>> nested_svm_check_permissions(), aside from the new EFER check, then
>> maybe we should also check CPL here?
Perhaps, but nested_svm_check_permissions() is not reached with CPL=0 
because the #GP overrides the interception (table 15-7, instruction 
intercepts).  The same should be true about EFLAGS.VM=1.

Paolo