On Tue, Oct 15, 2019 at 12:30:15PM +0200, Ard Biesheuvel wrote:
> On Tue, 15 Oct 2019 at 12:25, Dave Martin wrote:
> >
> > On Mon, Oct 14, 2019 at 06:57:30PM +0200, Ard Biesheuvel wrote:
[...]
> > > All in-kernel NEON code checks whether the NEON is usable, so I'd
On Mon, Oct 14, 2019 at 06:57:30PM +0200, Ard Biesheuvel wrote:
> On Mon, 14 Oct 2019 at 17:50, Dave P Martin wrote:
> >
> > On Mon, Oct 14, 2019 at 04:45:40PM +0100, Suzuki K Poulose wrote:
> > >
> > >
> > > On 14/10/2019 15:52, Dave Martin wrote:
> &
On Mon, Oct 14, 2019 at 06:20:17PM +0100, Will Deacon wrote:
> On Mon, Oct 14, 2019 at 05:57:46PM +0100, Suzuki K Poulose wrote:
> > On 14/10/2019 17:43, Will Deacon wrote:
> > > On Mon, Oct 14, 2019 at 11:21:13AM +0100, Julien Grall wrote:
> > > > The kernel may not support SVE if
On Fri, Oct 11, 2019 at 06:28:43PM +0100, Suzuki K Poulose wrote:
>
>
> On 11/10/2019 15:21, Dave Martin wrote:
> >On Fri, Oct 11, 2019 at 01:13:18PM +0100, Suzuki K Poulose wrote: > Hi Dave
> >>
> >>On 11/10/2019 12:36, Dave Martin wrote:
> >>>On
or in userspace.
>
> The kernel should not used the register when CONFIG_SVE is disabled.
> Therefore, we only need to hidden them from the userspace.
>
> Signed-off-by: Julien Grall
> Fixes: 06a916feca2b ('arm64: Expose SVE2 features for userspace')
Reviewed-by: Dave Ma
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:
> > This patch adds the bare minimum required to expose the ARMv8.5
> > Branch Target Identification feature to userspace.
> >
> > By itself, th
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 Fri, Oct 11, 2019 at 04:40:43PM +0100, Mark Rutland wrote:
> > > On Fri, Oct 11, 2019 at 04:32:26PM +0100, Dave Martin wrote:
> > > >
On Fri, Oct 11, 2019 at 04:44:45PM +0100, Dave Martin wrote:
> On Fri, Oct 11, 2019 at 04:40:43PM +0100, Mark Rutland wrote:
> > On Fri, Oct 11, 2019 at 04:32:26PM +0100, Dave Martin wrote:
> > > On Fri, Oct 11, 2019 at 11:25:33AM -0400, Richard Henderson wrote:
> > > &
On Fri, Oct 11, 2019 at 04:40:43PM +0100, Mark Rutland wrote:
> On Fri, Oct 11, 2019 at 04:32:26PM +0100, Dave Martin wrote:
> > On Fri, Oct 11, 2019 at 11:25:33AM -0400, Richard Henderson wrote:
> > > On 10/11/19 11:10 AM, Mark Rutland wrote:
> > > > On Thu, Oct 10,
On Fri, Oct 11, 2019 at 11:31:02AM -0400, Richard Henderson wrote:
> On 10/10/19 2:44 PM, Dave Martin wrote:
> > #define PSR_IL_BIT (1 << 20)
> > -#define PSR_BTYPE_CALL (2 << PSR_BTYPE_SHIFT)
> > +
> > +/* Convenience names for the
On Fri, Oct 11, 2019 at 11:25:33AM -0400, Richard Henderson wrote:
> On 10/11/19 11:10 AM, Mark Rutland wrote:
> > On Thu, Oct 10, 2019 at 07:44:33PM +0100, Dave Martin wrote:
> >> @@ -730,6 +730,11 @@ static void setup_return
> >>regs->regs[29] = (unsigned long
[Add Kconfig dependency on CONFIG_ARM64_PTR_AUTH]
Signed-off-by: Dave Martin
---
This one could use some discussion.
Two conforming hardware implementations containing BTI could nonetheless
have incompatible Pointer auth implementations, meaning that we expose
BTI to userspace but not Pointer
Signed-off-by: Dave Martin
---
Changes since v2:
* Fix Kconfig typo that claimed that Pointer authentication is part of
ARMv8.2. It's v8.3.
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 563dec5
Here are a couple of late-breaking fixups, which may be integrated in
the next posting.
The first is trivial; the second needs discussion.
Dave Martin (2):
squash! arm64: Basic Branch Target Identification support
squash! arm64: Basic Branch Target Identification support
arch/arm64
On Fri, Oct 11, 2019 at 02:19:48PM +0100, Alex Bennée wrote:
>
> Dave Martin writes:
>
> > Commit d71be2b6c0e1 ("arm64: cpufeature: Detect SSBS and advertise
> > to userspace") exposes ID_AA64PFR1_EL1 to userspace, but didn't
> > update the documentation to
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:
> > Since normal execution of any non-branch instruction resets the
> > PSTATE BTYPE field to 0, so do the same thing when emulating a
> >
On Fri, Oct 11, 2019 at 03:24:55PM +0100, Mark Rutland wrote:
> On Thu, Oct 10, 2019 at 07:44:40PM +0100, Dave Martin wrote:
> > Since normal execution of any non-branch instruction resets the
> > PSTATE BTYPE field to 0, so do the same thing when emulating a
> >
On Fri, Oct 11, 2019 at 01:13:18PM +0100, Suzuki K Poulose wrote: > Hi Dave
>
> On 11/10/2019 12:36, Dave Martin wrote:
> >On Thu, Oct 10, 2019 at 06:15:15PM +0100, Suzuki K Poulose wrote:
> >>The NO_FPSIMD capability is defined with scope SYSTEM, which implies
> >
On Thu, Oct 10, 2019 at 06:15:15PM +0100, Suzuki K Poulose wrote:
> The NO_FPSIMD capability is defined with scope SYSTEM, which implies
> that the "absence" of FP/SIMD on at least one CPU is detected only
> after all the SMP CPUs are brought up. However, we use the status
> of this capability for
On Thu, Oct 10, 2019 at 06:15:16PM +0100, Suzuki K Poulose wrote:
> We detect the absence of FP/SIMD after we boot the SMP CPUs, and by then
> we have kernel threads running already with TIF_FOREIGN_FPSTATE set which
> could be inherited by early userspace applications (e.g, modprobe triggered
>
: 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
---
arch/arm64/kernel/traps.c | 18 --
1 fil
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
---
arch/arm64/include
[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 v1:
* Add convenience
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
---
arch/arm64/kernel
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
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
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
---
Changes since v1:
* Configure SCTLR_EL1.BTx to disallow BR onto a PACIxSP instruction
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
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
-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
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
---
[Dropped Kees' Reviewed-by -- rework in parse_elf_property() needs
review.]
Changes since RFC v2:
* Rework parse_elf_property() for clearer
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
---
Changes since RFC v2:
* Fix struct gnu_property indentation to follow the linux coding style
---
fs
gABI
https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
[4] Git branch:
git://linux-arm.org/linux-dm.git arm64/bti/v2/head
http://linux-arm.org/git?p=linux-dm.git;a=shortlog;h=refs/heads/arm64/bti/v2/head
Dave Martin (12):
ELF: UAPI and Kconfig additions for ELF program properties
EL
On Fri, Aug 30, 2019 at 09:34:17AM +0100, Dave Martin wrote:
> On Fri, Aug 30, 2019 at 06:37:45AM +0100, Kees Cook wrote:
> > On Fri, Aug 23, 2019 at 06:23:40PM +0100, Dave Martin wrote:
> > > ELF program properties will needed for detecting whether to enable
> > > o
stack. So it
> would not be possible to clear TIF_SVE until the stack is initialized.
> From commit c02433dd6de3 ("arm64: split thread_info from task stack"),
> the thread_info is part of the task, so it should be valid to modify
> the flag from arch_dup_task_struct().
>
> Cc: sta...
On Mon, Sep 30, 2019 at 10:29:53AM -0400, Masayoshi Mizuma wrote:
> Hi Julien and Dave,
>
> On Mon, Sep 30, 2019 at 02:02:46PM +0100, Dave Martin wrote:
> > On Mon, Sep 30, 2019 at 01:23:18PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > O
sve_state
> >
> >Move child's sve_state = NULL and clearing TIF_SVE flag
> >to arch_dup_task_struct() so that the child doesn't free the
> >parent's one.
> >
> >Cc: sta...@vger.kernel.org
> >Fixes: bc0ee4760364 ("arm64/sve: Core task context handling"
y exists from v4.15, it may be helpful to specify that,
i.e., replace that Cc line with:
Cc: # 4.15.x-
Otherwise, I'm happy to see this applied, but I'd like somebody to
confirm that this change definitely fixes the bug.
Cheers
---Dave
[...]
> Fixes: bc0ee4760364 ("arm64/sve: Core task
On Fri, Sep 27, 2019 at 10:38:02AM -0400, Masayoshi Mizuma wrote:
> Hi Julien and Dave,
>
> Thank you for your comments!
> Dave's suggestion looks good for me, many thanks!
> I'll post it as v2.
Please add Fixes and Cc: stable tags as appropriate.
(I'm happy not to push this patch myself, but I
On Thu, Sep 26, 2019 at 03:08:46PM -0400, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> The system which has SVE feature crashed because of
> the memory pointed by task->thread.sve_state was destroyed
> by someone.
>
> That is because sve_state is freed while the forking the
> child
On Wed, Sep 04, 2019 at 05:50:06PM +0100, Kees Cook wrote:
> On Fri, Aug 30, 2019 at 09:34:18AM +0100, Dave Martin wrote:
> > Do you have any thoughts on Yu-Cheng Yu's comments? It would be nice to
> > early-terminate the scan if we can, but my feeling so far was that the
&g
[Kees, you have any thoughts on the error code issue? See below.]
On Tue, Sep 03, 2019 at 11:29:10PM +0100, Yu-cheng Yu wrote:
> On Mon, 2019-09-02 at 10:28 +0100, Dave Martin wrote:
> > On Fri, Aug 30, 2019 at 06:03:27PM +0100, Yu-cheng Yu wrote:
> > > On Fri, 2019-08-30 at
On Fri, Aug 30, 2019 at 06:03:27PM +0100, Yu-cheng Yu wrote:
> On Fri, 2019-08-30 at 09:34 +0100, Dave Martin wrote:
> > On Fri, Aug 30, 2019 at 06:37:45AM +0100, Kees Cook wrote:
> > > On Fri, Aug 23, 2019 at 06:23:40PM +0100, Dave Martin wrote:
> > > > ELF
On Fri, Aug 30, 2019 at 06:37:45AM +0100, Kees Cook wrote:
> On Fri, Aug 23, 2019 at 06:23:40PM +0100, Dave Martin wrote:
> > ELF program properties will needed for detecting whether to enable
> > optional architecture or ABI features for a new ELF process.
> >
> > Fo
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
---
Changes since RFC v1:
* Fix stupid typo in IS_ENABLED().
* Fix premature dereference of possibly-NULL phdr in
parse_elf_properties
Pull the basic ELF definitions from Yu-Cheng Yu's series.
Signed-off-by: Yu-cheng Yu
Signed-off-by: Dave Martin
---
This patch should be merged with the next patch.
I kept it seprate for now to document where this code came from.
Changes since RFC v1:
* Move struct gnu_property
: Alternate program property parser
https://lore.kernel.org/lkml/1566295063-7387-1-git-send-email-dave.mar...@arm.com/
Dave Martin (2):
ELF: UAPI and Kconfig additions for ELF program properties
ELF: Add ELF program property parsing support
fs/Kconfig.binfmt| 3 ++
fs/binfmt_elf.c
Hi there,
Can you clarify a couple of points about the SysV ABI Linux
Extensions [1] for me?
1) Can there be more than one NT_GNU_PROPERTY_TYPE_0 note in a valid
ELF file? I think the answer should be "no".
2) Is is permissible for an ELF ET_EXEC or ET_DYN file that contains
an
On Tue, Aug 20, 2019 at 10:40:54PM +0100, Yu-cheng Yu wrote:
> On Tue, 2019-08-20 at 10:57 +0100, Dave Martin wrote:
> > ELF program properties will needed for detecting whether to enable
> > optional architecture or ABI features for a new ELF process.
> >
> > Fo
Pull the basic ELF definitions from Yu-Cheng Yu's series.
Signed-off-by: Yu-cheng Yu
Signed-off-by: Dave Martin
---
This patch should be merged with the next patch.
I kept it seprate for now to document where this code came from.
---
fs/Kconfig.binfmt| 3 +++
include/uapi/linux
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 | 109 +++
fs/compat_binfmt_elf.c | 4 ++
include/linux/elf.h | 21
...@intel.com/
Dave Martin (2):
ELF: UAPI and Kconfig additions for ELF program properties
ELF: Add ELF program property parsing support
fs/Kconfig.binfmt| 3 ++
fs/binfmt_elf.c | 109 +++
fs/compat_binfmt_elf.c | 4 ++
include
out;
>
> /*
> - * Apart from PT_SVE_REGS_MASK, all PT_SVE_* flags are consumed by
> + * Apart from SVE_PT_REGS_MASK, all SVE_PT_* flags are consumed by
>* sve_set_vector_length(), which will also validate them for us:
> */
Thanks for spotting that.
Reviewed-by: Dave Martin
Cheers
---Dave
On Tue, Aug 06, 2019 at 02:29:16PM -0700, Nathan Huckleberry wrote:
> I'm not sure that we should disable a broken feature instead of
> attempting a fix.
>
> CONFIG_FUNCTION_GRAPH_TRACER is dependent on CONFIG_FRAME_POINTER and
> there have been reports by MediaTek that the frame pointer unwinder
On Fri, Aug 02, 2019 at 10:27:30AM -0700, Nathan Huckleberry wrote:
> You're right. Would pushing an extra register be an adequate fix?
Would forcing CONFIG_ARM_UNWIND=y for clang work as an alternative to
this?
Assuming clang supports -funwind-tables or equivalent, this may just
work.
[...]
On Fri, Jul 12, 2019 at 01:20:42PM +0100, Phil Elwell wrote:
> Hi Rogier,
>
> On 12/07/2019 13:10, Rogier Wolff wrote:
> > On Fri, Jul 12, 2019 at 12:21:05PM +0100, Dave Martin wrote:
> >> diff --git a/drivers/tty/serial/amba-pl011.c
> >> b/drivers/tty/seria
On Thu, Jul 11, 2019 at 02:45:32PM +0100, Phil Elwell wrote:
> pl011_tx_chars takes a "from_irq" parameter to reduce the number of
> register accesses. When from_irq is true the function assumes that the
> FIFO is half empty and writes up to half a FIFO's worth of bytes
> without polling the FIFO
On Fri, Jun 28, 2019 at 10:22:03AM -0700, Yu-cheng Yu wrote:
> This patch was part of the Intel Control-flow Enforcement (CET) series at:
>
> https://lkml.org/lkml/2019/6/6/1014.
>
> In the discussion, we decided to look at only an ELF header's
> PT_GNU_PROPERTY, which is a shortcut pointing
On Thu, Jun 27, 2019 at 12:59:07PM +0100, Vincenzo Frascino wrote:
> On 6/27/19 12:27 PM, Dave Martin wrote:
> > On Thu, Jun 27, 2019 at 11:57:36AM +0100, Vincenzo Frascino wrote:
[...]
> >> Disassembly of section .text:
> >> show_it:
> >>
On Thu, Jun 27, 2019 at 11:57:36AM +0100, Vincenzo Frascino wrote:
> Hi Dave,
>
> Overall, I want to thank you for bringing out the topic. It helped me to
> question some decisions and make sure that we have no holes left in
> the approach.
Fair enough.
This is really just a nasty compiler
On Wed, Jun 26, 2019 at 08:01:58PM +0100, Vincenzo Frascino wrote:
[...]
> On 6/26/19 5:14 PM, Dave Martin wrote:
> > On Wed, Jun 26, 2019 at 02:27:59PM +0100, Vincenzo Frascino wrote:
> >> Hi Dave,
> >>
> >> On 25/06/2019 16:33, Dave Martin wrote:
> >&
On Wed, Jun 26, 2019 at 02:27:59PM +0100, Vincenzo Frascino wrote:
> Hi Dave,
>
> On 25/06/2019 16:33, Dave Martin wrote:
> > On Fri, Jun 21, 2019 at 10:52:31AM +0100, Vincenzo Frascino wrote:
> >> To take advantage of the commonly defined vdso interface for
> >&g
On Fri, Jun 21, 2019 at 10:52:31AM +0100, Vincenzo Frascino wrote:
> To take advantage of the commonly defined vdso interface for
> gettimeofday the architectural code requires an adaptation.
>
> Re-implement the gettimeofday vdso in C in order to use lib/vdso.
>
> With the new implementation
bit more explicit that we copied defined symbols, in commit
> and code.
> - Use Fixes: tag in commit message
>
> Thanks to Dave Martin and Will Deacon for the review.
>
> ---
> arch/arm64/include/uapi/asm/ptrace.h | 8 +++-
> 1 file changed, 3 insertions(+), 5 del
On Mon, Jun 17, 2019 at 02:20:40PM +0200, Thomas Gleixner wrote:
> On Mon, 17 Jun 2019, Florian Weimer wrote:
> > * Dave Martin:
> > > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> > >> We can probably check PT_GNU_PROPERTY first, and fallb
On Thu, Jun 13, 2019 at 06:38:01PM +0200, Anisse Astier wrote:
> Otherwise this will create userspace build issues for any program
> (strace, qemu) that includes both (with musl libc) and
> (which then includes ), like this:
>
> error: redefinition of 'struct prctl_mm_map'
>struct
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> From: Catalin Marinas
>
> It is not desirable to relax the ABI to allow tagged user addresses into
> the kernel indiscriminately. This patch introduces a prctl() interface
> for enabling or disabling the tagged ABI with a global
On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> Hi Catalin,
>
> On 12/06/2019 16:35, Catalin Marinas wrote:
> > Hi Vincenzo,
> >
> > Some minor comments below but it looks fine to me overall. Cc'ing
> > Szabolcs as well since I'd like a view from the libc people.
> >
>
>
On Thu, Jun 13, 2019 at 01:28:21PM +0100, Catalin Marinas wrote:
> On Thu, Jun 13, 2019 at 12:37:32PM +0100, Dave P Martin wrote:
> > On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
> > > On 12/06/2019 16:35, Catalin Marinas wrote:
> > > > On Wed, Jun 12, 2019 at 03:21:10PM
On Wed, Jun 12, 2019 at 12:04:01PM -0700, Yu-cheng Yu wrote:
> On Wed, 2019-06-12 at 10:32 +0100, Dave Martin wrote:
> > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> > > On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote:
> > > > On Mon, Ju
On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> On Tue, 2019-06-11 at 12:41 +0100, Dave Martin wrote:
> > On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote:
> > > * Yu-cheng Yu:
> > >
> > > > To me, looking at PT_GNU_PROP
isable-warning so that it gets disabled for GCC and does nothing
> for Clang.
>
> Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
> Link: https://github.com/ClangBuiltLinux/linux/issues/511
> Reported-by: Qian Cai
> Acked-by: Dave Martin
>
ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift")
> Link: https://github.com/ClangBuiltLinux/linux/issues/511
> Reported-by: Qian Cai
> Signed-off-by: Nathan Chancellor
FWIW,
Acked-by: Dave Martin
Cheers
---Dave
> ---
> arch/arm64/Makefile | 2 +-
> 1
On Fri, Jun 07, 2019 at 08:40:10AM -0700, Nathan Chancellor wrote:
> On Fri, Jun 07, 2019 at 11:26:11AM -0400, Qian Cai wrote:
> > On Fri, 2019-06-07 at 16:25 +0100, Will Deacon wrote:
> > > On Fri, Jun 07, 2019 at 11:22:45AM -0400, Qian Cai wrote:
> > > > The linux-next commit "arm64: Silence gcc
On Thu, Jun 06, 2019 at 10:34:22AM -0700, Yu-cheng Yu wrote:
> On Thu, 2019-06-06 at 18:23 +0100, Dave Martin wrote:
> > On Thu, Jun 06, 2019 at 06:11:56PM +0100, Catalin Marinas wrote:
> > > On Fri, May 24, 2019 at 03:53:06PM +0100, Dave P Martin wrote:
> > > > On F
On Thu, Jun 06, 2019 at 06:11:56PM +0100, Catalin Marinas wrote:
> On Fri, May 24, 2019 at 03:53:06PM +0100, Dave P Martin wrote:
> > On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> > > On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrot
On Tue, May 28, 2019 at 06:18:16PM +0530, Amit Daniel Kachhap wrote:
> Hi Dave,
[...]
> >Were you planning to repost this?
> >
> >Alternatively, I can fix up the diagnostic messages discussed here and
> >post it together with the SVE support. I'll do that locally for now,
> >but let me know
On Fri, May 24, 2019 at 04:38:48PM +0100, Mark Rutland wrote:
> On Fri, May 24, 2019 at 03:53:06PM +0100, Dave Martin wrote:
> > On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> > > On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrote:
> > > > +
On Fri, May 24, 2019 at 02:02:17PM +0100, Mark Rutland wrote:
> Hi Dave,
>
> This generally looks good, but I have a few comments below.
>
> On Fri, May 24, 2019 at 11:25:29AM +0100, Dave Martin wrote:
> > +#define arch_calc_vm_prot_bits(prot, pkey) arm64_calc_vm_prot_b
to stash information for later use.
Signed-off-by: Dave Martin
---
fs/binfmt_elf.c | 26 +-
include/linux/elf.h | 15 +++
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 18015fc..32c9c13 100644
--- a/fs
).
So 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
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_GUARDED
as appropriate.
Signed-off-by: Dave
[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
---
arch/arm64/include/asm/ptrace.h | 4
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
---
Documentation/arm64/cpu-feature-registers.txt | 16
1 file c
-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 abd238d..ad3c6e5 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm
to be annotated 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
---
Notes:
* An #ifdef CONFIG_ARM64_BTI controls the cpufeature field visibility
-flow Enforcement series; the original
patch is here: https://lkml.org/lkml/2018/11/20/205. Dave Martin responded
that ARM recently introduced new features to NT_GNU_PROPERTY_TYPE_0 with
properties closely modelled on GNU_PROPERTY_X86_FEATURE_1_AND, and it is
logical to split out the generic part
landing pads.
Dave Martin (7):
mm: Reserve asm-generic prot flag 0x10 for arch use
arm64: docs: cpu-feature-registers: Document ID_AA64PFR1_EL1
arm64: Basic Branch Target Identification support
elf: Parse program properties before destroying the old process
elf: Allow arch to tweak
vide a means to access post-mortem.
I just dived in on this single patch, so I may be missing something more
fundamental, or just being pedantic...
Cheers
---Dave
> Cc: sta...@vger.kernel.org
> Cc: Dave Martin
> Cc: James Morse
> Cc: Will Deacon
> Fixes: af40ff687bc9 (&qu
On Tue, May 21, 2019 at 03:48:56PM -0300, Jason Gunthorpe wrote:
> On Fri, May 17, 2019 at 03:49:31PM +0100, Catalin Marinas wrote:
>
> > The tagged pointers (whether hwasan or MTE) should ideally be a
> > transparent feature for the application writer but I don't think we can
> > solve it
On Wed, May 01, 2019 at 04:09:02PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the kvm-ppc tree got a conflict in:
>
> include/uapi/linux/kvm.h
>
> between commits:
>
> 555f3d03e7fb ("KVM: arm64: Add a capability to advertise SVE support")
> a243c16d18be
On Fri, Apr 26, 2019 at 04:06:02PM +0100, Julien Grall wrote:
> Hi,
>
> On 26/04/2019 15:52, Dave Martin wrote:
> >On Fri, Apr 26, 2019 at 03:37:40PM +0100, Julien Grall wrote:
> >>When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> >>the ker
On Fri, Apr 26, 2019 at 03:37:40PM +0100, Julien Grall wrote:
> When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> the kernel may be able to use FPSIMD/SVE. This is for instance the case
> for crypto code.
>
> Any use of FPSIMD/SVE in the kernel are clearly marked by using
On Thu, Apr 25, 2019 at 06:12:59PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 25/04/2019 17:39, Dave Martin wrote:
> >On Thu, Apr 25, 2019 at 04:57:26PM +0100, Julien Grall wrote:
> >>Hi Dave,
> >>
> >>On 24/04/2019 14:17, Dave Martin wrote:
> >&g
On Thu, Apr 25, 2019 at 04:57:26PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 24/04/2019 14:17, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
> >>diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> >>
On Thu, Apr 25, 2019 at 01:37:40PM +0100, Julien Grall wrote:
> Hi Dave,
>
> On 24/04/2019 14:17, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 02:57:18PM +0100, Julien Grall wrote:
> >>tent-Length: 4295
> >>Lines: 128
> >>
> >>The only extern
On Wed, Apr 24, 2019 at 11:27:50AM +0530, Amit Daniel Kachhap wrote:
> Hi,
>
> On 4/23/19 9:14 PM, Dave Martin wrote:
> >On Tue, Apr 23, 2019 at 10:12:34AM +0530, Amit Daniel Kachhap wrote:
> >>A per vcpu flag is added to check if pointer authentication is
On Tue, Apr 23, 2019 at 02:57:19PM +0100, Julien Grall wrote:
> When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of
> the kernel may be able to use FPSIMD/SVE. This is for instance the case
> for crypto code.
>
> Any use of FPSIMD/SVE in the kernel are clearly marked by using
> +extern void fpsimd_save_and_flush_cpu_state(void);
Nit: You could drop this blank line: these are all "state maintenance"
operations, roughly speaking.
But don't bother unless you respin for some other reason.
[...]
With or without that,
Reviewed-by: Dave Martin
Cheers
---Dave
macros defined in the headers are not in sync and should be replaced
> from the upstream.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
>
> Changes since v9:
> * Added a error check for both enable-ptrauth and disable-ptrauth
> option.
> * Make the error explicit when en
101 - 200 of 1073 matches
Mail list logo
