From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Benjamin Gray" <bgray@linux.ibm.com>, <linuxppc-dev@lists.ozlabs.org>
Cc: linux-hardening@vger.kernel.org, ajd@linux.ibm.com,
cmr@bluescreens.de, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 03/13] powerpc/dexcr: Handle hashchk exception
Date: Tue, 29 Nov 2022 20:39:24 +1000 [thread overview]
Message-ID: <COOPRF72WR3V.1WPE5NI7M8V7J@bobo> (raw)
In-Reply-To: <20221128024458.46121-4-bgray@linux.ibm.com>
On Mon Nov 28, 2022 at 12:44 PM AEST, Benjamin Gray wrote:
> Recognise and pass the appropriate signal to the user program when a
> hashchk instruction triggers. This is independent of allowing
> configuration of DEXCR[NPHIE], as a hypervisor can enforce this aspect
> regardless of the kernel.
>
> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/include/asm/processor.h | 6 ++++++
> arch/powerpc/kernel/dexcr.c | 22 ++++++++++++++++++++++
> arch/powerpc/kernel/traps.c | 6 ++++++
> 4 files changed, 35 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 21e33e46f4b8..89b316466ed1 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -215,6 +215,7 @@
> #define OP_31_XOP_STFSX 663
> #define OP_31_XOP_STFSUX 695
> #define OP_31_XOP_STFDX 727
> +#define OP_31_XOP_HASHCHK 754
> #define OP_31_XOP_STFDUX 759
> #define OP_31_XOP_LHBRX 790
> #define OP_31_XOP_LFIWAX 855
> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
> index 0a8a793b8b8b..c17ec1e44c86 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -448,10 +448,16 @@ void *exit_vmx_ops(void *dest);
>
> #ifdef CONFIG_PPC_BOOK3S_64
>
> +bool is_hashchk_trap(struct pt_regs const *regs);
> unsigned long get_thread_dexcr(struct thread_struct const *t);
>
> #else
>
> +static inline bool is_hashchk_trap(struct pt_regs const *regs)
> +{
> + return false;
> +}
> +
> static inline unsigned long get_thread_dexcr(struct thread_struct const *t)
> {
> return 0;
> diff --git a/arch/powerpc/kernel/dexcr.c b/arch/powerpc/kernel/dexcr.c
> index 32a0a69ff638..11515e67afac 100644
> --- a/arch/powerpc/kernel/dexcr.c
> +++ b/arch/powerpc/kernel/dexcr.c
> @@ -3,6 +3,9 @@
>
> #include <asm/cpu_has_feature.h>
> #include <asm/cputable.h>
> +#include <asm/disassemble.h>
> +#include <asm/inst.h>
> +#include <asm/ppc-opcode.h>
> #include <asm/processor.h>
> #include <asm/reg.h>
>
> @@ -19,6 +22,25 @@ static int __init dexcr_init(void)
> }
> early_initcall(dexcr_init);
>
> +bool is_hashchk_trap(struct pt_regs const *regs)
> +{
> + ppc_inst_t insn;
> +
> + if (!cpu_has_feature(CPU_FTR_DEXCR_NPHIE))
> + return false;
> +
> + if (get_user_instr(insn, (void __user *)regs->nip)) {
> + WARN_ON(1);
> + return false;
> + }
Nice series, just starting to have a look at it.
You probably don't want a WARN_ON() here because it's user triggerable
and isn't necessarily even indiciating a problem or attack if the app
is doing code unmapping in order to get faults.
Check some of the other instruction emulation for what to do in case of
an EFAULT.
> +
> + if (ppc_inst_primary_opcode(insn) == 31 &&
> + get_xop(ppc_inst_val(insn)) == OP_31_XOP_HASHCHK)
> + return true;
> +
> + return false;
> +}
> +
> unsigned long get_thread_dexcr(struct thread_struct const *t)
> {
> return DEFAULT_DEXCR;
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 9bdd79aa51cf..b83f5b382f24 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1516,6 +1516,12 @@ static void do_program_check(struct pt_regs *regs)
> return;
> }
> }
> +
> + if (user_mode(regs) && is_hashchk_trap(regs)) {
> + _exception(SIGILL, regs, ILL_ILLOPN, regs->nip);
> + return;
> + }
I guess ILLOPN makes sense. Do you know if any other archs do similar?
Thanks,
Nick
next prev parent reply other threads:[~2022-11-29 10:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 2:44 [RFC PATCH 00/13] Add DEXCR support Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 01/13] powerpc/book3s: Add missing <linux/sched.h> include Benjamin Gray
2023-03-07 4:28 ` Nicholas Piggin
2022-11-28 2:44 ` [RFC PATCH 02/13] powerpc: Add initial Dynamic Execution Control Register (DEXCR) support Benjamin Gray
2023-03-07 4:45 ` Nicholas Piggin
2023-03-09 23:46 ` Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 03/13] powerpc/dexcr: Handle hashchk exception Benjamin Gray
2022-11-29 10:39 ` Nicholas Piggin [this message]
2022-11-29 22:04 ` Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 04/13] powerpc/dexcr: Support userspace ROP protection Benjamin Gray
2023-03-07 5:05 ` Nicholas Piggin
2023-03-07 5:37 ` Benjamin Gray
2023-03-21 4:51 ` Nicholas Piggin
2022-11-28 2:44 ` [RFC PATCH 05/13] prctl: Define PowerPC DEXCR interface Benjamin Gray
2023-03-07 5:07 ` Nicholas Piggin
2022-11-28 2:44 ` [RFC PATCH 06/13] powerpc/dexcr: Add prctl implementation Benjamin Gray
2023-03-07 5:12 ` Nicholas Piggin
2022-11-28 2:44 ` [RFC PATCH 07/13] powerpc/dexcr: Add sysctl entry for SBHE system override Benjamin Gray
2023-03-07 5:30 ` Nicholas Piggin
2023-03-07 5:58 ` Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 08/13] powerpc/dexcr: Add enforced userspace ROP protection config Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 09/13] selftests/powerpc: Add more utility macros Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 10/13] selftests/powerpc: Add hashst/hashchk test Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 11/13] selftests/powerpc: Add DEXCR prctl, sysctl interface test Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 12/13] selftests/powerpc: Add DEXCR status utility lsdexcr Benjamin Gray
2022-11-28 2:44 ` [RFC PATCH 13/13] Documentation: Document PowerPC kernel DEXCR interface Benjamin Gray
2023-03-07 5:40 ` Nicholas Piggin
2023-03-07 5:52 ` Benjamin Gray
2022-11-28 4:05 ` [RFC PATCH 00/13] Add DEXCR support Russell Currey
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=COOPRF72WR3V.1WPE5NI7M8V7J@bobo \
--to=npiggin@gmail.com \
--cc=ajd@linux.ibm.com \
--cc=bgray@linux.ibm.com \
--cc=cmr@bluescreens.de \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).