[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250507180811.3CKhxtu0@linutronix.de>
Date: Wed, 7 May 2025 20:08:11 +0200
From: Nam Cao <namcao@...utronix.de>
To: Samuel Holland <samuel.holland@...ive.com>
Cc: Alexandre Ghiti <alex@...ti.fr>, Palmer Dabbelt <palmer@...belt.com>,
linux-riscv@...ts.infradead.org, Albert Ou <aou@...s.berkeley.edu>,
Bill O'Donnell <bodonnel@...hat.com>,
Charlie Jenkins <charlie@...osinc.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Joel Granados <joel.granados@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Yunhui Cui <cuiyunhui@...edance.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: Disallow PR_GET_TAGGED_ADDR_CTRL without Supm
On Wed, May 07, 2025 at 07:52:18AM -0700, Samuel Holland wrote:
> When the prctl() interface for pointer masking was added, it did not
> check that the pointer masking ISA extension was supported, only the
> individual submodes. Userspace could still attempt to disable pointer
> masking and query the pointer masking state. commit 81de1afb2dd1
> ("riscv: Fix kernel crash due to PR_SET_TAGGED_ADDR_CTRL") disallowed
> the former, as the senvcfg write could crash on older systems.
> PR_GET_TAGGED_ADDR_CTRL state does not crash, because it reads only
> kernel-internal state and not senvcfg, but it should still be disallowed
> for consistency.
>
> Fixes: 09d6775f503b ("riscv: Add support for userspace pointer masking")
> Signed-off-by: Samuel Holland <samuel.holland@...ive.com>
> ---
>
> arch/riscv/kernel/process.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
> index 7c244de77180..f7a1a887ae68 100644
> --- a/arch/riscv/kernel/process.c
> +++ b/arch/riscv/kernel/process.c
> @@ -330,6 +330,9 @@ long get_tagged_addr_ctrl(struct task_struct *task)
> struct thread_info *ti = task_thread_info(task);
> long ret = 0;
>
> + if (!riscv_has_extension_unlikely(RISCV_ISA_EXT_SUPM))
> + return -EINVAL;
> +
> if (is_compat_thread(ti))
> return -EINVAL;
I think this matches what the man page says:
"If the arguments are invalid or this feature is disabled or unsupported by
the kernel, the call fails with EINVAL"
Reviewed-by: Nam Cao <namcao@...utronix.de>
Powered by blists - more mailing lists