Re: [PATCH 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect Emulation of Illegal Exception Return corrupts ELR_EL2 and may cause spurious Instruction Aborts
--

commit 56bc216de713f5bf0e45ff5ad97580cbdc7eeb66
Author: Fuad Tabba <tabba@google.com>

KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation

This commit fixes the FPAC syndrome constructed during nested ERET
emulation to include the IL bit. It ensures that the IL bit is set to 1
for ERET and its authenticated variants, which are always 32-bit A64
instructions.

> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2777,7 +2777,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
>  		 */
>  		if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
>  			esr &= ESR_ELx_ERET_ISS_ERETA;
> -			esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
> +			esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC) | ESR_ELx_IL;
>  			kvm_inject_nested_sync(vcpu, esr);
>  			return;
>  		}
>  	}
>  
>  	preempt_disable();
>  	vcpu_set_flag(vcpu, IN_NESTED_ERET);
>  	kvm_arch_vcpu_put(vcpu);
>  
>  	if (!esr_iss_is_eretax(esr))
>  		elr = __vcpu_sys_reg(vcpu, ELR_EL2);
>  
>  	trace_kvm_nested_eret(vcpu, elr, spsr);
>  
>  	*vcpu_pc(vcpu) = elr;
>  	*vcpu_cpsr(vcpu) = spsr;

[Severity: High]
This is a pre-existing issue, but does setting the PC to the target address
here cause issues when an illegal exception return is detected?

If kvm_check_illegal_exception_return() previously detected an illegal return
and set PSR_IL_BIT in spsr, kvm_emulate_nested_eret() unconditionally
advances the guest PC to the ERET target address (elr) and returns to the
guest, relying on hardware to generate the Illegal Execution State exception.

Wouldn't the hardware then save the target address into the guest's ELR_EL2
instead of the faulting ERET address, corrupting the architectural state?

Additionally, since the hardware fetches the instruction at the target address
using the guest EL2 translation regime before execution, an unmapped or
unexecutable target address could trigger an Instruction Abort instead of the
required Illegal Execution State exception, per ARM ARM D1.8.2.

Could this result in the guest hypervisor receiving a spurious Instruction
Abort for an EL1/EL0 address?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260614163336.3490925-1-tabba@google.com?part=4