[PATCH 1/6 v14] ARM: Handle a device tree in lowmem

[Linus Walleij]

On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel <ardb at kernel.org> wrote:

> > Let me see if I can code up a PoC
>
> I pushed a branch to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-dt-mapping
>
> that moves the DT mapping to a read-only region at the top of the
> kernel VA space: there happened to be a 4 MB hole there (between
> VMALLOC_END and FIXADDR_START) that we can use, even if the purpose of
> that hole was as a guard region, as a read-only mapping still catches
> stray writes.

I will test it when I'm back at the hardware.
I tried to do this thing as well but couldn't figure out a good
place to map it, putting it between VMALLOC_END
and FIXADDR_START seems like a good idea!

But this is going to be a problem:

+ map.type = MT_ROM;

Because the current code calls unflatten_device_tree() which
will unflatten the device tree right where it is.
So then the memory needs to be RW.

This is why in my patch I change that to
unflatten_and_copy_device_tree() so I can treat
it as a ROM, unflatten and copy that and then
ditch the memory where the device tree is so the
kernel does not need to work around that.

(unflatten_and_copy_device_tree()
will not delete the memblock around the device
tree, so that would need to be fixed in my patch.)

With your patch, if we call
unflatten_and_copy_device_tree() we can use
MT_ROM but then we would want to get rid of the
remapped memory and memblock
for the device tree after copying and unflattening
it, but since there is no delete_mapping()
counterpart to create_mapping() I guess that
is going to be hard?

> What I don't get is why the DT *contents* get clobbered -
> arm_memblock_init() memblock_reserve's the DT contents, and wiping
> reserved memblocks is something we really shouldn't be doing.

The contents are fine on my system, just the two section
mappings get wiped.

I hope my previous mail explains that, the code in
prepare_page_table() simply just wipes the lowmem
PMDs without any regard for any reserved memblocks being
in that range.

Yours,
Linus Walleij