linux-kernel - Re: [PATCH v2 03/13] arm64: use more granular reservations for static page table allocations

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, 7 Jan 2016 15:02:00 +0100
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	kernel-hardening@...ts.openwall.com,
	Will Deacon <will.deacon@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stuart Yoder <stuart.yoder@...escale.com>,
	Sharma Bhupesh <bhupesh.sharma@...escale.com>,
	Arnd Bergmann <arnd@...db.de>,
	Marc Zyngier <marc.zyngier@....com>,
	Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v2 03/13] arm64: use more granular reservations for static
 page table allocations

On 7 January 2016 at 14:55, Mark Rutland <mark.rutland@....com> wrote:
> 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.
>

OK. In the original series, I also aligned the pgdir section to a log2
upper bound of its size, but that is not necessary anymore with your
changes. So the original goal was to avoid reserving the alignment
padding as well as the pgdirs that end up unused

> 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).
>

It is a lot less likely to happen now that I moved the kernel to the
start of the vmalloc area rather than right below PAGE_OFFSET. But in
general, it seems sensible to only populate entries after confirming
that they are in fact vacant.

> 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?
>

Yes, I have added that to my v3 version of the vmalloc base move patch here

https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/commitdiff/0beef2c1a6bfc90cc116a6ba1b24f2ba35e7e5f6

but I think 16k/4 levels is the only config affected when the kernel
is always in the lower half of the vmalloc area. That also implies
that the fixmap pgd is either always shared, or never, depending on
the build time config, so I could probably simplify that part
somewhat.

-- 
Ard.
--
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/