On Fri, 08 Nov 2024 11:05:49 +, Catalin Marinas wrote:
> Since commit 49f59573e9e0 ("selftests/mm: Enable pkey_sighandler_tests
> on arm64"), pkey_sighandler_tests.c (which includes pkey-arm64.h via
> pkey-helpers.h) ends up compiled for arm64. Since it doesn't use
>
On Fri, Nov 08, 2024 at 03:30:11PM +, Mark Brown wrote:
> On Fri, Nov 08, 2024 at 03:25:46PM +0000, Catalin Marinas wrote:
> > On Fri, Nov 08, 2024 at 03:10:59PM +, Mark Brown wrote:
>
> > > > - (ret
On Fri, Nov 08, 2024 at 03:10:59PM +, Mark Brown wrote:
> On Fri, Nov 08, 2024 at 01:49:18PM +0000, Catalin Marinas wrote:
> > While prctl() returns an 'int', the PR_MTE_TCF_MASK is defined as
> > unsigned long which results in the larger type following a bitwise
On Fri, Nov 08, 2024 at 02:58:34PM +, Mark Brown wrote:
> On Fri, Nov 08, 2024 at 01:49:16PM +0000, Catalin Marinas wrote:
> > It looks like people started ignoring the compiler warnings (or even
> > errors) when building the arm64-specific kselftests. The first three
> &g
On Fri, Nov 08, 2024 at 02:53:29PM +, Mark Brown wrote:
> On Fri, Nov 08, 2024 at 01:49:20PM +0000, Catalin Marinas wrote:
> > SMSTOP/SMSTART require the SME arch extension for the assembler. Add
> > '.arch_extension sme' to za-test.S and zt-test.S.
>
> I'v
Fix the incorrect length modifiers in arm64/abi/syscall-abi.c.
Cc: Shuah Khan
Cc: Mark Brown
Signed-off-by: Catalin Marinas
---
tools/testing/selftests/arm64/abi/syscall-abi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/arm64/abi/syscall
SMSTOP/SMSTART require the SME arch extension for the assembler. Add
'.arch_extension sme' to za-test.S and zt-test.S.
Cc: Shuah Khan
Cc: Mark Brown
Signed-off-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/za-test.S | 1 +
tools/testing/selftests/arm64/fp/zt-test.S | 1
While prctl() returns an 'int', the PR_MTE_TCF_MASK is defined as
unsigned long which results in the larger type following a bitwise 'and'
operation. Cast the printf() argument to 'int'.
Cc: Shuah Khan
Cc: Mark Brown
Signed-off-by: Catalin Marinas
---
too
Lots of incorrect length modifiers, missing arguments or conversion
specifiers. Fix them.
Cc: Shuah Khan
Cc: Mark Brown
Signed-off-by: Catalin Marinas
---
tools/testing/selftests/arm64/fp/sve-ptrace.c | 16 +---
tools/testing/selftests/arm64/fp/za-ptrace.c | 8 +---
tools
st).
Note for future kselftest contributors - try to keep them warning-free.
Catalin Marinas (4):
kselftest/arm64: Fix printf() compiler warnings in the arm64 fp tests
kselftest/arm64: Fix printf() warning in the arm64 MTE prctl() test
kselftest/arm64: Fix printf() compiler warnings in
On Thu, 07 Nov 2024 13:16:40 +, Kevin Brodsky wrote:
> Commit 6e182dc9f268 ("selftests/mm: Use generic pkey register
> manipulation") makes use of PKEY_UNRESTRICTED in
> pkey_sighandler_tests. The macro has been proposed for addition to
> uapi headers [1], but the patch hasn't landed yet.
>
>
~
Make the aarch64_write_signal_pkey() a 'static inline void' function to
avoid the compiler warning.
Fixes: f5b5ea51f78f ("selftests: mm: make protection_keys test work on arm64")
Cc: Shuah Khan
Cc: Joey Gouly
Cc: Kevin Brodsky
Signed-off-by: Catalin Marinas
---
I'll add this on top
On Thu, Nov 07, 2024 at 02:26:11PM -0700, Shuah Khan wrote:
> On 11/7/24 11:00, Catalin Marinas wrote:
> > On Thu, Nov 07, 2024 at 09:50:20AM -0700, Shuah Khan wrote:
> > > On 11/7/24 06:16, Kevin Brodsky wrote:
> > > > Commit 6e182dc9f268 ("self
On Thu, Nov 07, 2024 at 09:50:20AM -0700, Shuah Khan wrote:
> On 11/7/24 06:16, Kevin Brodsky wrote:
> > Commit 6e182dc9f268 ("selftests/mm: Use generic pkey register
> > manipulation") makes use of PKEY_UNRESTRICTED in
> > pkey_sighandler_tests. The macro has been proposed for addition to
> > uapi
On Tue, 29 Oct 2024 14:45:34 +, Kevin Brodsky wrote:
> This series is a follow-up to Joey's Permission Overlay Extension (POE)
> series [1] that recently landed on mainline. The goal is to improve the
> way we handle the register that governs which pkeys/POIndex are
> accessible (POR_EL0) durin
On Thu, Oct 24, 2024 at 04:55:48PM +0200, Kevin Brodsky wrote:
> On 24/10/2024 12:59, Catalin Marinas wrote:
> > On Wed, Oct 23, 2024 at 04:05:09PM +0100, Kevin Brodsky wrote:
> >> +/*
> >> + * Save the unpriv access state into ua_state and reset it to disabl
];
>
> badframe:
The saving part I'm fine with. For restoring, I was wondering whether we
can get a more privileged POR_EL0 if reading the frame somehow failed.
This is largely theoretical, there are other ways to attack like
writing POR_EL0 directly than unmapping/remapping the
On Mon, Oct 21, 2024 at 06:19:38PM +0100, Will Deacon wrote:
> On Mon, Oct 21, 2024 at 04:30:04PM +0100, Catalin Marinas wrote:
> > On Mon, Oct 21, 2024 at 02:31:08PM +0100, Dave P Martin wrote:
> > > > > On Thu, Oct 17, 2024 at 02:39:04PM +0100, Kevin Brodsky wrote:
>
On Mon, Oct 21, 2024 at 02:31:08PM +0100, Dave P Martin wrote:
> > > On Thu, Oct 17, 2024 at 02:39:04PM +0100, Kevin Brodsky wrote:
> > >> This series is a follow-up to Joey's Permission Overlay Extension (POE)
> > >> series [1] that recently landed on mainline. The goal is to improve the
> > >> wa
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
On Thu, Oct 17, 2024 at 02:39:05PM +0100, Kevin Brodsky wrote:
> Commit 33f082614c34 ("arm64: signal: Allow expansion of the signal
> frame") introduced the BASE_SIGFRAME_SIZE macro but it has
> apparently never been used.
>
> Signed-off-by: Kevin Brodsky
Acked-by: Catalin Marinas
On Fri, 16 Aug 2024 16:32:43 +0100, Andre Przywara wrote:
> This fixes several smaller issues I faced when compiling the arm64
> kselftests on my machine.
> Patch 1 avoids a warning about the double definition of GNU_SOURCE,
> for the arm64/signal tests. Patch 2 fixes a typo, where the f8dp2 hwcap
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
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, 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 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
ff-by: Mark Brown
It looks fine to me now.
Reviewed-by: Catalin Marinas
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
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
> &
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 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 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 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
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: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
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 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(current) || task_gcs_el0_enabled(next))
> + gcsb_dsync();
> }
Ah, the comment turned up in this patch. It looks fine.
Reviewed-by: Catalin Marinas
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
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
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
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: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
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
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: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
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
tuation where leaving
> GCS enabled would be reasonable.
>
> Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Reviewed-by: Catalin Marinas
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
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 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 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: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: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
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
; +
> + }
> + }
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
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
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 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 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 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 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 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: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
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
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
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
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: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 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 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
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
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
>
> 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
n
Reviewed-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
gt; Reviewed-by: Thiago Jung Bauermann
> Signed-off-by: Mark Brown
Acked-by: Catalin Marinas
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
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: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
op of stack
> merker in the shadow stack */
s/merker/marker/
Otherwise:
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
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
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
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
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()
>
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 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 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 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 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 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 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, 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 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 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 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 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: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
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
1 - 100 of 121 matches
Mail list logo
