[PATCH] ARM: expand fixmap region to 3MB

[Kees Cook]

On Mon, Aug 11, 2014 at 9:14 AM, Leif Lindholm <leif.lindholm at linaro.org> wrote:
> On Fri, Aug 08, 2014 at 10:23:24AM -0500, Rob Herring wrote:
>> From: Rob Herring <robh at kernel.org>
>>
>> With commit a05e54c103b0b8 "ARM: 8031/2: change fixmap mapping region to
>> support 32 CPUs", the fixmap region was expanded to 2MB, but it
>> precluded any other uses of the fixmap region in order to support up to
>> 32 CPUs. In order to support other uses the fixmap region needs to be
>> expanded beyond 2MB. Fortunately, the adjacent 1MB range
>> 0xffe00000-0xfff00000 is availabe to use.
>>
>> Remove fixmap_page_table ptr and lookup the page table via the virtual
>> address so that the fixmap region can span more that one pmd. The 2nd
>> pmd is already created since it is shared with the vector page.
>>
>> Cc: Leif Lindholm <leif.lindholm at linaro.org>
>> Cc: Kees Cook <keescook at chromium.org>
>> Cc: Russell King <linux at arm.linux.org.uk>
>> Signed-off-by: Rob Herring <robh at kernel.org>
>> ---
>>
>> This patch can come before or after the generic fixmap.h. There's a
>> single line conflict with the ending address
>
> Tested-by: Leif Lindholm <leif.lindholm at linaro.org>
> For Kees' set with this addition + generic fixmap + early_ioremap +
> UEFI.
>
>> This worked for earlycon, but I've not done any highmem specific
>> testing. My full series is available here:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git fixmap
>
> I was hoping to be able to give you a tested-by for that series on
> next-20140811 with the UEFI patches, but that setup fails to boot
> right now. Looking into why.

For me, the 3MB change doesn't work. It acts like the PTE isn't there:

lkdtm: Performing direct entry WRITE_KERN
lkdtm: attempting 52 byte write at 804331cc
lkdtm: 804331cc mapped RW via ffe7f1cc
Unable to handle kernel paging request at virtual address ffe7f1cc
pgd = 9ea40000
[ffe7f1cc] *pgd=9fffd821, *pte=00000000, *ppte=00000000

And it weirdly leaves this hanging around in
/sys/kernel/debug/kernel_page_tables:

0xffc7f000-0xffc80000           4K     RW NX SHD MEM/CACHED/WBWA

If I use all the other changes to clean up the code, everything is
fine. The only change I have been the trees now is just this:

-#define FIXADDR_END            0xffe00000UL
+#define FIXADDR_END            0xfff00000UL

I think my build isn't catching this extra area via the vector table pmd.

So, instead of continuing to beat my head against this, I've changed
my series around to use NR_CPUS as Rob was doing, and added
BUILD_BUG_ON to check the fixmap size. The result is that there will
be a build-time limit on the number of CPUs, rather than surprising
run-time problems.

I will repost the series in a moment.

-- 
Kees Cook
Chrome OS Security