On Fri, 22 Sep 2023 14:42:55 +0100, Mark Brown wrote:
> In the ZA and ZT test programs we explicitly validate that PSTATE.ZA is as
> expected on each loop but we do not do the equivalent for our streaming
> SVE test, add a check that we are still in streaming mode on every loop
> in case that goes
On Fri, 15 Sep 2023 13:18:05 +0100, Mark Brown wrote:
> SVE 2.1 introduced a new feature FEAT_SVE_B16B16 which adds instructions
> supporting the BFloat16 floating point format. Report this to userspace
> through the ID registers and hwcap.
>
>
Applied to arm64 (for-next/feat_sve_b16b16), thanks
On Wed, Sep 27, 2023 at 03:01:08PM +0100, Joey Gouly wrote:
> +static void permission_overlay_switch(struct task_struct *next)
> +{
> + if (alternative_has_cap_unlikely(ARM64_HAS_S1POE)) {
> + current->thread.por_el0 = read_sysreg_s(SYS_POR_EL0);
> + write_sysreg_s(next-
On Tue, Oct 03, 2023 at 03:26:51PM +0100, Mark Brown wrote:
> On Tue, Oct 03, 2023 at 09:45:56AM +0100, Szabolcs Nagy wrote:
> > clone3 seems to have features that are only available in clone3 and
> > not exposed (reasonably) in libc apis so ppl will use clone3 directly
> > and those will be hard t
On Tue, Nov 07, 2023 at 06:32:13PM +0530, Naresh Kamboju wrote:
> # <1>[ 88.160313] Unable to handle kernel paging
> request at virtual address 00550f0344550f02
It would really help if the kernel dump was not wrapped. Just use git
send-email to post to the list if your email client wraps the log
On Thu, 16 Nov 2023 12:52:29 +, Mark Brown wrote:
> The za-fork test does not output a newline when reporting the result of
> the one test it runs, causing the counts printed by kselftest to be
> included in the test name. Add the newline.
>
>
Applied to arm64 (for-next/fixes), thanks!
[1/
Hi Mark,
Thanks for putting this together and sorry it took me some time to catch
up (well, still not fully, so rather more questions below).
On Tue, Nov 28, 2023 at 06:22:38PM +, Mark Brown wrote:
> Since clone3() is readily extensible let's add support for specifying a
> shadow stack when c
Thanks all for the clarification.
On Thu, Nov 30, 2023 at 09:51:04PM +, Mark Brown wrote:
> On Thu, Nov 30, 2023 at 07:00:58PM +0000, Catalin Marinas wrote:
> > My hope when looking at the arm64 patches was that we can completely
> > avoid the kernel allocation/deallocatio
On Fri, Nov 24, 2023 at 04:34:46PM +, Joey Gouly wrote:
> Add POR_EL{0,1} according to DDI0601 2023-03.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Mark Brown
Acked-by: Catalin Marinas
On Fri, Nov 24, 2023 at 04:34:47PM +, Joey Gouly wrote:
> Add E0POE bit that traps accesses to POR_EL0 from EL0.
Nitpick: s/traps/enables/
Acked-by: Catalin Marinas
On Fri, Nov 24, 2023 at 04:34:48PM +, Joey Gouly wrote:
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2078,6 +2078,22 @@ config ARM64_EPAN
> if the cpu does not implement the feature.
> endmenu # "ARMv8.7 architectural features"
>
> +menu "ARMv8.9 architectural features
On Fri, Nov 24, 2023 at 04:34:49PM +, Joey Gouly wrote:
> Allow EL0 or EL1 to access POR_EL0 without being trapped to EL2.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Fri, Nov 24, 2023 at 04:34:50PM +, Joey Gouly wrote:
> @@ -498,6 +508,17 @@ static void erratum_1418040_new_exec(void)
> preempt_enable();
> }
>
> +static void permission_overlay_switch(struct task_struct *next)
> +{
> + if (system_supports_poe()) {
> + current->thre
On Sat, Nov 25, 2023 at 12:02:49PM +, Mark Brown wrote:
> On Fri, Nov 24, 2023 at 04:34:50PM +, Joey Gouly wrote:
>
> > +static void flush_poe(void)
> > +{
> > + if (system_supports_poe())
> > + write_sysreg_s(POR_EL0_INIT, SYS_POR_EL0);
> > +}
>
> Here we have no isb()...
My
On Fri, Nov 24, 2023 at 04:34:52PM +, Joey Gouly wrote:
> +#ifdef CONFIG_ARM64_POE
> +static void cpu_enable_poe(const struct arm64_cpu_capabilities *__unused)
> +{
> + sysreg_clear_set(REG_TCR2_EL1, 0, TCR2_EL1x_E0POE);
> + sysreg_clear_set(CPACR_EL1, 0, CPACR_ELx_E0POE);
> +}
> +#endi
On Fri, Nov 24, 2023 at 04:34:54PM +, Joey Gouly wrote:
> arch/arm64/include/asm/mman.h | 8 +++-
> arch/arm64/include/asm/page.h | 10 ++
> arch/arm64/mm/mmap.c| 9 +
> arch/powerpc/include/asm/page.h | 11 +++
> arch/x86/include/asm/page.h |
On Fri, Nov 24, 2023 at 04:34:55PM +, Joey Gouly wrote:
> When a PTE is modified, the POIndex must be masked off so that it can be
> modified.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Fri, Nov 24, 2023 at 04:34:56PM +, Joey Gouly wrote:
> diff --git a/arch/arm64/include/asm/pkeys.h b/arch/arm64/include/asm/pkeys.h
> new file mode 100644
> index ..5761fb48fd53
> --- /dev/null
> +++ b/arch/arm64/include/asm/pkeys.h
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifie
On Fri, Nov 24, 2023 at 04:34:57PM +, Joey Gouly wrote:
> @@ -497,6 +498,23 @@ static void do_bad_area(unsigned long far, unsigned long
> esr,
> #define VM_FAULT_BADMAP ((__force vm_fault_t)0x01)
> #define VM_FAULT_BADACCESS ((__force vm_fault_t)0x02)
>
> +static boo
On Fri, Nov 24, 2023 at 04:34:58PM +, Joey Gouly wrote:
> These functions will be extended to support pkeys.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Nit: can you squash it into patch 14 introducing those functions? Less
patches to carry.
On Fri, Nov 24, 2023 at 04:34:59PM +, Joey Gouly wrote:
> @@ -211,11 +212,24 @@ init_new_context(struct task_struct *tsk, struct
> mm_struct *mm)
> {
> atomic64_set(&mm->context.id, 0);
> refcount_set(&mm->context.pinned, 0);
> +
> + // pkey 0 is the default, so always reserve
kframe.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Mark Brown
> ---
> arch/arm64/include/uapi/asm/sigcontext.h | 7
> arch/arm64/kernel/signal.c | 51
> 2 files changed, 58 insertion
On Fri, Nov 24, 2023 at 04:35:01PM +, Joey Gouly wrote:
> Now that PKEYs support has been implemented, enable it for CPUs that
> support S1POE.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Catalin Marinas
On Fri, Nov 24, 2023 at 04:35:02PM +, Joey Gouly wrote:
> Set the EL0/userspace indirection encodings to be the overlay enabled
> variants of the permissions.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm64/includ
On Fri, Nov 24, 2023 at 04:35:03PM +, Joey Gouly wrote:
> Add a regset for POE containing POR_EL0.
>
> Signed-off-by: Joey Gouly
> Cc: Catalin Marinas
> Cc: Will Deacon
Reviewed-by: Catalin Marinas
On Mon, 22 Jan 2024 21:05:03 +, Mark Brown wrote:
> While we have test coverage for the ptrace interface in our selftests
> the current programs have a number of gaps. The testing is done per
> regset so does not cover interactions and at no point do any of the
> tests actually run the traced p
On Wed, 06 Mar 2024 23:14:45 +, Mark Brown wrote:
> This series enables support for the data processing extensions in the
> newly released 2023 architecture, this is mainly support for 8 bit
> floating point formats. Most of the extensions only introduce new
> instructions and therefore only r
On Tue, 21 May 2024 19:18:26 +0100, Mark Brown wrote:
> Currently fp-stress only covers userspace use of floating point, it does
> not cover any kernel mode uses. Since currently kernel mode floating
> point usage can't be preempted and there are explicit preemption points in
> the existing implem
On Wed, 05 Jun 2024 17:24:48 +0530, Dev Jain wrote:
> Currently, we are writing the same value as we read, into the TLS
> register; hence, we cannot confirm updation of the register, making the
> testcase "verify_tpidr_one" redundant. Fix this; while at it, do a style
> change.
>
>
Applied to ar
On Thu, 13 Jun 2024 08:34:29 +0100, Colin Ian King wrote:
> There are two spelling mistakes in some error messages. Fix them.
>
>
Applied to arm64 (for-next/kselftest), thanks!
[1/1] kselftest/arm64: Fix a couple of spelling mistakes
https://git.kernel.org/arm64/c/963c5d496822
--
Catali
On Sun, Jun 02, 2024 at 06:24:59PM +0500, Muhammad Usama Anjum wrote:
> Conform the layout, informational and status messages to TAP. No
> functional change is intended other than the layout of output messages.
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> tools/testing/selftests/arm64/tags/ta
On Sun, 02 Jun 2024 18:24:59 +0500, Muhammad Usama Anjum wrote:
> Conform the layout, informational and status messages to TAP. No
> functional change is intended other than the layout of output messages.
>
>
Applied to arm64 (for-next/kselftest), thanks!
[1/2] selftests: arm64: tags_test: conf
On Wed, Apr 24, 2024 at 11:39:23AM +0100, Ryan Roberts wrote:
> - Have a chat with Catalin about appetite for soft-dirty on arm64; But
> likely
> that will be left here until/unless there is clear justificaiton that the
> use case cannot be met with uffd-wp.
I agree, I wouldn't use the
On Thu, Aug 08, 2024 at 09:15:25AM +0100, Mark Brown wrote:
> diff --git a/arch/x86/kernel/shstk.c b/arch/x86/kernel/shstk.c
> index 059685612362..d7005974aff5 100644
> --- a/arch/x86/kernel/shstk.c
> +++ b/arch/x86/kernel/shstk.c
> @@ -191,44 +191,105 @@ void reset_thread_features(void)
> cu
On Sat, Aug 10, 2024 at 12:06:12AM +0100, Mark Brown wrote:
> On Fri, Aug 09, 2024 at 07:19:26PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 08, 2024 at 09:15:25AM +0100, Mark Brown wrote:
> > > + /* This should really be an atomic cmpxchg. It is not. */
> > > + if
On Tue, Aug 13, 2024 at 07:58:26PM +0100, Mark Brown wrote:
> On Tue, Aug 13, 2024 at 05:25:47PM +0100, Catalin Marinas wrote:
> > However, the x86 would be slightly inconsistent here between clone() and
> > clone3(). I guess it depends how you look at it. The classic clone()
>
t; important considerations for userspace code interacting directly with the
> feature let's provide some documentation covering the common aspects.
>
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
t; Suggested-by: David Hildenbrand
> Acked-by: David Hildenbrand
> Reviewed-by: Deepak Gupta
> Reviewed-by: Rick Edgecombe
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
refactor the existing code to be more extensible, no functional change
> intended.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
k
> pointer is required this could be a separate prctl.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
op of stack
> merker in the shadow stack */
s/merker/marker/
Otherwise:
Reviewed-by: Catalin Marinas
On Thu, Aug 01, 2024 at 01:06:31PM +0100, Mark Brown wrote:
> + - If EL2 is present:
> +
> +- GCSCR_EL2 must be initialised to 0.
> +
> + - If the kernel is entered at EL1 and EL2 is present:
> +
> +- GCSCR_EL1 must be initialised to 0.
> +
> +- GCSCRE0_EL1 must be initialised to 0.
C
On Thu, Aug 15, 2024 at 12:18:23AM +, Edgecombe, Rick P wrote:
> On Thu, 2024-08-08 at 09:15 +0100, Mark Brown wrote:
> > +int arch_shstk_post_fork(struct task_struct *t, struct kernel_clone_args
> > *args)
[...]
> > + /* This should really be an atomic cmpxchg. It is not. */
> > +
On Thu, Aug 01, 2024 at 01:06:32PM +0100, Mark Brown wrote:
> +1. General
> +---
[...]
> +* EL0 GCS entries with bit 63 set are reserved for use, one such use is
> defined
Maybe "reserved for specific uses". The proposed sentenced feels like
it's missing something.
> + below for signal
gt; Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Acked-by: Catalin Marinas
e
> a bit limiting for the compiler but none of these should be used in
> sufficiently fast paths for this to be a problem.
>
> Note that GCSSTTR is used to store to EL0.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Acked-by: Catalin Marinas
n
Reviewed-by: Catalin Marinas
>
> We also initialise GCSCR_EL1 and GCSCRE0_EL1 to ensure that we can
> execute function call instructions without faulting regardless of the
> state when the kernel is started.
>
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
E2H0, NI_NV1)
> },
> + {
> + .desc = "Guarded Control Stack (GCS)",
> + .capability = ARM64_HAS_GCS,
> + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
Given that it's for user space only, system feature makes sense.
Reviewed-by: Catalin Marinas
ndex(_PAGE_SHARED),PIE_RW))
>
> #define PIE_E1 ( \
> + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS), PIE_NONE_O) | \
> + PIRx_ELx_PERM(pte_pi_index(_PAGE_GCS_RO),PIE_NONE_O) | \
It's fine to keep PIE_NONE_O here, the kernel wouldn't need to access
this memory with unprivileged instructions (it only matters for the
futex code using LDXR/STXR).
Reviewed-by: Catalin Marinas
On Fri, Aug 16, 2024 at 11:51:57AM +0100, Mark Brown wrote:
> On Fri, Aug 16, 2024 at 09:44:46AM +0100, Catalin Marinas wrote:
> > We could, in theory, consume this token in the parent before the child
> > mm is created. The downside is that if a parent forks multiple
> > pro
On Fri, Aug 16, 2024 at 02:52:28PM +, Edgecombe, Rick P wrote:
> On Fri, 2024-08-16 at 09:44 +0100, Catalin Marinas wrote:
> > > After a token is consumed normally, it doesn't set it to zero. Instead it
> > > sets it to a "previous-ssp token". I don't
On Thu, Aug 01, 2024 at 01:06:39PM +0100, Mark Brown wrote:
> Use VM_HIGH_ARCH_5 for guarded control stack pages.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 01, 2024 at 01:06:40PM +0100, Mark Brown wrote:
> Map pages flagged as being part of a GCS as such rather than using the
> full set of generic VM flags.
>
> This is done using a conditional rather than extending the size of
> protection_map since that would make for a very sparse array
On Thu, Aug 01, 2024 at 01:06:42PM +0100, Mark Brown wrote:
> Hook up an override for GCS, allowing it to be disabled from the command
> line by specifying arm64.nogcs in case there are problems.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Acked-by: Catalin Marinas
p.h
> @@ -122,5 +122,6 @@
> #define HWCAP2_SME_SF8FMA(1UL << 60)
> #define HWCAP2_SME_SF8DP4(1UL << 61)
> #define HWCAP2_SME_SF8DP2(1UL << 62)
> +#define HWCAP2_GCS (1UL << 63)
You'll be fighting with Joey over the last bit here ;) (we do have
HWCAP3 though).
Reviewed-by: Catalin Marinas
t 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.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 01, 2024 at 01:06:45PM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 451ba7cbd5ad..0973dd09f11a 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -486,6 +486,14 @@ static void do_bad_area(unsigned long far, unsigned l
On Thu, Aug 01, 2024 at 01:06:46PM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 4ae31b7af6c3..5f00cb0da9c3 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
[...]
> +static void gcs_thread_switch(struct task_s
On Thu, Aug 01, 2024 at 01:06:47PM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 5f00cb0da9c3..d6d3a96cf2e4 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -285,9 +285,32 @@ static void flush_gcs(void)
>
On Mon, Aug 19, 2024 at 05:33:24PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2024 at 10:10:36AM +0100, Catalin Marinas wrote:
> > On Thu, Aug 01, 2024 at 01:06:40PM +0100, Mark Brown wrote:
> > > + if (system_supports_gcs() && (
On Mon, Aug 19, 2024 at 04:44:42PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2024 at 12:46:13PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 01, 2024 at 01:06:46PM +0100, Mark Brown wrote:
> > > + /*
> > > + * Ensure that GCS changes are observable by/from othe
On Mon, Aug 19, 2024 at 04:57:08PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2024 at 01:04:18PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 01, 2024 at 01:06:47PM +0100, Mark Brown wrote:
> > > +static int copy_thread_gcs(struct task_struct *p,
> > > +
On Tue, Aug 20, 2024 at 04:28:21PM +0100, Mark Brown wrote:
> On Tue, Aug 20, 2024 at 03:59:21PM +0100, Catalin Marinas wrote:
> > On Mon, Aug 19, 2024 at 05:33:24PM +0100, Mark Brown wrote:
> > > On Mon, Aug 19, 2024 at 10:10:36AM +0100, Catalin Marinas wrote:
> &g
On Tue, Aug 20, 2024 at 06:56:19PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2024 at 04:44:52PM +0100, Mark Brown wrote:
> > On Mon, Aug 19, 2024 at 12:46:13PM +0100, Catalin Marinas wrote:
> > > On Thu, Aug 01, 2024 at 01:06:46PM +0100
; +
> + }
> + }
Nitpick: use a single 'if' instead of nesting (unless subsequent patches
add more to the first block).
Otherwise it looks fine.
Reviewed-by: Catalin Marinas
he token in the clone3() implementation. Maybe write
something along the lines of "ensure the new cap is ordered before
standard memory accesses to the same location".
Anyway, the patch looks fine.
Reviewed-by: Catalin Marinas
On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote:
> @@ -860,6 +892,50 @@ static int restore_sigframe(struct pt_regs *regs,
> return err;
> }
>
> +#ifdef CONFIG_ARM64_GCS
> +static int gcs_restore_signal(void)
> +{
> + u64 gcspr_el0, cap;
Nitpick: use 'unsigned long __user *g
On Thu, Aug 01, 2024 at 01:06:51PM +0100, Mark Brown wrote:
> @@ -636,6 +639,81 @@ extern int restore_zt_context(struct user_ctxs *user);
>
> #endif /* ! CONFIG_ARM64_SME */
>
> +#ifdef CONFIG_ARM64_GCS
> +
> +static int preserve_gcs_context(struct gcs_context __user *ctx)
> +{
> + int err
On Thu, Aug 01, 2024 at 01:06:52PM +0100, Mark Brown wrote:
> @@ -1440,6 +1441,51 @@ static int tagged_addr_ctrl_set(struct task_struct
> *target, const struct
> }
> #endif
>
> +#ifdef CONFIG_ARM64_GCS
> +static int gcs_get(struct task_struct *target,
> +const struct user_regse
On Thu, Aug 01, 2024 at 01:06:53PM +0100, Mark Brown wrote:
> Provide a Kconfig option allowing the user to select if GCS support is
> built into the kernel.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Wed, Aug 21, 2024 at 06:23:18PM +0100, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 03:54:49PM +, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
> > > > Sorry for that. I looked through all the old threads expecting to find
> > > > discussion, but couldn't f
On Wed, Aug 21, 2024 at 07:03:13PM +0100, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 06:28:49PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 01, 2024 at 01:06:50PM +0100, Mark Brown wrote:
> > > + /*
> > > + * Push a cap and the GCS entry for
tuation where leaving
> GCS enabled would be reasonable.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:09AM +0100, Mark Brown wrote:
> Add some documentation of the userspace ABI for Guarded Control Stacks.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:16AM +0100, Mark Brown wrote:
> Use VM_HIGH_ARCH_5 for guarded control stack pages.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
flags & VM_SHADOW_STACK)) {
> + prot = _PAGE_GCS_RO;
> + } else {
> + prot = pgprot_val(protection_map[vm_flags &
> (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]);
> + }
>
> + /* VM_ARM64_BTI on a GCS is rejected in arch_validate_flags() */
Not anymore.
> if (vm_flags & VM_ARM64_BTI)
> prot |= PTE_GP;
Other than the comment above, it looks good.
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:19AM +0100, Mark Brown wrote:
> Hook up an override for GCS, allowing it to be disabled from the command
> line by specifying arm64.nogcs in case there are problems.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:20AM +0100, Mark Brown wrote:
> Provide a hwcap to enable userspace to detect support for GCS.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
t 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.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:21AM +0100, Mark Brown wrote:
> +static void noinstr el0_gcs(struct pt_regs *regs, unsigned long esr)
> +{
> + enter_from_user_mode(regs);
> + local_daif_restore(DAIF_PROCCTX);
> + do_el0_gcs(regs, esr);
> + exit_to_user_mode(regs);
> +}
> +
> static v
On Thu, Aug 22, 2024 at 02:15:22AM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 451ba7cbd5ad..3ada31c2ac12 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -486,6 +486,14 @@ static void do_bad_area(unsigned long far, unsigned l
ting of GCS faults if userspace implements disabling of
> GCS on error - the GCS can still be discovered and examined even if GCS
> has been disabled.
>
> Signed-off-by: Mark Brown
We could do with a bit more code comments around GCSB DSYNC but
otherwise it looks fine now.
Reviewed-by: Catalin Marinas
d(current) || task_gcs_el0_enabled(next))
> + gcsb_dsync();
> }
Ah, the comment turned up in this patch. It looks fine.
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 05:44:19PM +0100, Mark Brown wrote:
> On Thu, Aug 22, 2024 at 05:12:30PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 22, 2024 at 02:15:22AM +0100, Mark Brown wrote:
>
> > > +static bool is_invalid_gcs_access(struct vm_area_struct *vma, u64 esr)
d validate and pop off on signal return. The combination of the top
> bit being set and the token type mean that this can't be interpreted as
> a valid token or address.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:28AM +0100, Mark Brown wrote:
> +static int preserve_gcs_context(struct gcs_context __user *ctx)
> +{
> + int err = 0;
> + u64 gcspr;
> +
> + /*
> + * We will add a cap token to the frame, include it in the
> + * GCSPR_EL0 we report to support sta
e via ptrace, only GCSPR_EL0 may be changed.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
On Thu, Aug 22, 2024 at 02:15:30AM +0100, Mark Brown wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a2f8ff354ca6..772f9ba99fe8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2137,6 +2137,26 @@ config ARM64_EPAN
> if the cpu does not implement the f
On Fri, Aug 23, 2024 at 11:25:30AM +0100, Mark Brown wrote:
> On Fri, Aug 23, 2024 at 10:37:19AM +0100, Catalin Marinas wrote:
> > On Thu, Aug 22, 2024 at 02:15:28AM +0100, Mark Brown wrote:
>
> > > + gcs_preserve_current_state();
> > > + gcspr =
On Fri, Aug 23, 2024 at 03:45:32PM +0100, Will Deacon wrote:
> On Thu, Aug 22, 2024 at 04:10:49PM +0100, Joey Gouly wrote:
> > +static void permission_overlay_switch(struct task_struct *next)
> > +{
> > + if (!system_supports_poe())
> > + return;
> > +
> > + current->thread.por_el0 =
On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote:
> On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 23, 2024 at 03:45:32PM +0100, Will Deacon wrote:
> > > On Thu, Aug 22, 2024 at 04:10:49PM +0100, Joey Gouly wrote:
&g
On Fri, Aug 23, 2024 at 11:01:13PM +0100, Mark Brown wrote:
> On Fri, Aug 23, 2024 at 04:59:11PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 23, 2024 at 11:25:30AM +0100, Mark Brown wrote:
>
> > > We could store either the cap token or the interrupted GCSPR_EL0 (the
> &
ith cap tokens).
>
> We also report any GCS faults in VMAs not marked as part of a GCS as
> access violations, causing a fault to be delivered to userspace if it
> attempts to do GCS operations outside a GCS.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
ff-by: Mark Brown
It looks fine to me now.
Reviewed-by: Catalin Marinas
On Thu, Aug 29, 2024 at 12:27:42AM +0100, Mark Brown wrote:
> +static int gcs_get(struct task_struct *target,
> +const struct user_regset *regset,
> +struct membuf to)
> +{
> + struct user_gcs user_gcs;
> +
> + if (target == current)
> + gcs_prese
On Tue, Aug 27, 2024 at 12:38:04PM +0100, Will Deacon wrote:
> On Fri, Aug 23, 2024 at 07:40:52PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote:
> > > On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote:
> > > &
On Wed, Sep 04, 2024 at 11:22:54AM +0100, Will Deacon wrote:
> On Tue, Sep 03, 2024 at 03:54:13PM +0100, Joey Gouly wrote:
> > commit 3141fb86bee8d48ae47cab1594dad54f974a8899
> > Author: Joey Gouly
> > Date: Tue Sep 3 15:47:26 2024 +0100
> >
> > fixup! arm64: context switch POR_EL0 register
On Tue, Oct 15, 2024 at 12:41:16PM +0100, Will Deacon wrote:
> On Tue, Oct 15, 2024 at 10:59:11AM +0100, Joey Gouly wrote:
> > On Mon, Oct 14, 2024 at 06:10:23PM +0100, Will Deacon wrote:
> > > Looking a little more at this, I think we have quite a weird behaviour
> > > on arm64 as it stands. It lo
set has been checked before saving POR_EL0; this
> is in line with other frame records (FPMR, TPIDR2).
>
> Signed-off-by: Kevin Brodsky
Acked-by: Catalin Marinas
1 - 100 of 129 matches
Mail list logo
