From: Keir Fraser <keirf@google.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Kristina Martsenko <kristina.martsenko@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] arm64: mops: Do not dereference src reg for a set operation
Date: Wed, 26 Mar 2025 10:45:20 +0000 [thread overview]
Message-ID: <Z-PawJpGJRcSTMnc@google.com> (raw)
In-Reply-To: <Z-PWZ98oNna6nVu1@J2N7QTR9R3>
On Wed, Mar 26, 2025 at 10:26:47AM +0000, Mark Rutland wrote:
> On Wed, Mar 26, 2025 at 07:02:55AM +0000, Keir Fraser wrote:
> > The register is not defined and reading it can result in a UBSAN
> > out-of-bounds array access error, specifically when the srcreg field
> > value is 31.
>
> I'm assuming this is for a MOPS exception taken from a SET* sequence
> with XZR as the source?
Yes.
> It'd be nice to say that explicitly, as this is the only case where any
> of the src/dst/size fields in the ESR can be reported as 31. In all
> other cases where a CPY* or SET* instruction takes register 31 as an
> argument, the behaviour is CONSTRAINED UNPREDICTABLE and cannot generate
> a MOPS exception.
Okay, will do.
> Note that in ARM DDI 0487 L.a there's a bug where:
>
> * The prose says that SET* taking XZR as a src is CONSTRAINED
> UNPREDICTABLE, per K1.2.17.1.1 linked from C6.2.332.
>
> The title for the K1.2.17.1.1 is "Memory Copy and Memory Set CPY*",
> which looks like an editing error.
>
> * The pseudocode is explicit that the CONSTRAINED UNPREDICTABLE
> behaviours differ for CPY* and SET* per J1.1.3.121
> CheckCPYConstrainedUnpredictable() and J1.1.3.125
> CheckSETConstrainedUnpredictable().
>
> ... and I'll go file a ticket about that soon if someone doesn't beat me
> to it.
>
> > Cc: Kristina Martsenko <kristina.martsenko@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
>
> Looks like this should have:
>
> Fixes: 2de451a329cf662b ("KVM: arm64: Add handler for MOPS exceptions")
>
> Prior to that, the code in do_el0_mops() was benign as the use of
> pt_regs_read_reg() prevented the out-of-bounds access. It'd also be nice
> to note that in the commit message.
I will add this too. And Marc's reviewed-by. And re-send as v2. Thanks!
Keir
> Mark.
>
> > Signed-off-by: Keir Fraser <keirf@google.com>
> > ---
> > arch/arm64/include/asm/traps.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/traps.h b/arch/arm64/include/asm/traps.h
> > index d780d1bd2eac..82cf1f879c61 100644
> > --- a/arch/arm64/include/asm/traps.h
> > +++ b/arch/arm64/include/asm/traps.h
> > @@ -109,10 +109,9 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon
> > int dstreg = ESR_ELx_MOPS_ISS_DESTREG(esr);
> > int srcreg = ESR_ELx_MOPS_ISS_SRCREG(esr);
> > int sizereg = ESR_ELx_MOPS_ISS_SIZEREG(esr);
> > - unsigned long dst, src, size;
> > + unsigned long dst, size;
> >
> > dst = regs->regs[dstreg];
> > - src = regs->regs[srcreg];
> > size = regs->regs[sizereg];
> >
> > /*
> > @@ -129,6 +128,7 @@ static inline void arm64_mops_reset_regs(struct user_pt_regs *regs, unsigned lon
> > }
> > } else {
> > /* CPY* instruction */
> > + unsigned long src = regs->regs[srcreg];
> > if (!(option_a ^ wrong_option)) {
> > /* Format is from Option B */
> > if (regs->pstate & PSR_N_BIT) {
> > --
> > 2.49.0.395.g12beb8f557-goog
> >
next prev parent reply other threads:[~2025-03-26 10:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 7:02 [PATCH] arm64: mops: Do not dereference src reg for a set operation Keir Fraser
2025-03-26 9:39 ` Marc Zyngier
2025-03-26 10:26 ` Mark Rutland
2025-03-26 10:45 ` Keir Fraser [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-03-26 11:00 Keir Fraser
2025-03-26 11:05 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z-PawJpGJRcSTMnc@google.com \
--to=keirf@google.com \
--cc=catalin.marinas@arm.com \
--cc=kristina.martsenko@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=stable@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.