linux-kernel - Re: [PATCH] [RESEND] arm: limit memblock base address for early_pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jun 2012 10:08:27 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:	Dave Martin <dave.martin@...aro.org>,
	Minchan Kim <minchan@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Chanho Min <chanho.min@....com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Jongsung Kim <neidhard.kim@....com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] [RESEND] arm: limit memblock base address for
	early_pte_alloc

On Thu, Jun 28, 2012 at 12:33:02AM -0400, Nicolas Pitre wrote:
> I propose the following two patches instead -- both patches are included 
> inline not to break the email thread.  What do you think?
> 
> ---------- >8
> 
> From: Nicolas Pitre <nicolas.pitre@...aro.org>
> Date: Wed, 27 Jun 2012 23:02:31 -0400
> Subject: [PATCH] ARM: head.S: simplify initial page table mapping
> 
> Let's map the initial RAM up to the end of the kernel.bss plus 64MB
> instead of the strict kernel image area.  This simplifies the code
> as the kernel image only needs to be handled specially in the XIP case.
> This also give some room for the early memory allocator to use before
> the real mapping is finally installed with the actual amount of memory.
> 
> Signed-off-by: Nicolas Pitre <nico@...aro.org>

Why is this needed?  The initial allocation is sufficient, and you really
should not be wanting to _allocate_ memory in your ->reserve method and
have it be _usable_ at that point.

> Early on the only accessible memory comes from the initial mapping
> performed in head.S, minus those page table entries cleared in
> prepare_page_table().  Eventually the full lowmem is available once
> map_lowmem() has mapped it.  Let's have this properly reflected in the
> memblock allocator limit.

Err, I don't think you understand what's going on here.

The sequence is:

1. setup the initial mappings so we can run the kernel in virtual space.
2. provide the memory areas to memblock
3. ask the platform to reserve whatever memory it wants from memblock
   [this means using memblock_reserve or arm_memblock_steal).  The
   reserved memory is *not* expected to be mapped at this point, and is
   therefore inaccessible.
4. Setup the lowmem mappings.

And when we're setting up the lowmem mappings, we do *not* expect to
create any non-section page mappings, which again means we have no reason
to use the memblock allocator to obtain memory that we want to immediately
use.

So I don't know where you're claim of being "fragile" is coming from.

What is fragile is people wanting to use arm_memblock_steal() without
following the rules for it I layed down.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/