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
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
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
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
>
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
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
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
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
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.
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]
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(+ 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:
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
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:
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
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
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
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
: 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
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
: 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
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
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
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
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
> - 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
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
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
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
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
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
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/
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:
>&
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
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.
>> >
>>
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
.
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
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
>
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
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
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
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:
>> >
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:
&
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
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:
>>
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
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
>
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:
>>>
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
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
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
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
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_
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
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
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
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
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
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
> 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
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
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:
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
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
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
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
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
>
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:
>
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
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
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
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
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()
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
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
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
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
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
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 - 100 of 3022 matches
Mail list logo
