On Mon, 5 Oct 2020 at 15:27, Linus Walleij [off-list ref] wrote:

On Mon, Oct 5, 2020 at 11:14 AM Ard Biesheuvel [off-list ref] wrote:

quoted

On Mon, 5 Oct 2020 at 09:14, Ard Biesheuvel [off-list ref] wrote:

quoted

quoted

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.

I don't think this is the case. Note that arm64 has been using r/o
mappings for the device tree for a long time, and it calls
unflatten_device_tree() without any problems.

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?

quoted

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.

Ah ok.

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.

In that case, mapping the DT outside of the linear region should solve
this entirely.

Note that this code boots fine for me. The only question I have is
whether the ATAGS based systems require the ability to make changes to
the data structure at runtime.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel