Re: [PATCH v4 4/7] KVM: VMX: Implement LASS violation check

[Sohil Mehta <sohil.mehta@intel.com>]

On 8/5/2026 6:52 PM, sashiko-bot@kernel.org wrote:
>> @@ -8604,6 +8604,53 @@ gva_t vmx_get_untagged_addr(struct kvm_vcpu *vcpu, gva_t gva, unsigned int flags
>>  	return (sign_extend64(gva, lam_bit) & ~BIT_ULL(63)) | (gva & BIT_ULL(63));
>>  }
>>  
>> +bool vmx_is_lass_violation(struct kvm_vcpu *vcpu, gva_t gva,
>> +			   unsigned int size, unsigned int flags)
>> +{
>> +	const bool is_supervisor_address = !!(gva & BIT_ULL(63));
>> +	const bool implicit_supervisor = !!(flags & X86EMUL_F_IMPLICIT);
>> +	const bool fetch = !!(flags & X86EMUL_F_FETCH);
>> +
>> +	if (!kvm_is_cr4_bit_set(vcpu, X86_CR4_LASS) || !is_long_mode(vcpu))
>> +		return false;
> 
> [Severity: High]
> Should this check use is_64_bit_mode() instead of is_long_mode()?
> 

No, LASS applies only to IA-32e mode. So, I think the is_long_mode()
check here is correct.

> If a guest is in compatibility mode with LASS and SMAP enabled, a compatibility
> mode application might trigger an interrupt resulting in an implicit supervisor
> access to the IDT or TSS. Since compatibility-mode linear addresses are 32-bit,
> bit 63 is always 0.
> 

AFAIU, in IA-32e compatiblity mode, all the bases (GDTR, IDTR, LDTR, and
TR) hold the full 64-bit address. So, there isn't any truncation and an
implicit supervisor access should have bit 63 present (set as 1).


> Does using is_long_mode() cause the hypervisor to erroneously flag these as
> LASS violations for supervisor mode, breaking 32-bit execution?
> 

...

>> +
>> +	/*
>> +	 * LASS enforcement for supervisor-mode data accesses depends on SMAP
>> +	 * being enabled, and like SMAP ignores explicit accesses if RFLAGS.AC=1.
>> +	 */
>> +	if (!fetch) {
>> +		if (!kvm_is_cr4_bit_set(vcpu, X86_CR4_SMAP))
>> +			return false;
>> +
>> +		if (!implicit_supervisor && (kvm_get_rflags(vcpu) & X86_EFLAGS_AC))
>> +			return false;
>> +	}
> 
> [Severity: High]
> Does LASS enforcement for supervisor-mode instruction fetches require a check
> for SMEP being enabled here?
> > According to the architecture specification, LASS applies to supervisor
> instruction fetches only if SMEP is enabled, similar to how it requires
> SMAP for data accesses.
> 

No, an SMEP check is not needed during LASS enforcement. The SDM
specifically states that:

"LASS enforces the equivalent of supervisor-mode execution prevention
regardless of the setting of CR4.SMEP[bit 17]"

"A supervisor-mode instruction fetch causes a LASS violation if it would
accesses a linear address of which bit 63 is 0. (Unlike paging, this
behavior of LASS applies regardless of the setting of CR4.SMEP.)"

So, an SMEP check would actually be wrong.

> If a guest OS running in 64-bit mode with CR4.LASS = 1 and CR4.SMEP = 0
> performs a supervisor-mode instruction fetch from a user-mode address,
> will omitting a kvm_is_cr4_bit_set(vcpu, X86_CR4_SMEP) check when fetch
> is true cause a spurious #GP fault to be injected?
>