All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	kernel-hardening@lists.openwall.com,
	Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Sharma Bhupesh <bhupesh.sharma@freescale.com>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 16:30:20 +0100	[thread overview]
Message-ID: <CAKv+Gu8dJQN98h9PrCFDyRa59UauDuxHCFPBrVyxrFG+f_No0g@mail.gmail.com> (raw)
In-Reply-To: <20160108152738.GG16432@e104818-lin.cambridge.arm.com>

On 8 January 2016 at 16:27, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Dec 30, 2015 at 04:26:10PM +0100, Ard Biesheuvel wrote:
>> +static void __init enforce_memory_limit(void)
>> +{
>> +     const phys_addr_t kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>> +     u64 to_remove = memblock_phys_mem_size() - memory_limit;
>> +     phys_addr_t max_addr = 0;
>> +     struct memblock_region *r;
>> +
>> +     if (memory_limit == (phys_addr_t)ULLONG_MAX)
>> +             return;
>> +
>> +     /*
>> +      * The kernel may be high up in physical memory, so try to apply the
>> +      * limit below the kernel first, and only let the generic handling
>> +      * take over if it turns out we haven't clipped enough memory yet.
>> +      */
>> +     for_each_memblock(memory, r) {
>> +             if (r->base + r->size > kbase) {
>> +                     u64 rem = min(to_remove, kbase - r->base);
>> +
>> +                     max_addr = r->base + rem;
>> +                     to_remove -= rem;
>> +                     break;
>> +             }
>> +             if (to_remove <= r->size) {
>> +                     max_addr = r->base + to_remove;
>> +                     to_remove = 0;
>> +                     break;
>> +             }
>> +             to_remove -= r->size;
>> +     }
>> +
>> +     memblock_remove(0, max_addr);
>> +
>> +     if (to_remove)
>> +             memblock_enforce_memory_limit(memory_limit);
>> +}
>
> IIUC, this is changing the user expectations a bit. There are people
> using the mem= limit to hijack some top of the RAM for other needs
> (though they could do it in a saner way like changing the DT memory
> nodes). Your patch first tries to remove the memory below the kernel
> image and only remove the top if additional limitation is necessary.
>
> Can you not remove memory from the top and block the limit if it goes
> below the end of the kernel image, with some warning that memory limit
> was not entirely fulfilled?
>

I'm in the middle of rewriting this code from scratch. The general idea is

static void __init clip_mem_range(u64 min, u64 max);

/*
* Clip memory in order of preference:
* - above the kernel and above 4 GB
* - between 4 GB and the start of the kernel
* - below 4 GB
* Note that tho
*/
clip_mem_range(max(sz_4g, PAGE_ALIGN(__pa(_end))), ULLONG_MAX);
clip_mem_range(sz_4g, round_down(__pa(_text), MIN_KIMG_ALIGN));
clip_mem_range(0, sz_4g);

where clip_mem_range() iterates over the memblocks to remove memory
between min and max iff min < max and the limit has not been met yet.

WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 16:30:20 +0100	[thread overview]
Message-ID: <CAKv+Gu8dJQN98h9PrCFDyRa59UauDuxHCFPBrVyxrFG+f_No0g@mail.gmail.com> (raw)
In-Reply-To: <20160108152738.GG16432@e104818-lin.cambridge.arm.com>

On 8 January 2016 at 16:27, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Dec 30, 2015 at 04:26:10PM +0100, Ard Biesheuvel wrote:
>> +static void __init enforce_memory_limit(void)
>> +{
>> +     const phys_addr_t kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>> +     u64 to_remove = memblock_phys_mem_size() - memory_limit;
>> +     phys_addr_t max_addr = 0;
>> +     struct memblock_region *r;
>> +
>> +     if (memory_limit == (phys_addr_t)ULLONG_MAX)
>> +             return;
>> +
>> +     /*
>> +      * The kernel may be high up in physical memory, so try to apply the
>> +      * limit below the kernel first, and only let the generic handling
>> +      * take over if it turns out we haven't clipped enough memory yet.
>> +      */
>> +     for_each_memblock(memory, r) {
>> +             if (r->base + r->size > kbase) {
>> +                     u64 rem = min(to_remove, kbase - r->base);
>> +
>> +                     max_addr = r->base + rem;
>> +                     to_remove -= rem;
>> +                     break;
>> +             }
>> +             if (to_remove <= r->size) {
>> +                     max_addr = r->base + to_remove;
>> +                     to_remove = 0;
>> +                     break;
>> +             }
>> +             to_remove -= r->size;
>> +     }
>> +
>> +     memblock_remove(0, max_addr);
>> +
>> +     if (to_remove)
>> +             memblock_enforce_memory_limit(memory_limit);
>> +}
>
> IIUC, this is changing the user expectations a bit. There are people
> using the mem= limit to hijack some top of the RAM for other needs
> (though they could do it in a saner way like changing the DT memory
> nodes). Your patch first tries to remove the memory below the kernel
> image and only remove the top if additional limitation is necessary.
>
> Can you not remove memory from the top and block the limit if it goes
> below the end of the kernel image, with some warning that memory limit
> was not entirely fulfilled?
>

I'm in the middle of rewriting this code from scratch. The general idea is

static void __init clip_mem_range(u64 min, u64 max);

/*
* Clip memory in order of preference:
* - above the kernel and above 4 GB
* - between 4 GB and the start of the kernel
* - below 4 GB
* Note that tho
*/
clip_mem_range(max(sz_4g, PAGE_ALIGN(__pa(_end))), ULLONG_MAX);
clip_mem_range(sz_4g, round_down(__pa(_text), MIN_KIMG_ALIGN));
clip_mem_range(0, sz_4g);

where clip_mem_range() iterates over the memblocks to remove memory
between min and max iff min < max and the limit has not been met yet.

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	kernel-hardening@lists.openwall.com,
	Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Sharma Bhupesh <bhupesh.sharma@freescale.com>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: [kernel-hardening] Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date: Fri, 8 Jan 2016 16:30:20 +0100	[thread overview]
Message-ID: <CAKv+Gu8dJQN98h9PrCFDyRa59UauDuxHCFPBrVyxrFG+f_No0g@mail.gmail.com> (raw)
In-Reply-To: <20160108152738.GG16432@e104818-lin.cambridge.arm.com>

On 8 January 2016 at 16:27, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Dec 30, 2015 at 04:26:10PM +0100, Ard Biesheuvel wrote:
>> +static void __init enforce_memory_limit(void)
>> +{
>> +     const phys_addr_t kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>> +     u64 to_remove = memblock_phys_mem_size() - memory_limit;
>> +     phys_addr_t max_addr = 0;
>> +     struct memblock_region *r;
>> +
>> +     if (memory_limit == (phys_addr_t)ULLONG_MAX)
>> +             return;
>> +
>> +     /*
>> +      * The kernel may be high up in physical memory, so try to apply the
>> +      * limit below the kernel first, and only let the generic handling
>> +      * take over if it turns out we haven't clipped enough memory yet.
>> +      */
>> +     for_each_memblock(memory, r) {
>> +             if (r->base + r->size > kbase) {
>> +                     u64 rem = min(to_remove, kbase - r->base);
>> +
>> +                     max_addr = r->base + rem;
>> +                     to_remove -= rem;
>> +                     break;
>> +             }
>> +             if (to_remove <= r->size) {
>> +                     max_addr = r->base + to_remove;
>> +                     to_remove = 0;
>> +                     break;
>> +             }
>> +             to_remove -= r->size;
>> +     }
>> +
>> +     memblock_remove(0, max_addr);
>> +
>> +     if (to_remove)
>> +             memblock_enforce_memory_limit(memory_limit);
>> +}
>
> IIUC, this is changing the user expectations a bit. There are people
> using the mem= limit to hijack some top of the RAM for other needs
> (though they could do it in a saner way like changing the DT memory
> nodes). Your patch first tries to remove the memory below the kernel
> image and only remove the top if additional limitation is necessary.
>
> Can you not remove memory from the top and block the limit if it goes
> below the end of the kernel image, with some warning that memory limit
> was not entirely fulfilled?
>

I'm in the middle of rewriting this code from scratch. The general idea is

static void __init clip_mem_range(u64 min, u64 max);

/*
* Clip memory in order of preference:
* - above the kernel and above 4 GB
* - between 4 GB and the start of the kernel
* - below 4 GB
* Note that tho
*/
clip_mem_range(max(sz_4g, PAGE_ALIGN(__pa(_end))), ULLONG_MAX);
clip_mem_range(sz_4g, round_down(__pa(_text), MIN_KIMG_ALIGN));
clip_mem_range(0, sz_4g);

where clip_mem_range() iterates over the memblocks to remove memory
between min and max iff min < max and the limit has not been met yet.

  reply	other threads:[~2016-01-08 15:30 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
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 [this message]
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=CAKv+Gu8dJQN98h9PrCFDyRa59UauDuxHCFPBrVyxrFG+f_No0g@mail.gmail.com \
    --to=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=mark.rutland@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.