On Thu, Feb 04, 2021 at 03:23:34PM +, Will Deacon wrote:
> On Mon, Feb 01, 2021 at 11:40:10AM -0800, Andrei Vagin wrote:
> > ip/r12 for AArch32 and x7 for AArch64 is used to indicate whether or not
> > the stop has been signalled from syscall entry or syscall exit. This
> > means that:
> >
>
> generic definition.
>
> Signed-off-by: Chang S. Bae
> Reviewed-by: Len Brown
> Cc: Carlos O'Donell
> Cc: Dave Martin
> Cc: libc-al...@sourceware.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: l
On Tue, Jan 19, 2021 at 02:06:35PM -0800, Andrei Vagin wrote:
> ip/r12 for AArch32 and x7 for AArch64 is used to indicate whether or not
> the stop has been signalled from syscall entry or syscall exit. This
> means that:
>
> - Any writes by the tracer to this register during the stop are
>
On Tue, Jan 19, 2021 at 02:06:36PM -0800, Andrei Vagin wrote:
> This is an alternative to NT_PRSTATUS that clobbers ip/r12 on AArch32,
> x7 on AArch64 when a tracee is stopped in syscall entry or syscall exit
> traps.
>
> Signed-off-by: Andrei Vagin
This approach looks like it works, though I
On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote:
> On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
> >
> > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > > Kernel mode NEON can be used in task or softirq context, but only in
> &g
On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> Kernel mode NEON can be used in task or softirq context, but only in
> a non-nesting manner, i.e., softirq context is only permitted if the
> interrupt was not taken at a point where the kernel was using the NEON
> in task context.
> >> arm_spe_pkt_snprintf() which is used to wrap up the complex logics, and
> > >> it's used by the caller arm_spe_pkt_desc().
> > >>
> > >> This patch also moves the variable 'blen' as the function's local
> > >> variable, this allows to remo
rror at the end of arm_spe_pkt_desc().
>
> This patch changes the caller arm_spe_dump() to respect the updated
> return value semantics of arm_spe_pkt_desc().
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
> Reviewed-by: Andre Przywara
> ---
>
On Wed, Nov 11, 2020 at 03:53:20PM +, Dave Martin wrote:
> On Wed, Nov 11, 2020 at 07:11:33AM +, Leo Yan wrote:
> > When outputs strings to the decoding buffer with function snprintf(),
> > SPE decoder needs to detects if any error returns from snprintf() and if
> >
the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
> Reviewed-by: Andre Przywara
Mostly looks fine to me now, thought there are a few potentionalu
issues -- commen
On Thu, Oct 29, 2020 at 11:02:22AM +, Catalin Marinas via Libc-alpha wrote:
> On Tue, Oct 27, 2020 at 02:15:22PM +, Dave P Martin wrote:
> > I also wonder whether we actually care whether the pages are marked
> > executable or not here; probably the flags can just be independent. This
> >
On Tue, Nov 03, 2020 at 06:51:01AM +, Leo Yan wrote:
> On Mon, Nov 02, 2020 at 04:25:36PM +0000, Dave Martin wrote:
> > On Fri, Oct 30, 2020 at 02:57:23AM +, Leo Yan wrote:
> > > From: Andre Przywara
> > >
> > > When SPE records a physical addres
On Tue, Nov 03, 2020 at 10:13:49AM +, André Przywara wrote:
> On 03/11/2020 06:40, Leo Yan wrote:
>
> Hi Dave, Leo,
>
> > On Mon, Nov 02, 2020 at 05:06:53PM +, Dave Martin wrote:
> >> On Fri, Oct 30, 2020 at 02:57:09AM +, Leo Yan wrote:
> >>&g
in a flow, the error is a cumulative value and simply
> returns its final value.
>
> This patch also moves the variable 'blen' as the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by: Dave Martin
&g
> #define SPE_ADDR_PKT_GET_NS(v) (((v) & BIT_ULL(63)) >>
> 63)
> #define SPE_ADDR_PKT_GET_EL(v) (((v) & GENMASK_ULL(62,
> 61)) >> 61)
> +#define SPE_ADDR_PKT_GET_CH(v) (((v) & BIT_ULL(62)) >>
> 62)
> +#define SPE_ADDR_PKT_GET_PAT(v) (((v) & GENMASK_ULL(59,
> 56)) >> 56)
These seem to match the spec.
With or without addressing the nit above:
Reviewed-by: Dave Martin
[...]
Cheers
---Dave
On Mon, Oct 26, 2020 at 05:39:42PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> On 10/26/20 12:52 PM, Dave Martin wrote:
> >On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> >>The 10/26/2020 16:24, Dave Martin via Libc-alp
;
> This patch also moves the variable 'blen' as the function's local
> variable, this allows to remove the unnecessary braces and improve the
> readability.
>
> Suggested-by: Dave Martin
> Signed-off-by: Leo Yan
> Reviewed-by: Andre Przywara
> ---
> .../arm-spe-decoder/a
On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
> * Dave Martin via Libc-alpha:
>
> > Would it now help to add something like:
> >
> > int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> > {
> > int re
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
> The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
> > Unrolling this discussion a bit, this problem comes from a few sources:
> >
> > 1) systemd is trying to implement a policy tha
On Wed, Oct 21, 2020 at 10:44:46PM -0500, Jeremy Linton via Libc-alpha wrote:
> Hi,
>
> There is a problem with glibc+systemd on BTI enabled systems. Systemd
> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
> PROT_EXEC changes. Glibc enables BTI only on segments which are
On Mon, Oct 26, 2020 at 02:52:46PM +, Catalin Marinas via Libc-alpha wrote:
> On Sat, Oct 24, 2020 at 02:01:30PM +0300, Topi Miettinen wrote:
> > On 23.10.2020 12.02, Catalin Marinas wrote:
> > > On Thu, Oct 22, 2020 at 01:02:18PM -0700, Kees Cook wrote:
> > > > Regardless, it makes sense to
On Thu, Oct 08, 2020 at 10:43:50PM +, Bae, Chang Seok wrote:
> On Wed, 2020-10-07 at 11:05 +0100, Dave Martin wrote:
> > On Tue, Oct 06, 2020 at 05:45:24PM +, Bae, Chang Seok wrote:
> > > On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> > > > On Tue, Se
On Wed, Oct 07, 2020 at 06:30:03AM -0700, H.J. Lu wrote:
> On Wed, Oct 7, 2020 at 3:47 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 10:44:14AM -0700, H.J. Lu wrote:
[...]
> > > I updated my glibc patch to add both _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.
> > >
On Tue, Oct 06, 2020 at 10:44:14AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 9:55 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 08:34:06AM -0700, H.J. Lu wrote:
> > > On Tue, Oct 6, 2020 at 8:25 AM Dave Martin wrote:
> > > >
> > > > O
On Tue, Oct 06, 2020 at 11:30:42AM -0700, Dave Hansen wrote:
> On 10/6/20 10:00 AM, Dave Martin wrote:
> > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> >> On 10/6/20 8:25 AM, Dave Martin wrote:
> >>> Or are people reporting real stack overruns o
On Tue, Oct 06, 2020 at 08:21:00PM +0200, Florian Weimer wrote:
> * Dave Martin via Libc-alpha:
>
> > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> >> On 10/6/20 8:25 AM, Dave Martin wrote:
> >> > Or are people reporting real stack overruns on x
On Tue, Oct 06, 2020 at 05:45:24PM +, Bae, Chang Seok wrote:
> On Mon, 2020-10-05 at 14:42 +0100, Dave Martin wrote:
> > On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> > >
> > > +/*
> > > + * The FP state frame contains an XSAVE buffer
ypto_skcipher_encrypt+0x50/0x84
> test_skcipher_vec_cfg+0x224/0x5f0
> test_skcipher+0xbc/0x120
> alg_test_skcipher+0xa0/0x1b0
> alg_test+0x3dc/0x47c
> cryptomgr_test+0x38/0x60
>
> Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly
> fun
On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:
> On 10/6/20 8:25 AM, Dave Martin wrote:
> > Or are people reporting real stack overruns on x86 today?
>
> We have real overruns. We have ~2800 bytes of XSAVE (regisiter) state
> mostly from AVX-512, and a 2048 byte M
On Tue, Oct 06, 2020 at 08:34:06AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 8:25 AM Dave Martin wrote:
> >
> > On Tue, Oct 06, 2020 at 05:12:29AM -0700, H.J. Lu wrote:
> > > On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> > > >
> > > > O
On Tue, Oct 06, 2020 at 08:18:03AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 5:12 AM H.J. Lu wrote:
> >
> > On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> > >
> > > On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> > > > On M
On Tue, Oct 06, 2020 at 05:12:29AM -0700, H.J. Lu wrote:
> On Tue, Oct 6, 2020 at 2:25 AM Dave Martin wrote:
> >
> > On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> > > On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote:
> > > >
> > > > O
On Tue, Oct 06, 2020 at 11:25:11AM +0100, Catalin Marinas wrote:
> On Tue, Oct 06, 2020 at 11:01:21AM +0100, Dave P Martin wrote:
> > On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> > > On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > > > The AES code uses a 'br
On Tue, Oct 06, 2020 at 09:27:48AM +0100, Will Deacon wrote:
> On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
> > The AES code uses a 'br x7' as part of a function called by
> > a macro. That branch needs a bti_j as a target. This results
> > in a panic as seen below. Instead of
On Mon, Oct 05, 2020 at 02:24:47PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
> >On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
> >>
> >>The AES code uses a 'br x7' as part of a function called by
> >>a macro, that ends up needing a BTI_J as a target.
> >
On Mon, Oct 05, 2020 at 10:17:06PM +0100, H.J. Lu wrote:
> On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote:
> >
> > On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote:
> > > During signal entry, the kernel pushes data onto the normal userspace
> > > st
On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote:
> During signal entry, the kernel pushes data onto the normal userspace
> stack. On x86, the data pushed onto the user stack includes XSAVE state,
> which has grown over time as new features and larger registers have been
> added to the
On Tue, Sep 29, 2020 at 01:57:43PM -0700, Chang S. Bae wrote:
> Signal frames do not have a fixed format and can vary in size when a number
> of things change: support XSAVE features, 32 vs. 64-bit apps. Add the code
> to support a runtime method for userspace to dynamically discover how large
> a
On Wed, Sep 30, 2020 at 07:04:53PM +0800, Leo Yan wrote:
[...]
> > > > > >> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > >> b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > >> index a033f34846a6..f0c369259554 100644
> > > > > >> ---
On Tue, Sep 29, 2020 at 10:19:02AM +0800, Leo Yan wrote:
> On Mon, Sep 28, 2020 at 03:47:56PM +0100, Dave Martin wrote:
> > On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> > > On 28/09/2020 14:21, Dave Martin wrote:
> > >
> > > Hi Dave,
>
On Tue, Sep 29, 2020 at 10:19:02AM +0800, Leo Yan wrote:
> On Mon, Sep 28, 2020 at 03:47:56PM +0100, Dave Martin wrote:
> > On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> > > On 28/09/2020 14:21, Dave Martin wrote:
> > >
> > > Hi Dave,
>
On Mon, Sep 28, 2020 at 02:59:34PM +0100, André Przywara wrote:
> On 28/09/2020 14:21, Dave Martin wrote:
>
> Hi Dave,
>
> > On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
> >> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
>
On Tue, Sep 22, 2020 at 11:12:25AM +0100, Andre Przywara wrote:
> The Scalable Vector Extension (SVE) is an ARMv8 architecture extension
> that introduces very long vector operations (up to 2048 bits).
(8192, in fact, though don't expect to see that on real hardware any
time soon... qemu and the
On Tue, Sep 15, 2020 at 04:18:28PM +0100, Boyan Karatotev wrote:
> On 07/09/2020 11:27 am, Dave Martin wrote:
> > On Thu, Sep 03, 2020 at 11:20:25AM +0100, Boyan Karatotev wrote:
> >> On 02/09/2020 18:00, Dave Martin wrote:
> >>> On Fri, Aug 28, 2020 at 02:16:05P
On Thu, Sep 03, 2020 at 11:48:37AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 18:08, Dave Martin wrote:
> > On Mon, Aug 31, 2020 at 12:04:49PM +0100, Boyan Karatotev wrote:
> >> +/*
> >> + * fork() does not change keys. Only exec() does so call a worker program.
>
On Thu, Sep 03, 2020 at 10:46:33AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 17:48, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:02PM +0100, Boyan Karatotev wrote:
> >> Pointer Authentication (PAuth) is a security feature introduced in ARMv8.3.
> >> It intr
On Thu, Sep 03, 2020 at 11:20:25AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 18:00, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:05PM +0100, Boyan Karatotev wrote:
> >> Kernel documentation states that it will change PAuth keys on exec() calls.
> >>
On Thu, Sep 03, 2020 at 11:12:02AM +0100, Boyan Karatotev wrote:
> On 02/09/2020 17:49, Dave Martin wrote:
> > On Fri, Aug 28, 2020 at 02:16:03PM +0100, Boyan Karatotev wrote:
> >> PAuth signs and verifies return addresses on the stack. It does so by
> >> inserting a
On Mon, Aug 31, 2020 at 12:04:49PM +0100, Boyan Karatotev wrote:
> Kernel documentation states that it will change PAuth keys on exec() calls.
>
> Verify that all keys are correctly switched to new ones.
>
> Cc: Shuah Khan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Reviewed-by: Vincenzo
On Fri, Aug 28, 2020 at 02:16:05PM +0100, Boyan Karatotev wrote:
> Kernel documentation states that it will change PAuth keys on exec() calls.
>
> Verify that all keys are correctly switched to new ones.
>
> Cc: Shuah Khan
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Boyan
On Fri, Aug 28, 2020 at 02:16:03PM +0100, Boyan Karatotev wrote:
> PAuth signs and verifies return addresses on the stack. It does so by
> inserting a Pointer Authentication code (PAC) into some of the unused top
> bits of an address. This is achieved by adding paciasp/autiasp instructions
> at
On Fri, Aug 28, 2020 at 02:16:02PM +0100, Boyan Karatotev wrote:
> Pointer Authentication (PAuth) is a security feature introduced in ARMv8.3.
> It introduces instructions to sign addresses and later check for potential
> corruption using a second modifier value and one of a set of keys. The
>
On Tue, Sep 01, 2020 at 11:11:37AM -0700, Dave Hansen wrote:
> On 9/1/20 10:45 AM, Andy Lutomirski wrote:
> >>> For arm64 (and sparc etc.) we continue to use the regular mmap/mprotect
> >>> family of calls. One or two additional arch-specific mmap flags are
> >>> sufficient for now.
> >>>
> >>>
On Thu, Aug 27, 2020 at 06:26:11AM -0700, H.J. Lu wrote:
> On Wed, Aug 26, 2020 at 12:57 PM Dave Hansen wrote:
> >
> > On 8/26/20 11:49 AM, Yu, Yu-cheng wrote:
> > >> I would expect things like Go and various JITs to call it directly.
> > >>
> > >> If we wanted to be fancy and add a potentially
On Wed, Aug 26, 2020 at 06:51:48PM +0200, Florian Weimer wrote:
> * Dave Martin:
>
> > On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> >> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> >> >
On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> I think this is more arch-specific. Even if it becomes a new syscall,
> we still need to pass the same parameters.
> >>>
> >>>Right, but
On Mon, Jul 06, 2020 at 10:36:28AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 06, 2020 at 06:05:57PM +0100, Dave Martin wrote:
> > On Mon, Jul 06, 2020 at 09:34:55AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote:
> >
On Mon, Jul 06, 2020 at 07:35:11PM +0100, Will Deacon wrote:
> On Mon, Jul 06, 2020 at 05:08:20PM +0100, Dave Martin wrote:
> > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote:
> > > diff --git a/arch/arm64/include/asm/rwonce.h
> > > b/arch/arm64/include/
On Sat, Jul 04, 2020 at 04:02:46PM +0200, Greg Kroah-Hartman wrote:
> Here is a tiny new syscall, readfile, that makes it simpler to read
> small/medium sized files all in one shot, no need to do open/read/close.
> This is especially helpful for tools that poke around in procfs or
> sysfs, making
On Fri, Jul 03, 2020 at 01:51:10PM -0700, Randy Dunlap wrote:
> Drop the doubled word "for".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infrad
On Mon, Jul 06, 2020 at 09:34:55AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote:
> > On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote:
> > > On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote:
> > > &
On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote:
> When building with LTO, there is an increased risk of the compiler
> converting an address dependency headed by a READ_ONCE() invocation
> into a control dependency and consequently allowing for harmful
> reordering by the CPU.
>
>
On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote:
> On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote:
> > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote:
> > > When building with LTO, there is an increased risk of the compiler
> > > converting an address
On Wed, Jun 24, 2020 at 06:40:48PM +0200, Ard Biesheuvel wrote:
> On Wed, 24 Jun 2020 at 18:29, Dave Martin wrote:
> >
> > On Wed, Jun 24, 2020 at 05:48:41PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 24 Jun 2020 at 17:45, Kees Cook wrote:
> > > >
> > &g
On Wed, Jun 24, 2020 at 05:48:41PM +0200, Ard Biesheuvel wrote:
> On Wed, 24 Jun 2020 at 17:45, Kees Cook wrote:
> >
> > On Wed, Jun 24, 2020 at 05:31:06PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 24 Jun 2020 at 17:21, Kees Cook wrote:
> > > >
> > > > On Wed, Jun 24, 2020 at 12:46:32PM +0200,
On Wed, Jun 24, 2020 at 04:26:46PM +0100, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 02:48:55PM +0100, Dave Martin wrote:
> > On Wed, Jun 24, 2020 at 12:26:47PM +0100, Will Deacon wrote:
> > > On Wed, Jun 24, 2020 at 12:46:32PM +0200, Ard Biesheuvel wrote:
> > > >
On Wed, Jun 24, 2020 at 12:26:47PM +0100, Will Deacon wrote:
> On Wed, Jun 24, 2020 at 12:46:32PM +0200, Ard Biesheuvel wrote:
> > On Wed, 24 Jun 2020 at 12:44, Will Deacon wrote:
> > > On Tue, Jun 23, 2020 at 09:44:11PM -0700, Kees Cook wrote:
> > > > On Tue, Jun 23, 2020 at 08:31:42PM -0700,
On Wed, Jun 24, 2020 at 10:38:48AM +0100, Catalin Marinas wrote:
> On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote:
> > On Wed, 17 Jun 2020 at 13:39, Steven Price wrote:
> > > These patches add support to KVM to enable MTE within a guest. It is
> > > based on Catalin's v4 MTE user
On Thu, Jun 11, 2020 at 03:11:02PM +0100, Catalin Marinas wrote:
> On Thu, Jun 11, 2020 at 06:42:12PM +0900, Wooyeon Kim wrote:
> > I am in charge of camera driver development in Samsung S.LSI division.
> >
> > In order to guarantee real time processing such as Camera 3A algorithm in
> > current
On Fri, Jun 05, 2020 at 11:37:05AM +0100, Mark Rutland wrote:
> Hi Wooyeon,
>
> There are a *lot* of people Cc' here, many of whomo will find this
> irrelevant. Please try to keep the Cc list constrained to a reasonable
> number of interested parties.
>
> On Fri, Jun 05, 2020 at 04:30:52PM
On Mon, Jun 01, 2020 at 05:40:28AM -0400, Keno Fischer wrote:
> On Mon, Jun 1, 2020 at 5:23 AM Dave Martin wrote:
> > > > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> > > > syscall at the syscall enter stop, then modifying the regs at th
On Mon, Jun 01, 2020 at 05:23:01AM -0400, Keno Fischer wrote:
> On Mon, Jun 1, 2020 at 5:14 AM Dave Martin wrote:
> > Can you explain why userspace would write a changed value for x7
> > but at the same time need that new to be thrown away?
>
> The discarding behavior
On Sun, May 31, 2020 at 12:20:51PM -0400, Keno Fischer wrote:
> > Can't PTRACE_SYSEMU be emulated by using PTRACE_SYSCALL, cancelling the
> > syscall at the syscall enter stop, then modifying the regs at the
> > syscall exit stop?
>
> Yes, it can. The idea behind SYSEMU is to be able to save half
On Sun, May 31, 2020 at 12:13:18PM -0400, Keno Fischer wrote:
> > Keno -- are you planning to send out a patch? You previously spoke about
> > implementing this using PTRACE_SETOPTIONS.
>
> Yes, I'll have a patch for you. Though I've come to the conclusion
> that introducing a new regset is
On Tue, May 26, 2020 at 09:45:05PM +0100, Will Deacon wrote:
> On Tue, 26 May 2020 10:31:14 -0700, Nick Desaulniers wrote:
> > Custom toolchains that modify the default target to -mthumb cannot
It's probably too late to water this down, but it's unfortunate to have
this comment in the upstream
On Wed, May 27, 2020 at 10:55:29AM +0100, Will Deacon wrote:
> On Sun, May 24, 2020 at 02:56:35AM -0400, Keno Fischer wrote:
> > Just ran into this issue again, with what I think may be most compelling
> > example yet why this is problematic:
> >
> > The tracee incurred a signal, we
On Mon, May 11, 2020 at 11:04:03PM +0100, Cristian Marussi wrote:
> Hi Dave
>
> thanks for the review first of all.
>
> On Wed, May 06, 2020 at 04:25:50PM +0100, Dave Martin wrote:
> > On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> > > Add co
On Thu, May 07, 2020 at 06:59:10PM +0530, Anshuman Khandual wrote:
> All HWCAP name arrays (i.e hwcap_str, compat_hwcap_str, compat_hwcap2_str)
> that are scanned for /proc/cpuinfo output are detached from their bit fild
> definitions making it difficult to corelate. This is also bit problematic
>
On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> Add core SCMI Notifications protocol-registration support: allow protocols
> to register their own set of supported events, during their initialization
> phase. Notification core can track multiple platform instances by their
>
Since normal execution of any non-branch instruction resets the
PSTATE BTYPE field to 0, so do the same thing when emulating a
trapped instruction.
Branches don't trap directly, so we should never need to assign a
non-zero value to BTYPE here.
Signed-off-by: Dave Martin
---
Changes since v2
Since normal execution of any non-branch instruction resets the
PSTATE BTYPE field to 0, so do the same thing when emulating a
trapped instruction.
Branches don't trap directly, so we should never need to assign a
non-zero value to BTYPE here.
Signed-off-by: Dave Martin
---
Changes since v2
to have the kernel do it
instead.
To this end, detect BTI support in the executable (or ELF
interpreter, as appropriate), via the
NT_GNU_PROGRAM_PROPERTY_TYPE_0 note, and tweak the initial prot
flags for the process' executable pages to include PROT_BTI as
appropriate.
Signed-off-by: Dave Martin
: Add condition code checks and IT advance")
Fixes: 6436b572 ("arm64: Fix single stepping in kernel traps")
Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Signed-off-by: Dave Martin
---
**NOTE**
Despite discussions on the v2 series to the effec
-off-by: Dave Martin
---
include/uapi/asm-generic/mman-common.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/asm-generic/mman-common.h
b/include/uapi/asm-generic/mman-common.h
index c160a53..81442d2 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm
Commit d71be2b6c0e1 ("arm64: cpufeature: Detect SSBS and advertise
to userspace") exposes ID_AA64PFR1_EL1 to userspace, but didn't
update the documentation to match.
Add it.
Signed-off-by: Dave Martin
---
Note to maintainers:
* This patch has been racing with various other attem
that this can be done in a generic way, add a hook
arch_elf_adjust_prot() to modify the prot flags as desired: arches
can select CONFIG_HAVE_ELF_PROT and implement their own backend
where necessary.
By default, leave the prot flags unchanged.
Signed-off-by: Dave Martin
---
fs/Kconfig.binfmt | 3
Pull the basic ELF definitions relating to the
NT_GNU_PROPERTY_TYPE_0 note from Yu-Cheng Yu's earlier x86 shstk
series.
Signed-off-by: Yu-cheng Yu
Signed-off-by: Dave Martin
---
fs/Kconfig.binfmt| 3 +++
include/linux/elf.h | 8
include/uapi/linux/elf.h | 1 +
3 files
the PT_PROGRAM_PROPERTY
phdrs entry (if any), and notify each property to the arch code.
For now, the added code is not used.
Signed-off-by: Dave Martin
---
fs/binfmt_elf.c | 127 +++
fs/compat_binfmt_elf.c | 4 ++
include/linux/elf.h | 19
Hoist the IT state handling code earlier in traps.c, to avoid
accumulating forward declarations.
No functional change.
Signed-off-by: Dave Martin
---
arch/arm64/kernel/traps.c | 101 ++
1 file changed, 49 insertions(+), 52 deletions(-)
diff --git
[11:10]) and
permitted classes of subsequent instruction are:
-- (BTYPE=0b00): any insn
jc (BTYPE=0b01): BTI jc, BTI j, BTI c, PACIxSP
-c (BYTPE=0b10): BTI jc, BTI c, PACIxSP
j- (BTYPE=0b11): BTI jc, BTI j
Signed-off-by: Dave Martin
---
Changes since v2:
* Split out
as such, just like any other function.
This blocks a relatively minor attack vector, but comforming
userspace will have the annotations anyway, so we may as well
enforce them.
Signed-off-by: Dave Martin
---
**NOTE**
Currently the generic code does not validate user-supplied prot bits
via
/wiki/Linux-Extensions-to-gABI
[3] Git branch:
git://linux-arm.org/linux-dm.git arm64/bti/v3/head
http://linux-arm.org/git?p=linux-dm.git;a=shortlog;h=refs/heads/arm64/bti/v3/head
Dave Martin (12):
ELF: UAPI and Kconfig additions for ELF program properties
ELF: Add ELF program property parsing
On Tue, Oct 15, 2019 at 05:49:05PM +0100, Dave Martin wrote:
> On Tue, Oct 15, 2019 at 05:42:04PM +0100, Mark Rutland wrote:
> > On Tue, Oct 15, 2019 at 04:21:09PM +0100, Dave Martin wrote:
> > > On Fri, Oct 11, 2019 at 04:24:53PM +0100, Mark Rutland wrote:
> > > >
On Fri, Oct 18, 2019 at 12:04:29PM +0100, Mark Rutland wrote:
> On Fri, Oct 11, 2019 at 03:47:43PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 03:21:58PM +0100, Mark Rutland wrote:
> > > On Thu, Oct 10, 2019 at 07:44:39PM +0100, Dave Martin wrote:
> > > >
On Fri, Oct 18, 2019 at 12:16:03PM +0100, Mark Rutland wrote:
> [adding mm folk]
>
> On Fri, Oct 11, 2019 at 06:20:15PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 04:10:29PM +0100, Mark Rutland wrote:
> > > On Thu, Oct 10, 2019 at 07:44:33PM +0100, Dave Martin
On Fri, Oct 18, 2019 at 12:10:03PM +0100, Mark Rutland wrote:
> On Fri, Oct 11, 2019 at 06:20:15PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 04:10:29PM +0100, Mark Rutland wrote:
> > > On Thu, Oct 10, 2019 at 07:44:33PM +0100, Dave Martin wrote:
> > > > +
On Fri, Oct 18, 2019 at 12:05:52PM +0100, Mark Rutland wrote:
> On Fri, Oct 11, 2019 at 05:42:00PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 05:01:13PM +0100, Dave Martin wrote:
> > > On Fri, Oct 11, 2019 at 04:44:45PM +0100, Dave Martin wrote:
> > > >
On Thu, Oct 17, 2019 at 01:42:37PM +0100, Suzuki K Poulose wrote:
> Hi Dave
>
> Thanks for the comments.
>
> On 11/10/2019 12:26, Dave Martin wrote:
> >On Thu, Oct 10, 2019 at 06:15:16PM +0100, Suzuki K Poulose wrote:
> >>We detect the absence of FP/S
On Tue, Oct 15, 2019 at 05:42:04PM +0100, Mark Rutland wrote:
> On Tue, Oct 15, 2019 at 04:21:09PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 04:24:53PM +0100, Mark Rutland wrote:
> > > On Thu, Oct 10, 2019 at 07:44:37PM +0100, Dave Martin wrote:
> &
On Fri, Oct 11, 2019 at 04:24:53PM +0100, Mark Rutland wrote:
> On Thu, Oct 10, 2019 at 07:44:37PM +0100, Dave Martin wrote:
> > Correct skipping of an instruction on AArch32 works a bit
> > differently from AArch64, mainly due to the different CPSR/PSTATE
> > semantics.
>
1 - 100 of 1073 matches
Mail list logo
