All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	kernel-hardening@lists.openwall.com, will.deacon@arm.com,
	catalin.marinas@arm.com, leif.lindholm@linaro.org,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	stuart.yoder@freescale.com, bhupesh.sharma@freescale.com,
	arnd@arndb.de, marc.zyngier@arm.com, christoffer.dall@linaro.org
Subject: Re: [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations
Date: Thu, 7 Jan 2016 13:55:18 +0000	[thread overview]
Message-ID: <20160107135518.GB15917@leverpostej> (raw)
In-Reply-To: <1451489172-17420-4-git-send-email-ard.biesheuvel@linaro.org>

On Wed, Dec 30, 2015 at 04:26:02PM +0100, Ard Biesheuvel wrote:
> Before introducing new statically allocated page tables and increasing
> their alignment in subsequent patches, update the reservation logic
> so that only pages that are in actual use end up as reserved with
> memblock.

Could you add something to the commit message about what this will gain
us (i.e. which pages we don't have to reserve)? It's not immediately
obvious why we'd have page tables we wouldn't want to reserve.

>From the looks of the next patch we won't have redundant levels of
fixmap table for a given configuration, so I guess we're catering for
the case the fixmap shares a pgd/pud/pmd entry with the image mapping?

Does that happen? If so that would invalidate the assumption I make when
copying the fixmap over in [1] (see map_kernel).

To handle that either we need some special logic to copy over the
relevant bits for the fixmap (as with kasan_copy_shadow), or we need to
avoid sharing a pgd entry.

Thoughts?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397114.html

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/init.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6bacba847923..8e678d05ad84 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -36,6 +36,7 @@
>  #include <linux/swiotlb.h>
>  
>  #include <asm/fixmap.h>
> +#include <asm/kernel-pgtable.h>
>  #include <asm/memory.h>
>  #include <asm/sections.h>
>  #include <asm/setup.h>
> @@ -165,11 +166,13 @@ void __init arm64_memblock_init(void)
>  	 * Register the kernel text, kernel data, initrd, and initial
>  	 * pagetables with memblock.
>  	 */
> -	memblock_reserve(__pa(_text), _end - _text);
> +	memblock_reserve(__pa(_text), __bss_stop - _text);
>  #ifdef CONFIG_BLK_DEV_INITRD
>  	if (initrd_start)
>  		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
>  #endif
> +	memblock_reserve(__pa(idmap_pg_dir), IDMAP_DIR_SIZE);
> +	memblock_reserve(__pa(swapper_pg_dir), SWAPPER_DIR_SIZE);
>  
>  	early_init_fdt_scan_reserved_mem();
>  
> -- 
> 2.5.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations
Date: Thu, 7 Jan 2016 13:55:18 +0000	[thread overview]
Message-ID: <20160107135518.GB15917@leverpostej> (raw)
In-Reply-To: <1451489172-17420-4-git-send-email-ard.biesheuvel@linaro.org>

On Wed, Dec 30, 2015 at 04:26:02PM +0100, Ard Biesheuvel wrote:
> Before introducing new statically allocated page tables and increasing
> their alignment in subsequent patches, update the reservation logic
> so that only pages that are in actual use end up as reserved with
> memblock.

Could you add something to the commit message about what this will gain
us (i.e. which pages we don't have to reserve)? It's not immediately
obvious why we'd have page tables we wouldn't want to reserve.

>From the looks of the next patch we won't have redundant levels of
fixmap table for a given configuration, so I guess we're catering for
the case the fixmap shares a pgd/pud/pmd entry with the image mapping?

Does that happen? If so that would invalidate the assumption I make when
copying the fixmap over in [1] (see map_kernel).

To handle that either we need some special logic to copy over the
relevant bits for the fixmap (as with kasan_copy_shadow), or we need to
avoid sharing a pgd entry.

Thoughts?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397114.html

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/init.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6bacba847923..8e678d05ad84 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -36,6 +36,7 @@
>  #include <linux/swiotlb.h>
>  
>  #include <asm/fixmap.h>
> +#include <asm/kernel-pgtable.h>
>  #include <asm/memory.h>
>  #include <asm/sections.h>
>  #include <asm/setup.h>
> @@ -165,11 +166,13 @@ void __init arm64_memblock_init(void)
>  	 * Register the kernel text, kernel data, initrd, and initial
>  	 * pagetables with memblock.
>  	 */
> -	memblock_reserve(__pa(_text), _end - _text);
> +	memblock_reserve(__pa(_text), __bss_stop - _text);
>  #ifdef CONFIG_BLK_DEV_INITRD
>  	if (initrd_start)
>  		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
>  #endif
> +	memblock_reserve(__pa(idmap_pg_dir), IDMAP_DIR_SIZE);
> +	memblock_reserve(__pa(swapper_pg_dir), SWAPPER_DIR_SIZE);
>  
>  	early_init_fdt_scan_reserved_mem();
>  
> -- 
> 2.5.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	kernel-hardening@lists.openwall.com, will.deacon@arm.com,
	catalin.marinas@arm.com, leif.lindholm@linaro.org,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	stuart.yoder@freescale.com, bhupesh.sharma@freescale.com,
	arnd@arndb.de, marc.zyngier@arm.com, christoffer.dall@linaro.org
Subject: [kernel-hardening] Re: [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations
Date: Thu, 7 Jan 2016 13:55:18 +0000	[thread overview]
Message-ID: <20160107135518.GB15917@leverpostej> (raw)
In-Reply-To: <1451489172-17420-4-git-send-email-ard.biesheuvel@linaro.org>

On Wed, Dec 30, 2015 at 04:26:02PM +0100, Ard Biesheuvel wrote:
> Before introducing new statically allocated page tables and increasing
> their alignment in subsequent patches, update the reservation logic
> so that only pages that are in actual use end up as reserved with
> memblock.

Could you add something to the commit message about what this will gain
us (i.e. which pages we don't have to reserve)? It's not immediately
obvious why we'd have page tables we wouldn't want to reserve.

>From the looks of the next patch we won't have redundant levels of
fixmap table for a given configuration, so I guess we're catering for
the case the fixmap shares a pgd/pud/pmd entry with the image mapping?

Does that happen? If so that would invalidate the assumption I make when
copying the fixmap over in [1] (see map_kernel).

To handle that either we need some special logic to copy over the
relevant bits for the fixmap (as with kasan_copy_shadow), or we need to
avoid sharing a pgd entry.

Thoughts?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397114.html

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/init.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 6bacba847923..8e678d05ad84 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -36,6 +36,7 @@
>  #include <linux/swiotlb.h>
>  
>  #include <asm/fixmap.h>
> +#include <asm/kernel-pgtable.h>
>  #include <asm/memory.h>
>  #include <asm/sections.h>
>  #include <asm/setup.h>
> @@ -165,11 +166,13 @@ void __init arm64_memblock_init(void)
>  	 * Register the kernel text, kernel data, initrd, and initial
>  	 * pagetables with memblock.
>  	 */
> -	memblock_reserve(__pa(_text), _end - _text);
> +	memblock_reserve(__pa(_text), __bss_stop - _text);
>  #ifdef CONFIG_BLK_DEV_INITRD
>  	if (initrd_start)
>  		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
>  #endif
> +	memblock_reserve(__pa(idmap_pg_dir), IDMAP_DIR_SIZE);
> +	memblock_reserve(__pa(swapper_pg_dir), SWAPPER_DIR_SIZE);
>  
>  	early_init_fdt_scan_reserved_mem();
>  
> -- 
> 2.5.0
> 

  reply	other threads:[~2016-01-07 13:55 UTC|newest]

Thread overview: 156+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 15:25 [PATCH v2 00/13] arm64: implement support for KASLR Ard Biesheuvel
2015-12-30 15:25 ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:25 ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 01/13] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 02/13] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-05 14:36   ` Christoffer Dall
2016-01-05 14:36     ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:36     ` Christoffer Dall
2016-01-05 14:46     ` Mark Rutland
2016-01-05 14:46       ` [kernel-hardening] " Mark Rutland
2016-01-05 14:46       ` Mark Rutland
2016-01-05 14:58       ` Christoffer Dall
2016-01-05 14:58         ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:58         ` Christoffer Dall
2015-12-30 15:26 ` [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-07 13:55   ` Mark Rutland [this message]
2016-01-07 13:55     ` [kernel-hardening] " Mark Rutland
2016-01-07 13:55     ` Mark Rutland
2016-01-07 14:02     ` Ard Biesheuvel
2016-01-07 14:02       ` [kernel-hardening] " Ard Biesheuvel
2016-01-07 14:02       ` Ard Biesheuvel
2016-01-07 14:25       ` Mark Rutland
2016-01-07 14:25         ` [kernel-hardening] " Mark Rutland
2016-01-07 14:25         ` Mark Rutland
2015-12-30 15:26 ` [PATCH v2 04/13] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-06 16:35   ` James Morse
2016-01-06 16:35     ` [kernel-hardening] " James Morse
2016-01-06 16:35     ` James Morse
2016-01-06 16:42     ` Ard Biesheuvel
2016-01-06 16:42       ` [kernel-hardening] " Ard Biesheuvel
2016-01-06 16:42       ` Ard Biesheuvel
2016-01-08 12:00   ` Catalin Marinas
2016-01-08 12:00     ` [kernel-hardening] " Catalin Marinas
2016-01-08 12:00     ` Catalin Marinas
2016-01-08 12:05     ` Ard Biesheuvel
2016-01-08 12:05       ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 12:05       ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 05/13] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-04 10:08   ` Marc Zyngier
2016-01-04 10:08     ` [kernel-hardening] " Marc Zyngier
2016-01-04 10:08     ` Marc Zyngier
2016-01-04 10:31     ` Ard Biesheuvel
2016-01-04 10:31       ` [kernel-hardening] " Ard Biesheuvel
2016-01-04 10:31       ` Ard Biesheuvel
2016-01-04 11:02       ` Marc Zyngier
2016-01-04 11:02         ` [kernel-hardening] " Marc Zyngier
2016-01-04 11:02         ` Marc Zyngier
2016-01-05 14:41   ` Christoffer Dall
2016-01-05 14:41     ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:41     ` Christoffer Dall
2016-01-05 14:51     ` Ard Biesheuvel
2016-01-05 14:51       ` [kernel-hardening] " Ard Biesheuvel
2016-01-05 14:51       ` Ard Biesheuvel
2016-01-05 14:56       ` Christoffer Dall
2016-01-05 14:56         ` [kernel-hardening] " Christoffer Dall
2016-01-05 14:56         ` Christoffer Dall
2015-12-30 15:26 ` [PATCH v2 06/13] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 07/13] arm64: add support for module PLTs Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 08/13] arm64: use relative references in exception tables Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 09/13] arm64: avoid R_AARCH64_ABS64 relocations for Image header fields Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 10/13] arm64: avoid dynamic relocations in early boot code Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-08 11:26   ` Mark Rutland
2016-01-08 11:26     ` [kernel-hardening] " Mark Rutland
2016-01-08 11:26     ` Mark Rutland
2016-01-08 11:34     ` Ard Biesheuvel
2016-01-08 11:34       ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 11:34       ` Ard Biesheuvel
2016-01-08 11:43       ` Mark Rutland
2016-01-08 11:43         ` [kernel-hardening] " Mark Rutland
2016-01-08 11:43         ` Mark Rutland
2016-01-08 15:27   ` Catalin Marinas
2016-01-08 15:27     ` [kernel-hardening] " Catalin Marinas
2016-01-08 15:27     ` Catalin Marinas
2016-01-08 15:30     ` Ard Biesheuvel
2016-01-08 15:30       ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 15:30       ` Ard Biesheuvel
2016-01-08 15:36     ` Mark Rutland
2016-01-08 15:36       ` [kernel-hardening] " Mark Rutland
2016-01-08 15:36       ` Mark Rutland
2016-01-08 15:48       ` Catalin Marinas
2016-01-08 15:48         ` [kernel-hardening] " Catalin Marinas
2016-01-08 15:48         ` Catalin Marinas
2016-01-08 16:14         ` Mark Rutland
2016-01-08 16:14           ` [kernel-hardening] " Mark Rutland
2016-01-08 16:14           ` Mark Rutland
2015-12-30 15:26 ` [PATCH v2 12/13] arm64: add support for relocatable kernel Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-05 19:51   ` Kees Cook
2016-01-05 19:51     ` [kernel-hardening] " Kees Cook
2016-01-05 19:51     ` Kees Cook
2016-01-06  7:51     ` Ard Biesheuvel
2016-01-06  7:51       ` [kernel-hardening] " Ard Biesheuvel
2016-01-06  7:51       ` Ard Biesheuvel
2016-01-08 10:17   ` James Morse
2016-01-08 10:17     ` [kernel-hardening] " James Morse
2016-01-08 10:17     ` James Morse
2016-01-08 10:25     ` Ard Biesheuvel
2016-01-08 10:25       ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 10:25       ` Ard Biesheuvel
2016-01-08 12:36   ` Mark Rutland
2016-01-08 12:36     ` [kernel-hardening] " Mark Rutland
2016-01-08 12:36     ` Mark Rutland
2016-01-08 12:38     ` Ard Biesheuvel
2016-01-08 12:38       ` [kernel-hardening] " Ard Biesheuvel
2016-01-08 12:38       ` Ard Biesheuvel
2016-01-08 12:40       ` Mark Rutland
2016-01-08 12:40         ` [kernel-hardening] " Mark Rutland
2016-01-08 12:40         ` Mark Rutland
2016-01-08 12:41     ` [PATCH] arm64: split elf relocs into a separate header Mark Rutland
2016-01-08 15:59       ` Will Deacon
2016-01-12 11:55         ` Ard Biesheuvel
2015-12-30 15:26 ` [PATCH v2 13/13] arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness Ard Biesheuvel
2015-12-30 15:26   ` [kernel-hardening] " Ard Biesheuvel
2015-12-30 15:26   ` Ard Biesheuvel
2016-01-05 19:53   ` Kees Cook
2016-01-05 19:53     ` [kernel-hardening] " Kees Cook
2016-01-05 19:53     ` Kees Cook
2016-01-06  7:51     ` Ard Biesheuvel
2016-01-06  7:51       ` [kernel-hardening] " Ard Biesheuvel
2016-01-06  7:51       ` Ard Biesheuvel
2016-01-07 18:46   ` Mark Rutland
2016-01-07 18:46     ` [kernel-hardening] " Mark Rutland
2016-01-07 18:46     ` Mark Rutland
2016-01-07 19:07     ` Kees Cook
2016-01-07 19:07       ` [kernel-hardening] " Kees Cook
2016-01-07 19:07       ` Kees Cook
2016-01-05 20:08 ` [PATCH v2 00/13] arm64: implement support for KASLR Kees Cook
2016-01-05 20:08   ` [kernel-hardening] " Kees Cook
2016-01-05 20:08   ` Kees Cook
2016-01-05 21:24   ` Ard Biesheuvel
2016-01-05 21:24     ` [kernel-hardening] " Ard Biesheuvel
2016-01-05 21:24     ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160107135518.GB15917@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhupesh.sharma@freescale.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=stuart.yoder@freescale.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.