Re: [PATCH v20 14/14] KVM: selftests: arm64: Add GCS EXLOCK exception emulation test

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Test asserts non-compliant KVM behavior for illegal ERET and fails to repair PC, causing infinite loops on compliant hardware.
--

commit 1bcae6fc1af422d4031f784c89cb5527a9aaf25d
Author: Mark Brown <broonie@kernel.org>

KVM: selftests: arm64: Add GCS EXLOCK exception emulation test

This commit adds a new KVM selftest for ARM64 to validate Exception Locking
(EXLOCK) with Guarded Control Stack (GCS) during exception returns (ERET). It
verifies that KVM correctly synthesizes Illegal Execution state exceptions
when an ERET is performed with inconsistent EXLOCK state.

> diff --git a/tools/testing/selftests/kvm/arm64/gcs_exceptions.c b/tools/testing/selftests/kvm/arm64/gcs_exceptions.c
> new file mode 100644
> index 0000000000000..de5bc65907272
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/arm64/gcs_exceptions.c
[ ... ]
> +static void guest_illegal_handler(struct ex_regs *regs)
> +{
> +	u64 esr = read_sysreg(esr_el2);
> +
> +	illegal_count++;
> +	illegal_pstate = regs->pstate;
> +
> +	GUEST_ASSERT_EQ(ESR_ELx_EC(esr), ESR_ELx_EC_ILL);
> +	GUEST_ASSERT(esr & ESR_ELx_IL);
> +	GUEST_ASSERT(regs->pstate & PSTATE_IL_BIT);
> +	GUEST_ASSERT(!(regs->pstate & PSR_EXLOCK_BIT));
> +	GUEST_ASSERT_EQ(regs->pc, expected_illegal_pc);

[Severity: Medium]
According to the ARM Architecture Reference Manual (DDI0487), when an Exception
return is illegal (e.g. due to EXLOCKEN), an Illegal Execution state exception
is taken, and the preferred exception return address is the address of the
Exception return instruction (the eret itself).

Does this assertion in guest_illegal_handler incorrectly expect regs->pc to be
the target of the eret (expected_illegal_pc) instead of the eret instruction's
address?

Additionally, because the hardware overwrites the original target ELR_EL2 with
the address of the eret when taking the illegal exception, will failing to
repair regs->pc back to expected_illegal_pc here cause the subsequent eret
to infinitely return to itself on compliant hardware?

> +
> +	/* Disable exception locking so we can repair the return state. */
> +	write_sysreg_s(0, SYS_GCSCR_EL2);
> +	isb();

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-arm64-gcs-v20-0-f31750bdfadb@kernel.org?part=14