From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F3463C7E0E; Thu, 18 Jun 2026 12:48:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781786937; cv=none; b=MwYpSbdGKxiJgKQpPcEVBDQNBIqNO6utStcPuMjI4NJVK8ObfPCBoFKyxjTayR2CpChyXQ1AJate/gjP/TvLyvboW3+Itw6FlrC+MDG3Sh5ebbUtS5pKtcUIzRTPTTFK8LjDsEA9hoArIKyomxb7EQwbvi0IsQb+zWYFbkwcwmY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781786937; c=relaxed/simple; bh=WuGBWJ1pz0HXjJrT/ICME/CSZ1MVQLljr/J5RLx68N0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=Z1tWEjuWrviCMZXcdXyy8bxmFJHcEYUGjbe5ShsMZZ/QJCwv01qwkApKoUkT+QqLs29uAlZ2qqdiPxgEq4yXIsj37fQoHu9hftYKjWIWNPQ/IQj8u2dv/pD6xdyrS/0X5UG0J/SMlOnqexK6WpFYWozHlG4m1pvSqAQPnoXz1vg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NoWOubQm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NoWOubQm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 152CB1F000E9; Thu, 18 Jun 2026 12:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781786936; bh=5BQkpnOyL96ryYJZZE0QZ2WkuLeWhsXeeHfNGkh9M4M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NoWOubQm6sYlgA1UG1pbE/PbyEWXuLt65njQnRlzSSx9eVrE2mtNaIiVnVcTeU7sI zqisyfqJb0JZsayvaCCmXW2OJ3URV0pqM8f0CvgEtEfM9q0wp6/h54RTgknLZeq4Vc IeCF7+xZ7XDrt6pOOiFYfmQZWVuCl0W37Y/Mg3UuUajtKHMi9wNDioZexe2WMLvpM/ Yw5LpxLLZQBGiVWhANQyRIMNtmkoN6nj3n35dnuIC/TY2qOPnH1DvCI9rWRcDHOnzu qSYaT/5vhuRPb5dnGPf4F4dZDyITOIcPZ6OPht2ftewWLegX1Wy3pTDPLML30lgYdk tUmcpGbBgUfiA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1waCAw-0000000E13l-0Nyy; Thu, 18 Jun 2026 12:48:54 +0000 Date: Thu, 18 Jun 2026 13:48:53 +0100 Message-ID: <86cxxorp3e.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: "Fuad Tabba" , kvmarm@lists.linux.dev, "Oliver Upton" Subject: Re: [PATCH v2 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation In-Reply-To: <20260618122808.1369D1F000E9@smtp.kernel.org> References: <20260618121643.4105064-1-tabba@google.com> <20260618121643.4105064-5-tabba@google.com> <20260618122808.1369D1F000E9@smtp.kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sashiko-reviews@lists.linux.dev, tabba@google.com, kvmarm@lists.linux.dev, oupton@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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 > 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.