Re: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-02 Thread Ard Biesheuvel
2012/10/2 Kees Cook : >> If desired, additional restrictions can be imposed by using the >> security framework, e.g,, disallow non-final r-x mappings. > > Interesting; what kind of interface did you have in mind? > The 'interface' we use is a LSM .ko which registers handlers for mmap() and mprotec

Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-03 Thread Ard Biesheuvel
mainly intended for the dynamic linker, which sets up the address space on behalf of dynamic binaries. By using this flag, it can prevent exploited code from remapping read-only executable code or data sections read-write. Signed-off-by: Ard Biesheuvel --- arch/alpha/include/asm/mman.h |1

Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-04 Thread Ard Biesheuvel
2012/10/4 Kees Cook : > On Wed, Oct 3, 2012 at 2:18 PM, Andrew Morton > wrote: >> Again: has this proposal been reviewed by the glibc maintainers? If >> so, what was their position on it? > > Ard have you talked with them? I would expect it would be welcomed. > Roland, do you know who would be t

Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-04 Thread Ard Biesheuvel
2012/10/4 Mikael Pettersson : > - If .text is mapped non-writable and final, how would a debugger > (or any ptrace-using monitor-like application) plant a large > number of breakpoints in a target process? Breakpoint registers > aren't enough because (a) they're few in number, and (b) not >

Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-04 Thread Ard Biesheuvel
2012/10/4 PaX Team : Thanks for taking a look at this matter. >> >> This is mainly intended for the dynamic linker, >> >> which sets up the address space on behalf of >> >> dynamic binaries. By using this flag, it can >> >> prevent exploited code from remapping read-only >> >> executable code or

Re: [PATCH 3/3] perf: parse the .debug_frame section in case .eh_frame is not present

2013-09-05 Thread Ard Biesheuvel
On 5 September 2013 14:45, Will Deacon wrote: > Hi Jean, > > [adding Michael, since I know he was interested in this] > > On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote: >> On ARM the debug info is not present in the .eh_frame sections but >> instead in .debug_frame. >> Use libunwind t

Re: [PATCH 3/3] perf: parse the .debug_frame section in case .eh_frame is not present

2013-09-05 Thread Ard Biesheuvel
On 5 September 2013 15:05, Jean Pihet wrote: [..] > Here are the commands I have been using: > perf record -g dwarf -- > perf report --sort symbol --call-graph --stdio > Ah, I failed to add the 'dwarf' after -g, however, in that case, my perf report segfaults: #0 locate_debug_info (as=0xb6ea

Re: [PATCH 1/3] ARM: perf: add support for perf regs API

2013-09-05 Thread Ard Biesheuvel
On 4 September 2013 20:04, Jean Pihet wrote: > From: Will Deacon > > This patch implements the functions required for the perf refs API, 'regs API' not 'refs API' Regards, Ard. > allowing the perf tool to interface kernel register dumps with libunwind > in order to provide userspace backtrac

Re: [PATCH 3/3] perf: parse the .debug_frame section in case .eh_frame is not present

2013-09-05 Thread Ard Biesheuvel
to Ubuntu Saucy's libunwind8 on a Ubuntu Raring system (Calxeda Highbank) FWIW, for the series Tested-by: Ard Biesheuvel # on ARM/Highbank/UbuntuSaucy -- Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.

Re: crypto/xor.ko fails to build with CONFIG_KERNEL_MODE_NEON=y

2013-09-06 Thread Ard Biesheuvel
On 7 sep. 2013, at 04:44, Josh Boyer wrote: > We enabled CONFIG_KERNEL_MODE_NEON on the armv7hl builds we're doing. > It builds for a while, but eventually fails when running modpost on > the xor.ko module: > > ERROR: "xor_block_neon_inner" [crypto/xor.ko] undefined! > make[1]: *** [__modpost]

Re: Updated: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-10-07 Thread Ard Biesheuvel
2012/10/6 PaX Team : > sadly, this is not true at all, for multiple reasons: > .. snip ... > > cheers, > PaX Team > So can I summarize your position as that there is no merit at all in the ability to inhibit future permissions of existing mappings? -- Ard. -- To unsubscribe from this list: sen

[RFC PATCH] sched: add preempt_[disable|enable]_strict()

2013-06-29 Thread Ard Biesheuvel
corruption is high while the likelihood of immediate detection is low, e.g., when using the NEON unit in kernel mode on arm64. Signed-off-by: Ard Biesheuvel --- include/linux/preempt.h | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/include/linux

[PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-08-14 Thread Ard Biesheuvel
mainly intended for the dynamic linker, which sets up the address space on behalf of dynamic binaries. By using this flag, it can prevent exploited code from remapping read-only executable code or data sections read-write. Signed-off-by: Ard Biesheuvel --- arch/powerpc/include/asm/mman.h |3

Re: [PATCH] hardening: add PROT_FINAL prot flag to mmap/mprotect

2012-08-20 Thread Ard Biesheuvel
> This seems like a good idea to me. It would allow more than just the > loader to harden userspace allocations. It's a more direct version of > PaX's "MPROTECT" feature[1]. That feature hardens existing loaders, > but doesn't play nice with JITs (like Java), but this lets a loader > (or JIT) opt-i

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

2016-07-22 Thread Ard Biesheuvel
On 22 July 2016 at 13:38, Robert Richter wrote: > On 29.06.16 15:56:50, Ard Biesheuvel wrote: >> On 29 June 2016 at 15:34, Christopher Covington wrote: >> > Hi Tomasz, >> > >> > On 06/29/2016 06:48 AM, Tomasz Nowicki wrote: >> >> On 28.06.2016 18

Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

2016-09-20 Thread Ard Biesheuvel
On 20 September 2016 at 14:33, Bjorn Helgaas wrote: > [+cc Rafael (maybe already cc'd; I didn't recognize raf...@kernel.org, Duc] > > On Tue, Sep 20, 2016 at 09:23:21AM +0200, Tomasz Nowicki wrote: >> On 19.09.2016 20:09, Bjorn Helgaas wrote: >> >On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz No

Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case

2016-09-20 Thread Ard Biesheuvel
On 20 September 2016 at 15:05, Bjorn Helgaas wrote: > Hi Ard, > > On Tue, Sep 20, 2016 at 02:40:13PM +0100, Ard Biesheuvel wrote: >> On 20 September 2016 at 14:33, Bjorn Helgaas wrote: >> > [+cc Rafael (maybe already cc'd; I didn't recognize raf...@kernel.org, D

[PATCH 1/2] MAINTAINERS: add myself as EFI maintainer

2016-09-21 Thread Ard Biesheuvel
At the request of Matt, I am taking up co-maintainership of the EFI subsystem. So add my name to the EFI section in MAINTAINERS, and change the SCM tree reference to point to the new shared Git repo. Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- MAINTAINERS | 3 ++- 1 file changed, 2

[PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem

2016-09-21 Thread Ard Biesheuvel
Since I will be co-maintaining the EFI subsystem, it makes sense to mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS so that Matt, the list and I get cc'ed on proposed changes. Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Signed-off-by: Ard Biesh

Re: EFI co-maintainer

2016-09-22 Thread Ard Biesheuvel
On 22 September 2016 at 09:34, Matt Fleming wrote: > On Wed, 21 Sep, at 07:59:51PM, Lukas Wunner wrote: >> >> That is great to hear, thanks a lot from me as well. >> >> Just curious, are there any plans to integrate the new repo into >> linux-next? It would be great to have testing as early as po

[RFC PATCH] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

2016-06-20 Thread Ard Biesheuvel
dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD Seattle with a GeForce 210 PCIe card

Re: [RFC PATCH v3 1/2] ACPI/PCI: Check platform specific ECAM quirks

2016-06-21 Thread Ard Biesheuvel
On 20 June 2016 at 19:16, Lorenzo Pieralisi wrote: > [+ Ard, Arnd] > > On Wed, Jun 15, 2016 at 11:34:10AM -0400, Christopher Covington wrote: >> From: Tomasz Nowicki >> >> Some platforms may not be fully compliant with the generic PCI config >> operations. For these cases we implement a way to us

[RFC PATCH v2] drm/nouveau/fb/nv50: set DMA mask before mapping scratch page

2016-06-21 Thread Ard Biesheuvel
dma_map_page() to the .init hook, and set the streaming DMA mask based on the MMU subdev parameters before performing the call. Signed-off-by: Ard Biesheuvel --- I am sure there is a much better way to address this, but this fixes the problem I get on AMD Seattle with a GeForce 210 PCIe card

[PATCH v4 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook

2016-09-26 Thread Ard Biesheuvel
dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c | 30 +--- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/nv50.c b

[PATCH v4 0/3] drm/nouveau: set DMA mask before mapping scratch page

2016-09-26 Thread Ard Biesheuvel
incorrect comparison of dma_addr_t type var against NULL Ard Biesheuvel (3): drm/nouveau: set streaming DMA mask early drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook drivers/gpu/drm/nouveau/nouv

[PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

2016-09-26 Thread Ard Biesheuvel
RAM is above 4 GB). So set a preliminary DMA mask right after constructing the PCI device, and base it on the .dma_bits member of the MMU subdevice, which is what the TTM layer will base the DMA mask on as well. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11

[PATCH v4 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook

2016-09-26 Thread Ard Biesheuvel
dma_map_page() to the .init hook, which executes after the DMA mask has been set. Signed-off-by: Ard Biesheuvel --- drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c | 26 ++-- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c

Re: [PATCH] arm64: fix address fault during mapping fdt region

2016-08-01 Thread Ard Biesheuvel
On 1 August 2016 at 11:42, zijun_hu wrote: > From 07b9216ec3494515e7a6c41e0333eb8782427db3 Mon Sep 17 00:00:00 2001 > From: zijun_hu > Date: Mon, 1 Aug 2016 17:04:59 +0800 > Subject: [PATCH] arm64: fix address fault during mapping fdt region > > fdt_check_header() accesses other fileds of fdt hea

Re: Kernel panic - encryption/decryption failed when open file on Arm64

2016-09-09 Thread Ard Biesheuvel
On 9 September 2016 at 11:19, xiakaixu wrote: > Hi, > > After a deeply research about this crash, seems it is a specific > bug that only exists in armv8 board. And it occurs in this function > in arch/arm64/crypto/aes-glue.c. > > static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterli

Re: Kernel panic - encryption/decryption failed when open file on Arm64

2016-09-13 Thread Ard Biesheuvel
On 13 September 2016 at 07:43, Herbert Xu wrote: > On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote: >> >> So to me, it seems like we should be taking the blkcipher_next_slow() >> path, which does a kmalloc() and bails with -ENOMEM if that fails. > > Inde

Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes

2016-08-26 Thread Ard Biesheuvel
Hello Suzuki, On 26 August 2016 at 11:23, Suzuki K Poulose wrote: > Systems with differing CPU i-cache/d-cache line sizes can cause > problems with the cache management by software when the execution > is migrated from one to another. Usually, the application reads > the cache size on a CPU and t

Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes

2016-08-26 Thread Ard Biesheuvel
On 26 August 2016 at 17:16, Will Deacon wrote: > On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote: >> On 26/08/16 14:04, Suzuki K Poulose wrote: >> >On 26/08/16 12:03, Ard Biesheuvel wrote: >> >>IMO, this is a pattern that we should avoid: you are int

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

2017-08-16 Thread Ard Biesheuvel
(+ Mark, Will) On 15 August 2017 at 22:46, Andy Lutomirski wrote: > On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya > wrote: >> +/* >> + * Makes the calling kernel thread switch to/from efi_mm context >> + * Can be used from SetVirtualAddressMap() or during efi runtime calls >> + * (Note:

Re: [PATCH 0/5] add support for relative references in special sections

2017-08-17 Thread Ard Biesheuvel
Hi Sergey, Thanks for taking a look On 18 August 2017 at 06:56, Sergey Senozhatsky wrote: > On (08/14/17 11:52), Ard Biesheuvel wrote: >> This adds support for emitting special sections such as initcall arrays, >> PCI fixups and tracepoints as relative references rathe

Re: [PATCH 0/5] add support for relative references in special sections

2017-08-17 Thread Ard Biesheuvel
On 18 August 2017 at 07:29, Sergey Senozhatsky wrote: > Hi Ard, > > On (08/18/17 07:12), Ard Biesheuvel wrote: >> Hi Sergey, >> >> Thanks for taking a look >> >> On 18 August 2017 at 06:56, Sergey Senozhatsky >> wrote: >> > On (08/14/17 11:

Re: [PATCH 5/5] kernel: tracepoints: add support for relative references

2017-08-18 Thread Ard Biesheuvel
On 18 August 2017 at 09:26, Ingo Molnar wrote: > > * Ard Biesheuvel wrote: > >> -static void for_each_tracepoint_range(struct tracepoint * const *begin, >> - struct tracepoint * const *end, >> +static void for_each_tracepoint_range(const v

Re: [PATCH 5/5] kernel: tracepoints: add support for relative references

2017-08-18 Thread Ard Biesheuvel
On 18 August 2017 at 09:36, Ard Biesheuvel wrote: > On 18 August 2017 at 09:26, Ingo Molnar wrote: >> >> * Ard Biesheuvel wrote: >> >>> -static void for_each_tracepoint_range(struct tracepoint * const *begin, >>> - struct tr

[PATCH v2 1/6] arch: enable relative relocations for arm64, power, x86, s390 and x86

2017-08-18 Thread Ard Biesheuvel
be able to support and benefit from it. Cc: Catalin Marinas Cc: Will Deacon Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Signed-o

[PATCH v2 4/6] init: allow initcall tables to be emitted using relative references

2017-08-18 Thread Ard Biesheuvel
Signed-off-by: Ard Biesheuvel --- include/linux/init.h | 64 init/main.c| 22 ++- kernel/printk/printk.c | 4 +- security/security.c| 6 +- 4 files changed, 62 insertions(+), 34 deletions(-) diff --git a/include/linux/init.h b/include/linux/init.h ind

[PATCH v2 2/6] module: use relative references for __ksymtab entries

2017-08-18 Thread Ard Biesheuvel
: Kees Cook Cc: Thomas Garnier Cc: Nicolas Pitre Signed-off-by: Ard Biesheuvel --- arch/x86/include/asm/Kbuild | 1 + arch/x86/include/asm/export.h | 4 -- include/asm-generic/export.h | 12 +++- include/linux/compiler.h | 11 include/linux/export.h| 68

[PATCH v2 5/6] drivers: pci: add support for relative addressing in quirk tables

2017-08-18 Thread Ard Biesheuvel
Allow the PCI quirk tables to be emitted in a way that avoids absolute references to the hook functions. This reduces the size of the entries, and, more importantly, makes them invariant under runtime relocation (e.g., for KASLR) Cc: Bjorn Helgaas Signed-off-by: Ard Biesheuvel --- drivers/pci

[PATCH v2 6/6] kernel: tracepoints: add support for relative references

2017-08-18 Thread Ard Biesheuvel
: Ard Biesheuvel --- include/linux/tracepoint.h | 42 ++-- kernel/tracepoint.c| 7 +--- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index a26ffbe09e71..68701821933a 100644 --- a/include/linux

[PATCH v2 3/6] treewide: add missing trailing semicolons to initcall() invocations

2017-08-18 Thread Ard Biesheuvel
Before modifying the initcall() code to add support for relative references in the initcall sections, fix the existing code that lacks the required trailing semicolon so we can remove it from the macros. Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/perf_event.c | 2 +- arch

[PATCH v2 0/6] add support for relative references in special sections

2017-08-18 Thread Ard Biesheuvel
dt Cc: Martin Schwidefsky Cc: Sergey Senozhatsky Cc: Linus Torvalds Cc: Andy Whitcroft Cc: Jessica Yu Ard Biesheuvel (6): arch: enable relative relocations for arm64, power, x86, s390 and x86 module: use relative references for __ksymtab entries treewide: add missing trailing semicolon

Re: [PATCH v2] drivers/kmem: disable on arm64

2017-06-19 Thread Ard Biesheuvel
On 19 June 2017 at 17:03, Will Deacon wrote: > On Mon, Jun 19, 2017 at 04:37:24PM +0200, Ard Biesheuvel wrote: >> On arm64, the /dev/kmem driver barely works, given that it assumes that >> VMALLOC_START > PAGE_OFFSET, which is not the case on arm64. Due to the > > Proba

[PATCH v3] drivers/char: kmem: disable on arm64

2017-06-19 Thread Ard Biesheuvel
erface entirely for arm64. Signed-off-by: Ard Biesheuvel --- v3: improve commit log v2: disable /dev/kmem entirely rather than bandaiding it drivers/char/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 31adbebf812e..8102ee7b3247 1

Re: [PATCH v2 18/31] efi-stub.txt: standardize document format

2017-06-20 Thread Ard Biesheuvel
> - use proper markups for titles; > - identify literal blocks. > > Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Ard Biesheuvel > --- > Documentation/efi-stub.txt | 25 +++-- > 1 file changed, 15 insertions(+), 10 deletions(-) > > diff --gi

Re: [PATCH v3] drivers/char: kmem: disable on arm64

2017-06-20 Thread Ard Biesheuvel
On 20 June 2017 at 08:59, Ard Biesheuvel wrote: > As it turns out, arm64 deviates from other architectures in the way it > maps the VMALLOC region: on most (all?) other architectures, it resides > strictly above the kernel's direct mapping of DRAM, but on arm64, this > is the

Re: [PATCH 1/2] efi: Process MEMATTR table only if EFI_MEMMAP

2017-06-21 Thread Ard Biesheuvel
On 20 June 2017 at 22:14, Daniel Kiper wrote: > Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes. > > In theory we can check EFI_PARAVIRT too, however, > EFI_MEMMAP looks more generic and covers more cases. > > Signed-off-by: Daniel Kiper Reviewed-by: Ard Biesheuvel

Re: [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

2017-06-21 Thread Ard Biesheuvel
a few times until now. So, let's initialize only efi struct members used by > Xen to avoid such issues in the future. > > Signed-off-by: Daniel Kiper Acked-by: Ard Biesheuvel > --- > arch/x86/xen/efi.c | 45 - > 1 file chan

Re: Problem with new X.509 is_hash_blacklisted() interface

2017-06-21 Thread Ard Biesheuvel
is_hash_blacklisted(). This would typically be the case for a signed > X.509 message. > This last part seems a premature optimization to me. Is there a performance concern preventing us from using (4) only? In any case, the approach and the code look sound to me, althoug

Re: Problem with new X.509 is_hash_blacklisted() interface

2017-06-21 Thread Ard Biesheuvel
On 21 June 2017 at 14:49, David Howells wrote: > Ard Biesheuvel wrote: > >> > This can be told to skip a particular algorithm for when the caller >> > has one precalculated. The precalculated hash can be passed to >> > is_hash_blacklisted(). Thi

Re: [PATCH 04/11] Define the virtual space of KASan's shadow region

2017-10-16 Thread Ard Biesheuvel
On 16 October 2017 at 12:42, Liuwenliang (Lamb) wrote: > On 10/16/2017 07:03 PM, Abbott Liu wrote: >>arch/arm/kernel/entry-armv.S:348: Error: selected processor does not support >>`movw r1, > > #:lower16:0xC000-0x0100)>>3)+((0xC000-0x0100)-(1<<29' > in ARM mode >>arch/

Re: [PATCH] firmware: dmi: handle missing DMI data gracefully

2017-10-17 Thread Ard Biesheuvel
On 17 October 2017 at 08:27, Jean Delvare wrote: > Hi Ard, > > On Thu, 12 Oct 2017 20:59:37 +0100, Ard Biesheuvel wrote: >> Currently, when booting a kernel with DMI support on a platform that has >> no DMI tables, the following output is emitted into the kernel log: >&

Re: ARM64: Regression with commit e3067861ba66 ("arm64: add basic VMAP_STACK support")

2017-10-17 Thread Ard Biesheuvel
On 17 October 2017 at 10:29, Mark Rutland wrote: > On Tue, Oct 17, 2017 at 08:30:54AM +0800, Leo Yan wrote: >> On Mon, Oct 16, 2017 at 03:35:46PM +0100, Robin Murphy wrote: >> > On 16/10/17 15:26, Mark Rutland wrote: >> > > On Mon, Oct 16, 2017 at 03:12:45PM +0100, Robin Murphy wrote: >> > >> On 1

Re: ARM64: Regression with commit e3067861ba66 ("arm64: add basic VMAP_STACK support")

2017-10-17 Thread Ard Biesheuvel
On 17 October 2017 at 10:36, Leo Yan wrote: > On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote: > > [...] > >> > AFAICT, erratum 836870 results in livelock rather than memory >> > corruption, so I think we can ignore that. >> > >>

Re: [PATCH 04/11] Define the virtual space of KASan's shadow region

2017-10-17 Thread Ard Biesheuvel
On 17 October 2017 at 12:27, Liuwenliang (Lamb) wrote: > On 10/17/2017 12:40 AM, Abbott Liu wrote: >> Ard Biesheuvel [ard.biesheu...@linaro.org] wrote >>This is unnecessary: >> >>ldr r1, =TASK_SIZE >> >>will be converted to a mov instruction by the assemble

[PATCH v2] firmware: dmi: handle missing DMI data gracefully

2017-10-17 Thread Ard Biesheuvel
. The first one is a pr_info(), but the subsequent ones are pr_err()s that complain about a condition that is not really an error to begin with. So let's clean this up, and give up silently if dma_available is not set. Signed-off-by: Ard Biesheuvel --- v2: - don't use dmi_available in

Re: [PATCH] mdt: slram: use memremap() instead of ioremap()

2017-10-17 Thread Ard Biesheuvel
emap() being used on normal memory. > > Signed-off-by: Roy Franz Acked-by: Ard Biesheuvel > --- > Tested on arm64 simulation, using simulator to preload filesystem image into > RAM, > and also tested on x86_64 using video card memory. This is useful for > speeding >

Re: verify_pefile_signature() and a message field of MZ header in pe.h

2017-05-30 Thread Ard Biesheuvel
On 30 May 2017 at 07:10, AKASHI Takahiro wrote: > Hi David, > > Struct mz_hdr in include/linux/pe.h contains a message[] field. > Should it be part of this structure? > (I googled "MZ format," but didn't find out the exact definition.) > MZ format does not exist. It is the magic number of the DOS

Re: Problem with new X.509 is_hash_blacklisted() interface

2017-05-30 Thread Ard Biesheuvel
On 27 May 2017 at 15:05, James Bottomley wrote: > Added by > > commit 436529562df2748fd9918f578205b22cf8ced277 > Author: David Howells > Date: Mon Apr 3 16:07:25 2017 +0100 > > X.509: Allow X.509 certs to be blacklisted > > Ironically it duplicates a UEFI bug we've been struggling with for

Re: [PATCH 0/5] security, efi: Set lockdown if in secure boot mode

2017-05-30 Thread Ard Biesheuvel
On 24 May 2017 at 14:45, David Howells wrote: > > Here's a set of patches to institute a "locked-down mode" in the kernel and > to set that mode if the kernel is booted in secure-boot mode. This can be > enabled with CONFIG_LOCK_DOWN_KERNEL. If a kernel is locked down, the > lockdown can be lift

Re: [PATCH] ARM: add a private asm/unaligned.h

2017-10-31 Thread Ard Biesheuvel
On 31 October 2017 at 12:47, Russell King - ARM Linux wrote: > On Mon, Oct 30, 2017 at 04:38:17PM +, Russell King - ARM Linux wrote: >> On Mon, Oct 30, 2017 at 05:24:34PM +0100, Gregory CLEMENT wrote: >> > Hi Russell King, >> > >> > Here you will find all the objects included the vmlinux: >> >

Re: [PATCH] ARM: add a private asm/unaligned.h

2017-11-01 Thread Ard Biesheuvel
On 31 October 2017 at 13:22, Gregory CLEMENT wrote: > Hi Ard, > > On mar., oct. 31 2017, Ard Biesheuvel wrote: > >> On 31 October 2017 at 12:47, Russell King - ARM Linux >> wrote: >>> On Mon, Oct 30, 2017 at 04:38:17PM +, Russell King - ARM Linux wrote: &

Re: [PATCH] ARM: add a private asm/unaligned.h

2017-11-01 Thread Ard Biesheuvel
On 1 November 2017 at 18:00, Russell King - ARM Linux wrote: > On Wed, Nov 01, 2017 at 03:57:36PM +0000, Ard Biesheuvel wrote: >> On 31 October 2017 at 13:22, Gregory CLEMENT >> wrote: >> > Hi Ard, >> > >> > On mar., oct. 31 2017, Ard Biesheuvel wro

Re: [PATCH] ARM: add a private asm/unaligned.h

2017-11-01 Thread Ard Biesheuvel
On 1 November 2017 at 18:11, Russell King - ARM Linux wrote: > On Wed, Nov 01, 2017 at 06:02:24PM +0000, Ard Biesheuvel wrote: >> On 1 November 2017 at 18:00, Russell King - ARM Linux >> wrote: >> > On Wed, Nov 01, 2017 at 03:57:36PM +, Ard Biesheuvel wrote: >>

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

2017-10-24 Thread Ard Biesheuvel
On 24 October 2017 at 10:09, Russell King - ARM Linux wrote: > On Tue, Oct 24, 2017 at 09:09:52AM +0100, Ard Biesheuvel wrote: >> The following patch appears to fix the issue as well: >> >> diff --git a/arch/arm/boot/compressed/vmlinux.lds.S >> b/arch/arm/boot/compre

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

2017-10-24 Thread Ard Biesheuvel
On 24 October 2017 at 10:22, Russell King - ARM Linux wrote: > On Tue, Oct 24, 2017 at 10:13:09AM +0100, Ard Biesheuvel wrote: >> On 24 October 2017 at 10:09, Russell King - ARM Linux >> wrote: >> > The question is: do we want to know when additional sections get >

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

2017-10-24 Thread Ard Biesheuvel
On 24 October 2017 at 10:26, Ard Biesheuvel wrote: > On 24 October 2017 at 10:22, Russell King - ARM Linux > wrote: >> On Tue, Oct 24, 2017 at 10:13:09AM +0100, Ard Biesheuvel wrote: >>> On 24 October 2017 at 10:09, Russell King - ARM Linux >>> wrote: >>>

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

2017-10-24 Thread Ard Biesheuvel
On 24 October 2017 at 10:38, Russell King - ARM Linux wrote: > On Tue, Oct 24, 2017 at 10:30:41AM +0100, Ard Biesheuvel wrote: >> On 24 October 2017 at 10:26, Ard Biesheuvel >> wrote: >> > On 24 October 2017 at 10:22, Russell King - ARM Linux >> > wrote: &g

Re: [PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

2017-10-24 Thread Ard Biesheuvel
On 24 October 2017 at 10:54, Russell King - ARM Linux wrote: > On Tue, Oct 24, 2017 at 10:44:00AM +0100, Ard Biesheuvel wrote: >> On 24 October 2017 at 10:38, Russell King - ARM Linux >> wrote: >> > Do you have any preference - I'd prefer one that I can merge along

[PATCH 2/2] efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y

2017-10-25 Thread Ard Biesheuvel
ION=y. Cc: James Morse Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/arm-stub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c index 1cb2d1c070c3..a94601d

[GIT PULL 0/2] EFI fixes for v4.14

2017-10-25 Thread Ard Biesheuvel
avoid crashing on UEFI runtime services invocations after resume from hibernation on ARM ---- Ard Biesheuvel (1): efi/libstub: arm: don't randomize runtime regions when CONFIG_HIBERNATION=y Dan Carpenter (1): ef

[PATCH 1/2] efi/efi_test: Prevent an Oops in efi_runtime_query_capsulecaps()

2017-10-25 Thread Ard Biesheuvel
ing UEFI runtime service interfaces") Signed-off-by: Dan Carpenter Acked-by: Ivan Hu Cc: Ard Biesheuvel Signed-off-by: Matt Fleming Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/test/efi_test.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/efi/test/efi_

[GIT PULL 0/2] EFI updates for v4.15

2017-10-25 Thread Ard Biesheuvel
string fix Ard Biesheuvel (1): arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set Arvind Yadav (1): efi/capsule-loader: pr_err() strings should end with newlines arch/arm64/kernel/efi.c | 4

[PATCH 2/2] arm64: efi: ignore EFI_MEMORY_XP attribute if RP and/or WP are set

2017-10-25 Thread Ard Biesheuvel
pt to execute) Reported-by: Stephen Boyd Tested-by: Stephen Boyd Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/efi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index 82cd07592519..f85ac58d08a3 100644

[PATCH 1/2] efi/capsule-loader: pr_err() strings should end with newlines

2017-10-25 Thread Ard Biesheuvel
From: Arvind Yadav pr_err() messages should terminated with a new-line to avoid other messages being concatenated onto the end. Signed-off-by: Arvind Yadav Cc: Ard Biesheuvel Cc: Jan Kiszka Cc: Kweh Hock Leong Signed-off-by: Matt Fleming Signed-off-by: Ard Biesheuvel --- drivers/firmware

Re: [PATCH] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-26 Thread Ard Biesheuvel
On 26 October 2017 at 21:29, Nick Desaulniers wrote: > Upon upgrading to binutils 2.27, we found that our lz4 compressed kernel > images were significantly larger, resulting is 10ms boot time regressions. > > As noted by Rahul: > "aarch64 binaries uses RELA relocations, where each relocation entry

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-11-13 Thread Ard Biesheuvel
On 13 November 2017 at 15:40, Andreas Färber wrote: > Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel: >> On 6 November 2017 at 06:58, Andreas Färber wrote: >>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel: >> [...] >>>> >>>> Again, I am not

Re: [PATCH -next] irqchip/exiu: Fix return value check in exiu_init()

2017-11-14 Thread Ard Biesheuvel
err = PTR_ERR(data->base); > + if (!data->base) { > + err = -ENODEV; > goto out_free; > } > I was going to blame Marc's Tegra code for this, because that is where I copied most of the code from, but the bug doesn't exist there, and so it appears to be an original work. Oops. Acked-by: Ard Biesheuvel

Re: [PATCH v2] arm64: support __int128 on gcc 5+

2017-11-03 Thread Ard Biesheuvel
> On 3 Nov 2017, at 13:42, Will Deacon wrote: > > Hi Jason, > > [+Ard] > >> On Thu, Nov 02, 2017 at 06:43:22PM +0100, Jason A. Donenfeld wrote: >> Versions of gcc prior to gcc 5 emitted a __multi3 function call when >> dealing with TI types, resulting in failures when trying to link to >> libg

Re: [PATCH 13/15] arm64: add a workaround for GNU gold with ARM64_MODULE_PLTS

2017-11-03 Thread Ard Biesheuvel
On 3 November 2017 at 17:12, Sami Tolvanen wrote: > CONFIG_CLANG_LTO depends on GNU gold and due to a known bug, the > linker crashes when ARM64_MODULE_PLTS is enabled: > > https://sourceware.org/bugzilla/show_bug.cgi?id=14592 > > To work around the problem, this change: > > 1) Enables ARM64_M

Re: [PATCH 06/15] efi/libstub: disable clang LTO

2017-11-03 Thread Ard Biesheuvel
On 3 November 2017 at 17:11, Sami Tolvanen wrote: > With CONFIG_CLANG_LTO, we produce LLVM IR instead of object files. Since LTO > is not really needed here and the Makefile assumes we produce an object file, > disable LTO for libstub. > > Signed-off-by: Sami Tolvanen Acked-by:

Re: [PATCH 14/15] arm64: crypto: disable LTO for aes-ce-cipher.c

2017-11-03 Thread Ard Biesheuvel
On 3 November 2017 at 17:12, Sami Tolvanen wrote: > CONFIG_CLANG_LTO requires the use of clang's integrated assembler, which > doesn't understand the inline assembly in aes-ce-cipher.c. Disable LTO for > the file to work around the issue. > > Signed-off-by: Sami

Re: [PATCH 10/15] arm64: disable ARM64_ERRATUM_843419 for clang LTO

2017-11-03 Thread Ard Biesheuvel
On 3 November 2017 at 17:11, Sami Tolvanen wrote: > CONFIG_CLANG_LTO depends on GNU gold, which can generate ADR_PREL_PG_HI21 > relocations even with --fix-cortex-a53-843419. > > Since ARM64_ERRATUM_843419 disables kernel support for these relocations, > disable the erratum when LTO is used. > I

Re: [PATCH 00/15] Add support for clang LTO

2017-11-03 Thread Ard Biesheuvel
On 3 November 2017 at 19:26, Mark Rutland wrote: > On Fri, Nov 03, 2017 at 11:11:45AM -0700, Nick Desaulniers wrote: >> On Fri, Nov 3, 2017 at 11:09 AM, Mark Rutland wrote: >> ently compile >> > What's the minimum set of patches necessary to work with clang (ignoring >> > LTO)? >> >> If you have

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-11-04 Thread Ard Biesheuvel
On 4 November 2017 at 13:44, Andreas Färber wrote: > Hi everyone, > > The non-building clk driver has been removed for 4.14, but this patchset > seems stuck on matters of naming and maintenance... > > Am 30.06.2017 um 01:18 schrieb Masahiro Yamada: >> Hi Andreas, >> >> 2017-06-29 21:53 GMT+09:00 A

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-11-04 Thread Ard Biesheuvel
On 4 November 2017 at 15:30, Andreas Färber wrote: > Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel: >> On 4 November 2017 at 13:44, Andreas Färber wrote: >>> Hi everyone, >>> >>> The non-building clk driver has been removed for 4.14, but this patchset >

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-11-04 Thread Ard Biesheuvel
On 4 November 2017 at 20:06, Andreas Färber wrote: > Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel: >> On 4 November 2017 at 15:30, Andreas Färber wrote: >>> Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel: >>>> On 4 November 2017 at 13:44, Andreas Färber wrote: >

Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

2017-11-06 Thread Ard Biesheuvel
On 6 November 2017 at 06:58, Andreas Färber wrote: > Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel: [...] >> >> Again, I am not the one who is ranting here. You hit a nerve by >> accusing me of 'rebelling against linux.git' while this is quite the >> opposite

Re: [PATCH v4] arm64: support __int128 on gcc 5+

2017-11-06 Thread Ard Biesheuvel
On 6 November 2017 at 16:51, Jason A. Donenfeld wrote: > Wait, please don't jump to that decision so quickly. > > Are you sure the fail is for v4? Will mentioned this with v1, which is whay > this current v4 is supposed to fix up. > It appears your v4 adds __ashlti3() and __ashrti3, whereas the e

[PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

2017-10-18 Thread Ard Biesheuvel
Even though calling dql_completed() with a count that exceeds the queued count is a serious error, it still does not justify bringing down the entire kernel with a BUG_ON(). So relax it to a WARN_ON() instead. Signed-off-by: Ard Biesheuvel --- lib/dynamic_queue_limits.c | 2 +- 1 file changed

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

2017-10-18 Thread Ard Biesheuvel
On 18 October 2017 at 17:29, Eric Dumazet wrote: > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: >> Even though calling dql_completed() with a count that exceeds the >> queued count is a serious error, it still does not justify bringing >> down the entire kerne

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

2017-10-18 Thread Ard Biesheuvel
On 18 October 2017 at 19:45, Eric Dumazet wrote: > On Wed, 2017-10-18 at 18:57 +0100, Ard Biesheuvel wrote: >> On 18 October 2017 at 17:29, Eric Dumazet wrote: >> > On Wed, 2017-10-18 at 16:45 +0100, Ard Biesheuvel wrote: >> >> Even though calling dql_completed()

Re: [PATCH] lib/dynamic_queue_limits.c: relax BUG_ON to WARN_ON in dql_complete()

2017-10-19 Thread Ard Biesheuvel
On 19 October 2017 at 11:57, David Miller wrote: > From: Ard Biesheuvel > Date: Wed, 18 Oct 2017 16:45:15 +0100 > >> Even though calling dql_completed() with a count that exceeds the >> queued count is a serious error, it still does not justify bringing >> down the

Re: [PATCH] ARM: multi_v7_defconfig: Enable HugePages

2017-10-19 Thread Ard Biesheuvel
On 19 October 2017 at 20:40, Sam Protsenko wrote: > HugePages support is enabled on ARM64 and x86. On ARM32 we have support > for HugePages since kernel 3.11 [1]. Let's enable it on ARM32 too, as > it's needed for some projects like DPDK [2], LTP [3], etc. The similar > change was done in commit 7

Re: [PATCH v2] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-27 Thread Ard Biesheuvel
be able to get better results from the > longer runs of zeros, not just GZIP and LZ4. > > 10ms boot time savings isn't anything to get excited about, but users of > arm64+compression+bfd-2.27 should not have to pay a boot time penalty for no > runtime improvement. > > Reported

Re: [PATCH v3] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 13:08, Will Deacon wrote: > On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote: >> Upon upgrading to binutils 2.27, we found that our lz4 and gzip >> compressed kernel images were significantly larger, resulting is 10ms >> boot time regressions. >> >> As noted b

Re: [PATCH v3] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 13:12, Will Deacon wrote: > On Mon, Oct 30, 2017 at 01:11:23PM +0000, Ard Biesheuvel wrote: >> On 30 October 2017 at 13:08, Will Deacon wrote: >> > On Fri, Oct 27, 2017 at 09:33:41AM -0700, Nick Desaulniers wrote: >> >> Upon upgrading to binuti

Re: [PATCH v3] arm64: prevent regressions in compressed kernel image size when upgrading to binutils 2.27

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 14:08, Will Deacon wrote: > On Mon, Oct 30, 2017 at 01:35:49PM +0000, Ard Biesheuvel wrote: >> On 30 October 2017 at 13:12, Will Deacon wrote: >> > On Mon, Oct 30, 2017 at 01:11:23PM +0000, Ard Biesheuvel wrote: >> >> On 30 October 201

  1   2   3   4   5   6   7   8   9   10   >