Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1304654

Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory

From Mark Rutland <mark.rutland@arm.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
Date 2016-01-08 16:40 +0100
Message-ID <qOHiV-cO-3@gated-at.bofh.it> (permalink)
References <qLqRk-8m8-9@gated-at.bofh.it> <qLqRl-8m8-31@gated-at.bofh.it> <qOH9g-8Y-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jan 08, 2016 at 03:27:38PM +0000, Catalin Marinas 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).

Which will be hopelessly broken in the presence of KASLR, the kernel
being loaded at a different address, pages betting reserved differently
due to page size, etc.

I hope that no-one usees this for anything other than testing low-memory
conditions. If they want to steal memory they need to carve it out
explicitly.

We can behave as we used to, but we shouldn't give the impression that
such usage is supported.

Thanks,
Mark.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere  in physical memory Catalin Marinas <catalin.marinas@arm.com> - 2016-01-08 16:30 +0100
  Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere  in physical memory Mark Rutland <mark.rutland@arm.com> - 2016-01-08 16:40 +0100
    Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere  in physical memory Catalin Marinas <catalin.marinas@arm.com> - 2016-01-08 16:50 +0100
      Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere  in physical memory Mark Rutland <mark.rutland@arm.com> - 2016-01-08 17:20 +0100
  Re: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere  in physical memory Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-01-08 16:40 +0100

csiph-web