[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230717131230.00003569@Huawei.com>
Date: Mon, 17 Jul 2023 13:12:30 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Mark Brown <broonie@...nel.org>
CC: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Jonathan Corbet <corbet@....net>,
Andrew Morton <akpm@...ux-foundation.org>,
Marc Zyngier <maz@...nel.org>,
Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>,
"Suzuki K Poulose" <suzuki.poulose@....com>,
Arnd Bergmann <arnd@...db.de>,
"Oleg Nesterov" <oleg@...hat.com>,
Eric Biederman <ebiederm@...ssion.com>,
"Kees Cook" <keescook@...omium.org>, Shuah Khan <shuah@...nel.org>,
"Rick P. Edgecombe" <rick.p.edgecombe@...el.com>,
Deepak Gupta <debug@...osinc.com>,
Ard Biesheuvel <ardb@...nel.org>,
Szabolcs Nagy <Szabolcs.Nagy@....com>,
"H.J. Lu" <hjl.tools@...il.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-doc@...r.kernel.org>, <kvmarm@...ts.linux.dev>,
<linux-fsdevel@...r.kernel.org>, <linux-arch@...r.kernel.org>,
<linux-mm@...ck.org>, <linux-kselftest@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 17/35] arm64/traps: Handle GCS exceptions
On Sun, 16 Jul 2023 22:51:13 +0100
Mark Brown <broonie@...nel.org> wrote:
> A new exception code is defined for GCS specific faults other than
> standard load/store faults, for example GCS token validation failures,
> add handling for this. These faults are reported to userspace as
> segfaults with code SEGV_CPERR (protection error), mirroring the
> reporting for x86 shadow stack errors.
>
> GCS faults due to memory load/store operations generate data aborts with
> a flag set, these will be handled separately as part of the data abort
> handling.
>
> Since we do not currently enable GCS for EL1 we should not get any faults
> there but while we're at it we wire things up there, treating any GCS
> fault as fatal.
>
> Signed-off-by: Mark Brown <broonie@...nel.org>
See below.
> ---
> arch/arm64/include/asm/esr.h | 26 +++++++++++++++++++++++++-
> arch/arm64/include/asm/exception.h | 2 ++
> arch/arm64/kernel/entry-common.c | 23 +++++++++++++++++++++++
> arch/arm64/kernel/traps.c | 11 +++++++++++
> 4 files changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index ae35939f395b..c5a72172fcf1 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
...
> @@ -382,6 +383,29 @@
> #define ESR_ELx_MOPS_ISS_SRCREG(esr) (((esr) & (UL(0x1f) << 5)) >> 5)
> #define ESR_ELx_MOPS_ISS_SIZEREG(esr) (((esr) & (UL(0x1f) << 0)) >> 0)
>
> +/* ISS field definitions for GCS */
> +#define ESR_ELx_ExType_SHIFT (20)
> +#define ESR_ELx_ExType_MASK GENMASK(23, 20)
> +#define ESR_ELx_Raddr_SHIFT (14)
(10) ?
> +#define ESR_ELx_Raddr_MASK GENMASK(14, 10)
> +#define ESR_ELx_Rn_SHIFT (5)
> +#define ESR_ELx_Rn_MASK GENMASK(9, 5)
I think this can also be ESR_ELx_RVALUE_MASK for some ExType
Worth adding that as well?
> +#define ESR_ELx_IT_SHIFT (0)
> +#define ESR_ELx_IT_MASK GENMASK(4, 0)
> +
> +#define ESR_ELx_ExType_DATA_CHECK 0
> +#define ESR_ELx_ExType_EXLOCK 1
> +#define ESR_ELx_ExType_STR 2
> +
> +#define ESR_ELx_IT_RET 0
> +#define ESR_ELx_IT_GCSPOPM 1
> +#define ESR_ELx_IT_RET_KEYA 2
> +#define ESR_ELx_IT_RET_KEYB 3
> +#define ESR_ELx_IT_GCSSS1 4
> +#define ESR_ELx_IT_GCSSS2 5
> +#define ESR_ELx_IT_GCSPOPCX 6
> +#define ESR_ELx_IT_GCSPOPX 7
Powered by blists - more mailing lists