[PATCH 0/2] PUD/PGDIR entries for linear mapping

mapping ]--- 0xc000-0xc0014000 0x8000 5G PUD D A . . . W R V 0xc0014000-0xc00177000x0001c000 880M PMD D A . . . W R V Alexandre Ghiti (2): riscv: Get memory below load_pa while ensuring linear mapping is PMD aligned

[PATCH v2 8/8] riscv: Explicit comment about user virtual address space size

Define precisely the size of the user accessible virtual space size for sv32/39/48 mmu types and explain why the whole virtual address space is split into 2 equal chunks between kernel and user space. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed-by: Palmer Dabbelt --- arch

[PATCH v2 7/8] riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo

Now that the mmu type is determined at runtime using SATP characteristic, use the global variable pgtable_l4_enabled to output mmu type of the processor through /proc/cpuinfo instead of relying on device tree infos. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed-by: Palmer

[PATCH v2 6/8] riscv: Allow user to downgrade to sv39 when hw supports sv48

less memory accesses in case of a TLB miss. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/mm/init.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index a937173af13d..4064639b24e4

[PATCH v2 5/8] riscv: Implement sv48 support

will automatically fallback to a standard 3-level page table by folding the new PUD level into PGDIR level. In order to detect HW capabilities at runtime, we use SATP feature that ignores writes with an unsupported mode. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/Kconfig

[PATCH v2 4/8] riscv: Prepare ptdump for vm layout dynamic addresses

the different zones of the vm layout. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/mm/ptdump.c | 49 ++ 1 file changed, 40 insertions(+), 9 deletions(-) diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c index 7eab76a93106

[PATCH v2 3/8] riscv: Simplify MAXPHYSMEM config

Either the user specifies maximum physical memory size of 2GB or the user lives with the system constraint which is 1/4th of maximum addressable memory in Sv39 MMU mode (i.e. 128GB) for now. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/Kconfig | 20

[PATCH v2 2/8] riscv: Allow to dynamically define VA_BITS

With 4-level page table folding at runtime, we don't know at compile time the size of the virtual address space so we must set VA_BITS dynamically so that sparsemem reserves the right amount of memory for struct pages. Signed-off-by: Alexandre Ghiti --- arch/riscv/Kconfig | 10

[PATCH v2 1/8] riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE

There is no need to compare at compile time MAX_EARLY_MAPPING_SIZE value with PGDIR_SIZE since MAX_EARLY_MAPPING_SIZE is set to 128MB which is less than PGDIR_SIZE that is equal to 1GB: that allows to simplify early_pmd definition. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed

[PATCH v2 0/8] Introduce sv48 support

the Reviewed-by) * Applied various Reviewed-by Alexandre Ghiti (8): riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE riscv: Allow to dynamically define VA_BITS riscv: Simplify MAXPHYSMEM config riscv: Prepare ptdump for vm layout dynamic addresses riscv: Implement sv48 support

[PATCH v4 4/4] riscv: Check relocations at compile time

the relocations. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/Makefile.postlink | 36 arch/riscv/tools/relocs_check.sh | 26 +++ 2 files changed, 62 insertions(+) create mode 100644 arch/riscv/Makefile.postlink create

[PATCH v4 3/4] powerpc: Move script to check relocations at compile time in scripts/

logic to scripts/ so that other architectures can take advantage of it. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/powerpc/tools/relocs_check.sh | 18 ++ scripts/relocs_check.sh| 20 2 files changed, 22 insertions(+), 16

[PATCH v4 2/4] riscv: Introduce CONFIG_RELOCATABLE

introduces an overhead even if the kernel is loaded at the same address it was linked at and that the compiler options are those used in arm64 which uses the same RELA relocation format. Signed-off-by: Alexandre Ghiti Reviewed-by: Zong Li Reviewed-by: Anup Patel --- arch/riscv/Kconfig

[PATCH v4 1/4] riscv: Move kernel mapping to vmalloc zone

to be loaded. Signed-off-by: Alexandre Ghiti --- arch/riscv/boot/loader.lds.S | 3 +- arch/riscv/include/asm/page.h| 10 +- arch/riscv/include/asm/pgtable.h | 38 ++--- arch/riscv/kernel/head.S | 3 +- arch/riscv/kernel/module.c | 4 +-- arch/riscv/kernel

[PATCH v4 0/4] vmalloc kernel mapping and relocatable kernel

* Tested with sv48 patchset * Add Reviewed/Tested-by from Zong and Anup Alexandre Ghiti (4): riscv: Move kernel mapping to vmalloc zone riscv: Introduce CONFIG_RELOCATABLE powerpc: Move script to check relocations at compile

[PATCH 8/8] riscv: Explicit comment about user virtual address space size

Define precisely the size of the user accessible virtual space size for sv32/39/48 mmu types and explain why the whole virtual address space is split into 2 equal chunks between kernel and user space. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed-by: Palmer Dabbelt --- arch

[PATCH 7/8] riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo

Now that the mmu type is determined at runtime using SATP characteristic, use the global variable pgtable_l4_enabled to output mmu type of the processor through /proc/cpuinfo instead of relying on device tree infos. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed-by: Palmer

[PATCH 6/8] riscv: Allow user to downgrade to sv39 when hw supports sv48

less memory accesses in case of a TLB miss. Signed-off-by: Alexandre Ghiti --- arch/riscv/mm/init.c | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index bad8da099ff6..1776eeb53d61 100644 --- a/arch/riscv/mm

[PATCH 5/8] riscv: Implement sv48 support

will automatically fallback to a standard 3-level page table by folding the new PUD level into PGDIR level. In order to detect HW capabilities at runtime, we use SATP feature that ignores writes with an unsupported mode. Signed-off-by: Alexandre Ghiti --- arch/riscv/Kconfig | 6

[PATCH 4/8] riscv: Prepare ptdump for vm layout dynamic addresses

the different zones of the vm layout. Signed-off-by: Alexandre Ghiti --- arch/riscv/mm/ptdump.c | 49 ++ 1 file changed, 40 insertions(+), 9 deletions(-) diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c index 7eab76a93106..7d9386a7f5c2 100644

[PATCH 3/8] riscv: Simplify MAXPHYSMEM config

Either the user specifies maximum physical memory size of 2GB or the user lives with the system constraint which is 1/4th of maximum addressable memory in Sv39 MMU mode (i.e. 128GB) for now. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel --- arch/riscv/Kconfig | 20

[PATCH 2/8] riscv: Allow to dynamically define VA_BITS

With 4-level page table folding at runtime, we don't know at compile time the size of the virtual address space so we must set VA_BITS dynamically so that sparsemem reserves the right amount of memory for struct pages. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed-by: Palmer

[PATCH 1/8] riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE

There is no need to compare at compile time MAX_EARLY_MAPPING_SIZE value with PGDIR_SIZE since MAX_EARLY_MAPPING_SIZE is set to 128MB which is less than PGDIR_SIZE that is equal to 1GB: that allows to simplify early_pmd definition. Signed-off-by: Alexandre Ghiti Reviewed-by: Anup Patel Reviewed

[PATCH 0/8] Introduce sv48 support

in case of TLB miss. Alexandre Ghiti (8): riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE riscv: Allow to dynamically define VA_BITS riscv: Simplify MAXPHYSMEM config riscv: Prepare ptdump for vm layout dynamic addresses riscv: Implement sv48 support riscv: Allow user

[PATCH v3 3/3] arch, scripts: Add script to check relocations at compile time

logic to scripts/ and add arch specific scripts triggered at postlink. At the moment, powerpc and riscv architectures take advantage of this compile-time check. Signed-off-by: Alexandre Ghiti --- arch/powerpc/tools/relocs_check.sh | 18 ++- arch/riscv/Makefile.postlink | 36

[PATCH v3 2/3] riscv: Introduce CONFIG_RELOCATABLE

introduces an overhead even if the kernel is loaded at the same address it was linked at and that the compiler options are those used in arm64 which uses the same RELA relocation format. Signed-off-by: Alexandre Ghiti --- arch/riscv/Kconfig | 12 +++ arch/riscv/Makefile

[PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

to be loaded. Signed-off-by: Alexandre Ghiti --- arch/riscv/boot/loader.lds.S | 3 +- arch/riscv/include/asm/page.h| 10 +- arch/riscv/include/asm/pgtable.h | 37 +--- arch/riscv/kernel/head.S | 3 +- arch/riscv/kernel/module.c | 4 +-- arch/riscv/kernel

[PATCH v3 0/3] vmalloc kernel mapping and relocatable kernel

patch allows to build relocatable kernels but is not selected by default. The third patch takes advantage of an already existing powerpc script that checks relocations at compile-time, and uses it for riscv. Alexandre Ghiti (3): riscv: Move kernel mapping to vmalloc zone riscv: Introduce

Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

On 6/20/19 7:03 AM, Alexandre Ghiti wrote: This series fixes the fallback of the top-down mmap: in case of failure, a bottom-up scheme can be tried as a last resort between the top-down mmap base and the stack, hoping for a large unused stack limit. Lots of architectures and even mm code start

Re: [PATCH v6 11/14] mips: Adjust brk randomization offset to fit generic version

On 8/8/19 11:19 AM, Sergei Shtylyov wrote: Hello! On 08.08.2019 9:17, Alexandre Ghiti wrote: This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Acked

Re: [PATCH v6 09/14] mips: Properly account for stack randomization and stack guard gap

On 8/8/19 11:16 AM, Sergei Shtylyov wrote: Hello! On 08.08.2019 9:17, Alexandre Ghiti wrote: This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed

[PATCH v6 14/14] riscv: Make mmap allocation top-down by default

3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 3ff7fff000-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Acked-by: Paul Walmsley Reviewed

[PATCH v6 13/14] mips: Use generic mmap top-down layout and brk randomization

of arch_randomize_brk since it also fits. Note that this commit also removes the possibility for mips to have elf randomization and no MMU: without MMU, the security added by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis

[PATCH v6 12/14] mips: Replace arch specific way to determine 32bit task with generic version

Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition. Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis

[PATCH v6 11/14] mips: Adjust brk randomization offset to fit generic version

This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 7

[PATCH v6 10/14] mips: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Acked-by: Paul Burton Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 4 ++-- 1 file changed, 2

[PATCH v6 09/14] mips: Properly account for stack randomization and stack guard gap

-by: Alexandre Ghiti Acked-by: Kees Cook Acked-by: Paul Burton Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c index d79f2b432318..f5c778113384 100644 --- a/arch/mips/mm/mmap.c

[PATCH v6 08/14] arm: Use generic mmap top-down layout and brk randomization

-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/processor.h | 2 -- arch/arm/kernel/process.c| 5 --- arch/arm/mm/mmap.c | 62 4 files changed, 1

[PATCH v6 07/14] arm: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH v6 06/14] arm: Properly account for stack randomization and stack guard gap

-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/mm/mmap.c | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index f866870db749..bff3d00bda5b 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c

[PATCH v6 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- arch/Kconfig| 1 + arch/arm64/Kconfig | 1 - arch/arm64/kernel/process.c | 8 mm/util.c

[PATCH v6 04/14] arm64, mm: Move generic mmap layout functions to mm

on MMU being enabled, if selected without MMU support, a warning will be thrown. Suggested-by: Christoph Hellwig Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- arch/Kconfig

[PATCH v6 03/14] arm64: Consider stack randomization for mmap base only when necessary

Do not offset mmap base address because of stack randomization if current task does not want randomization. Note that x86 already implements this behaviour. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis

[PATCH v6 02/14] arm64: Make use of is_compat_task instead of hardcoding this test

Each architecture has its own way to determine if a task is a compat task, by using is_compat_task in arch_mmap_rnd, it allows more genericity and then it prepares its moving to mm/. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig

[PATCH v6 01/14] mm, fs: Move randomize_stack_top from fs to mm

This preparatory commit moves this function so that further introduction of generic topdown mmap layout is contained only in mm/util.c. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- fs/binfmt_elf.c| 20

[PATCH v6 00/14] Provide generic top-down mmap layout functions

in riscv - Align #if defined on next line => this gives rise to a checkpatch warning. I found this pattern all around the tree, in the same proportion as the previous pattern which was less pretty: git grep -C 1 -n -P "^#if defined.+\|\|.*$" Alexandre Ghiti (14): mm, fs:

Re: [PATCH] riscv: kbuild: add virtual memory system selection

On 8/7/19 7:42 AM, Christoph Hellwig wrote: On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote: The rationale is to encourage others to start laying the groundwork for future Sv48 support. The immediate trigger for it was Alex's mmap randomization support patch series, which needs

Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

On 6/20/19 7:03 AM, Alexandre Ghiti wrote: This series fixes the fallback of the top-down mmap: in case of failure, a bottom-up scheme can be tried as a last resort between the top-down mmap base and the stack, hoping for a large unused stack limit. Lots of architectures and even mm code start

[PATCH v5 14/14] riscv: Make mmap allocation top-down by default

3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 3ff7fff000-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Reviewed-by: Christoph Hellwig Reviewed

[PATCH v5 13/14] mips: Use generic mmap top-down layout and brk randomization

of arch_randomize_brk since it also fits. Note that this commit also removes the possibility for mips to have elf randomization and no MMU: without MMU, the security added by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis

[PATCH v5 12/14] mips: Replace arch specific way to determine 32bit task with generic version

Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition. Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis

[PATCH v5 11/14] mips: Adjust brk randomization offset to fit generic version

This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Acked-by: Paul Burton Reviewed-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 7

[PATCH v5 10/14] mips: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Acked-by: Paul Burton Reviewed-by: Luis Chamberlain --- arch/mips/mm/mmap.c | 4 ++-- 1 file changed, 2

[PATCH v5 09/14] mips: Properly account for stack randomization and stack guard gap

This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for arm here: https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com Signed-off-by: Alexandre

[PATCH v5 08/14] arm: Use generic mmap top-down layout and brk randomization

-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/processor.h | 2 -- arch/arm/kernel/process.c| 5 --- arch/arm/mm/mmap.c | 62 4 files changed, 1

[PATCH v5 07/14] arm: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Luis Chamberlain --- arch/arm/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH v5 06/14] arm: Properly account for stack randomization and stack guard gap

This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for arm here: https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com Signed-off-by: Alexandre

[PATCH v5 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- arch/Kconfig| 1 + arch/arm64/Kconfig | 1 - arch/arm64/kernel/process.c | 8 mm/util.c

[PATCH v5 04/14] arm64, mm: Move generic mmap layout functions to mm

on MMU being enabled, if selected without MMU support, a warning will be thrown. Suggested-by: Christoph Hellwig Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- arch/Kconfig

[PATCH v5 03/14] arm64: Consider stack randomization for mmap base only when necessary

Do not offset mmap base address because of stack randomization if current task does not want randomization. Note that x86 already implements this behaviour. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis

[PATCH v5 01/14] mm, fs: Move randomize_stack_top from fs to mm

This preparatory commit moves this function so that further introduction of generic topdown mmap layout is contained only in mm/util.c. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain --- fs/binfmt_elf.c| 20

[PATCH v5 02/14] arm64: Make use of is_compat_task instead of hardcoding this test

Each architecture has its own way to determine if a task is a compat task, by using is_compat_task in arch_mmap_rnd, it allows more genericity and then it prepares its moving to mm/. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig

[PATCH v5 00/14] Provide generic top-down mmap layout functions

same proportion as the previous pattern which was less pretty: git grep -C 1 -n -P "^#if defined.+\|\|.*\\\\$" Alexandre Ghiti (14): mm, fs: Move randomize_stack_top from fs to mm arm64: Make use of is_compat_task instead of hardcoding this test arm64: Consider stack randomizati

Re: [PATCH REBASE v4 14/14] riscv: Make mmap allocation top-down by default

On 7/26/19 2:20 AM, Paul Walmsley wrote: Hi Alexandre, I have a few questions about this patch. Sorry to be dense here ... On Wed, 24 Jul 2019, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible

Re: [PATCH REBASE v4 11/14] mips: Adjust brk randomization offset to fit generic version

On 7/24/19 7:58 AM, Alexandre Ghiti wrote: This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/mm/mmap.c | 7

Re: [EXTERNAL][PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions

On 7/24/19 10:18 PM, Paul Burton wrote: Hi Alexandre, On Wed, Jul 24, 2019 at 01:58:36AM -0400, Alexandre Ghiti wrote: Hi Andrew, This is simply a rebase on top of next-20190719, where I added various Acked/Reviewed-by from Kees and Catalin and a note on commit 08/14 suggested by Kees

Re: [PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions

On 7/24/19 7:17 PM, Luis Chamberlain wrote: Other than the two comments: Reviewed-by: Luis Chamberlain Thanks for your time Luis, Alex Luis

Re: [PATCH REBASE v4 12/14] mips: Replace arch specific way to determine 32bit task with generic version

On 7/24/19 7:16 PM, Luis Chamberlain wrote: On Wed, Jul 24, 2019 at 01:58:48AM -0400, Alexandre Ghiti wrote: Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task

Re: [PATCH REBASE v4 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

On 7/24/19 7:11 PM, Luis Chamberlain wrote: On Wed, Jul 24, 2019 at 01:58:41AM -0400, Alexandre Ghiti wrote: diff --git a/mm/util.c b/mm/util.c index 0781e5575cb3..16f1e56e2996 100644 --- a/mm/util.c +++ b/mm/util.c @@ -321,7 +321,15 @@ unsigned long randomize_stack_top(unsigned long stack_top

[PATCH REBASE v4 14/14] riscv: Make mmap allocation top-down by default

3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 3ff7fff000-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti Reviewed-by: Christoph Hellwig Reviewed

[PATCH REBASE v4 13/14] mips: Use generic mmap top-down layout and brk randomization

of arch_randomize_brk since it also fits. Note that this commit also removes the possibility for mips to have elf randomization and no MMU: without MMU, the security added by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/Kconfig | 2

[PATCH REBASE v4 12/14] mips: Replace arch specific way to determine 32bit task with generic version

Mips uses TASK_IS_32BIT_ADDR to determine if a task is 32bit, but this define is mips specific and other arches do not have it: instead, use !IS_ENABLED(CONFIG_64BIT) || is_compat_task() condition. Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/mm/mmap.c | 3 ++- 1 file

[PATCH REBASE v4 11/14] mips: Adjust brk randomization offset to fit generic version

This commit simply bumps up to 32MB and 1GB the random offset of brk, compared to 8MB and 256MB, for 32bit and 64bit respectively. Suggested-by: Kees Cook Signed-off-by: Alexandre Ghiti Reviewed-by: Kees Cook --- arch/mips/mm/mmap.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions

[PATCH REBASE v4 10/14] mips: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook Acked-by: Paul Burton --- arch/mips/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH REBASE v4 09/14] mips: Properly account for stack randomization and stack guard gap

This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for arm here: https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com Signed-off-by: Alexandre

[PATCH REBASE v4 08/14] arm: Use generic mmap top-down layout and brk randomization

-by: Alexandre Ghiti Acked-by: Kees Cook --- arch/arm/Kconfig | 2 +- arch/arm/include/asm/processor.h | 2 -- arch/arm/kernel/process.c| 5 --- arch/arm/mm/mmap.c | 62 4 files changed, 1 insertion(+), 70 deletions(-) diff

[PATCH REBASE v4 07/14] arm: Use STACK_TOP when computing mmap base address

mmap base address must be computed wrt stack top address, using TASK_SIZE is wrong since STACK_TOP and TASK_SIZE are not equivalent. Signed-off-by: Alexandre Ghiti Acked-by: Kees Cook --- arch/arm/mm/mmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm

[PATCH REBASE v4 06/14] arm: Properly account for stack randomization and stack guard gap

This commit takes care of stack randomization and stack guard gap when computing mmap base address and checks if the task asked for randomization. This fixes the problem uncovered and not fixed for arm here: https://lkml.kernel.org/r/20170622200033.25714-1-r...@redhat.com Signed-off-by: Alexandre

[PATCH REBASE v4 05/14] arm64, mm: Make randomization selected by generic topdown mmap layout

by randomization is worth nothing. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig --- arch/Kconfig| 1 + arch/arm64/Kconfig | 1 - arch/arm64/kernel/process.c | 8 mm/util.c | 11 +-- 4

[PATCH REBASE v4 04/14] arm64, mm: Move generic mmap layout functions to mm

on MMU being enabled, if selected without MMU support, a warning will be thrown. Suggested-by: Christoph Hellwig Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig --- arch/Kconfig | 10 arch/arm64/Kconfig

[PATCH REBASE v4 03/14] arm64: Consider stack randomization for mmap base only when necessary

Do not offset mmap base address because of stack randomization if current task does not want randomization. Note that x86 already implements this behaviour. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig --- arch/arm64/mm/mmap.c

[PATCH REBASE v4 02/14] arm64: Make use of is_compat_task instead of hardcoding this test

Each architecture has its own way to determine if a task is a compat task, by using is_compat_task in arch_mmap_rnd, it allows more genericity and then it prepares its moving to mm/. Signed-off-by: Alexandre Ghiti Acked-by: Catalin Marinas Acked-by: Kees Cook Reviewed-by: Christoph Hellwig

[PATCH REBASE v4 01/14] mm, fs: Move randomize_stack_top from fs to mm

This preparatory commit moves this function so that further introduction of generic topdown mmap layout is contained only in mm/util.c. Signed-off-by: Alexandre Ghiti Reviewed-by: Christoph Hellwig Acked-by: Kees Cook --- fs/binfmt_elf.c| 20 include/linux/mm.h | 2

[PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions

#if defined.+\|\|.*$" Alexandre Ghiti (14): mm, fs: Move randomize_stack_top from fs to mm arm64: Make use of is_compat_task instead of hardcoding this test arm64: Consider stack randomization for mmap base only when necessary arm64, mm: Move generic mmap layout functions to mm arm64, mm: Ma

Re: [PATCH v3 0/2] Hugetlbfs support for riscv

On 7/4/19 12:57 AM, Paul Walmsley wrote: Hi Alex, Thanks for writing and testing these patches, and thanks for your patience waiting for reviews and testing. No problem :) On Mon, 1 Jul 2019, Alexandre Ghiti wrote: This series introduces hugetlbfs support for both riscv 32/64. Riscv32

Re: [PATCH v3 2/2] riscv: Introduce huge page support for 32/64bit kernel

On 7/2/19 3:24 PM, Christoph Hellwig wrote: +config ARCH_WANT_GENERAL_HUGETLB + def_bool y + +config SYS_SUPPORTS_HUGETLBFS + def_bool y In a perfect world these would be in mm/Kconfig and only selected by the architectures. But I don't want to force you to clean up all that mess

Re: [PATCH v3 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig

On 7/2/19 3:27 AM, Hanjun Guo wrote: On 2019/7/2 1:58, Alexandre Ghiti wrote: ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti --- arch/Kconfig | 3

Re: [PATCH v3 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig

On 7/1/19 8:51 PM, Paul Walmsley wrote: Catalin, Palmer, On Mon, 1 Jul 2019, Alexandre Ghiti wrote: ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti Since

[PATCH v3 2/2] riscv: Introduce huge page support for 32/64bit kernel

This patch implements both 4MB huge page support for 32bit kernel and 2MB/1GB huge pages support for 64bit kernel. Signed-off-by: Alexandre Ghiti --- arch/riscv/Kconfig | 8 ++ arch/riscv/include/asm/hugetlb.h | 18 + arch/riscv/include/asm/page.h| 10

[PATCH v3 1/2] x86, arm64: Move ARCH_WANT_HUGE_PMD_SHARE config in arch/Kconfig

ARCH_WANT_HUGE_PMD_SHARE config was declared in both architectures: move this declaration in arch/Kconfig and make those architectures select it. Signed-off-by: Alexandre Ghiti --- arch/Kconfig | 3 +++ arch/arm64/Kconfig | 4 +--- arch/x86/Kconfig | 4 +--- 3 files changed, 5

[PATCH v3 0/2] Hugetlbfs support for riscv

xplicitly asked for in command line, as suggested by Mike. - Replace #ifdef CONFIG_64BIT into IS_ENABLED(CONFIG_64BIT), as suggested by Christoph Hellwig. Alexand

[PATCH RESEND 4/8] x86, hugetlbpage: Start fallback of top-down mmap at mm->mmap_base

. Signed-off-by: Alexandre Ghiti --- arch/x86/mm/hugetlbpage.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c index fab095362c50..4b90339aef50 100644 --- a/arch/x86/mm/hugetlbpage.c +++ b/arch/x86/mm/hugetlbpage.c

[PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

is useless since the top-down scheme already failed on the whole address space: instead, simply use mmap_base. Along the way, it allows to get rid of of mmap_legacy_base and mmap_compat_legacy_base from mm_struct. Note that arm and mips already implement this behaviour. Alexandre Ghiti (8): s390

[PATCH RESEND 8/8] mm: Remove mmap_legacy_base and mmap_compat_legacy_code fields from mm_struct

Now that x86 and parisc do not use those fields anymore, remove them from mm code. Signed-off-by: Alexandre Ghiti --- include/linux/mm_types.h | 2 -- mm/debug.c | 4 ++-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/include/linux/mm_types.h b/include/linux

[PATCH RESEND 7/8] x86: Use mmap_*base, not mmap_*legacy_base, as low_limit for bottom-up mmap

-by: Alexandre Ghiti --- arch/x86/include/asm/elf.h | 2 +- arch/x86/kernel/sys_x86_64.c | 4 ++-- arch/x86/mm/hugetlbpage.c| 4 ++-- arch/x86/mm/mmap.c | 20 +--- 4 files changed, 14 insertions(+), 16 deletions(-) diff --git a/arch/x86/include/asm/elf.h b/arch/x86

[PATCH RESEND 6/8] parisc: Use mmap_base, not mmap_legacy_base, as low_limit for bottom-up mmap

resort, space between the top-down mmap base and the stack, which is the only place not covered by the top-down mmap. Then this commit removes the usage of mmap_legacy_base field from parisc code. Signed-off-by: Alexandre Ghiti --- arch/parisc/kernel/sys_parisc.c | 8 +++- 1 file changed, 3

[PATCH RESEND 5/8] mm: Start fallback top-down mmap at mm->mmap_base

. Signed-off-by: Alexandre Ghiti --- mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index dedae10cb6e2..e563145c1ff4 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2185,7 +2185,7 @@ arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr

[PATCH RESEND 3/8] sparc: Start fallback of top-down mmap at mm->mmap_base

. Signed-off-by: Alexandre Ghiti --- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/sparc/mm/hugetlbpage.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c index ccc88926bc00..ea1de1e5fa8d 100644 --- a/arch

[PATCH RESEND 2/8] sh: Start fallback of top-down mmap at mm->mmap_base

. Signed-off-by: Alexandre Ghiti --- arch/sh/mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c index 6a1a1297baae..4c7da92473dd 100644 --- a/arch/sh/mm/mmap.c +++ b/arch/sh/mm/mmap.c @@ -135,7 +135,7 @@ arch_get_unmapped_area_topdown

[PATCH RESEND 1/8] s390: Start fallback of top-down mmap at mm->mmap_base

. Signed-off-by: Alexandre Ghiti --- arch/s390/mm/mmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/s390/mm/mmap.c b/arch/s390/mm/mmap.c index cbc718ba6d78..4a222969843b 100644 --- a/arch/s390/mm/mmap.c +++ b/arch/s390/mm/mmap.c @@ -166,7 +166,7

<    1   2   3   4   >