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

[Marc Zyngier <maz@kernel.org>]

On Thu, 18 Jun 2026 13:28:07 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The constructed FPAC exception syndrome incorrectly maps the ERET ISS encoding directly to the FPAC ISS encoding, resulting in malformed ISS[2:0] bits being injected into the guest.
> --
> 
> commit 27996a8004c4285e2d114067b3fc644f3f649d64
> Author: Fuad Tabba <tabba@google.com>
> KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
> 
> This commit sets the IL (Instruction Length) bit for the FPAC syndrome
> constructed during nested ERET emulation. Since ERET and its authenticated
> variants are always A64 32-bit instructions, the IL bit must be set to 1.
> 
> > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> > index dba7ced74ca5e..b74369e9ad7ff 100644
> > --- a/arch/arm64/kvm/emulate-nested.c
> > +++ b/arch/arm64/kvm/emulate-nested.c
> > @@ -2776,7 +2776,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
> >  		 * ERET handling, and the guest will have a little surprise.
> >  		 */
> >  		if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
> > -			esr &= ESR_ELx_ERET_ISS_ERETA;
> > +			esr &= (ESR_ELx_ERET_ISS_ERETA | ESR_ELx_IL);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but does this mapping of the ERET
> ISS to the FPAC ISS result in malformed ISS[2:0] bits being injected into
> the guest?
> 
> For an ERET trap (EC=0x1A), ISS[0] indicates the key used (0 for ERETAA,
> 1 for ERETAB). For an FPAC exception (EC=0x1C), ISS[0] is the Instruction
> Type (must be 1 for a branch/return instruction), and ISS[2:1] indicates
> the Authentication Key.

No. Not at all. ESR_ELx_EC_FPAC (0x1C) defines ISS[0] as BnA. Which
matches the definition for ERET. On purpose. See ARM DDI 0487, version
M.b, D24-8777.

>
> By retaining the ERET ISS[0] bit and clearing the rest, it appears KVM
> inadvertently maps the ERET key type directly into the FPAC Instruction
> Type bit, while leaving the FPAC key type (ISS[2:1]) always at 00.
> 
> Consequently, wouldn't ERETAA be injected with an FPAC ISS of 0 (wrong
> instruction type), and ERETAB get an FPAC ISS of 1 (wrong key type)?

Yes, and that'd be correct.

I don't know who told Sashiko about the ARM ARM, but it doesn't seem
to parse it correctly.

	M.

-- 
Without deviation from the norm, progress is not possible.