linux-kernel - reserved_mem and early builtin device tree usage

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>] [day] [month] [year] [list]

Date:   Mon, 11 May 2020 23:18:43 +0200 (CEST)
From:   Clément Leger <cleger@...ray.eu>
To:     Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: reserved_mem and early builtin device tree usage

Hi,

I'm currently experiencing a bug during the port of the kernel on
a new architecture and after looking at other architectures, I
suspect the problem might be there too. my question is about
reserved memories and usage of early device tree.

>From what I understand, when reserved memory is initialized using
early_init_fdt_scan_reserved_mem, the reserved memories are
created using some pointers inside the early dt (mainly the names).
If this early device tree is located into the init section (when
using a builtin dtb for instance), this section will be discarded
(when calling free_initmem_default) and memset with a zero/poison
value. So all pointers which are referencing the early dt will be
invalid. This will clobber all the "names" of the reserved memory
entries. As a side effect, all drivers using of_reserved_mem_lookup
after the init section has been freed will always failed because
the search is based on the name of the reserved mem.

I also said that it might be present on other architectures because
the usual function call I found is the following:
- early_init_dt_scan
- early_init_fdt_reserve_self (only reserve memory in memblock)
- early_init_fdt_scan_reserved_mem
- unflatten_and_copy_device_tree
- free_initmem_default
- potential calls to of_reserved_mem_lookup

Which (if the device tree is builtin in init section) will lead
to the result I described before. 

So my question is about the legit usage of pointers referencing
the early dtb. If is it ok to use such pointers, this means that
the early dtb must always be available and that when using a
builtin dtb, then it should probably be copied early before
using it for scan operations with unflatten_and_copy_device_tree.

However, since the scan of the reserved mem nodes is required to
avoid allocating in reserved memory, unflatten_and_copy_device_tree
should probably not be called before early_init_fdt_scan_reserved_mem
since it allocates data. So this is a bit of the snake biting its
tail and thus, early dt pointers should probably not be used.

Is my understanding correct ? Or have I missed something since it
seems to haven't been noticed on other architectures ?

Thanks & regards,

Clément