linux-kernel - Re: [PATCH 03/15] kbuild: move non-boot builtin DTBs to .init.rodata section

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]

Message-ID: <20240905134704.GB1517132-robh@kernel.org>
Date: Thu, 5 Sep 2024 08:47:04 -0500
From: Rob Herring <robh@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kbuild@...r.kernel.org, linux-arch@...r.kernel.org,
	linux-snps-arc@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Michal Simek <monstr@...str.eu>, devicetree@...r.kernel.org,
	linux-mips@...r.kernel.org, linux-openrisc@...r.kernel.org,
	Dinh Nguyen <dinguyen@...nel.org>
Subject: Re: [PATCH 03/15] kbuild: move non-boot builtin DTBs to .init.rodata
 section

On Thu, Sep 05, 2024 at 08:47:39AM +0900, Masahiro Yamada wrote:
> Some architectures support embedding boot DTB(s) in vmlinux. These
> architectures, except MIPS and MicroBlaze, expect a single DTB in
> the .dtb.init.rodata section. MIPS embeds multiple DTBs in vmlinux.
> MicroBlaze embeds a DTB in its own __fdt_blob section instead of the
> .dtb.init.rodata section.
> 
> For example, RISC-V previously allowed embedding multiple DTBs, but
> only the first DTB in the .dtb.init.rodata section was used. Commit
> 2672031b20f6 ("riscv: dts: Move BUILTIN_DTB_SOURCE to common Kconfig")
> ensured only one boot DTB is embedded.
> 
> Meanwhile, commit 7b937cc243e5 ("of: Create of_root if no dtb provided
> by firmware") introduced another DTB into the .dtb.init.rodata section.
> 
> The symbol dump (sorted by address) for ARCH=riscv nommu_k210_defconfig
> is now as follows:
> 
>     00000000801290e0 D __dtb_start
>     00000000801290e0 D __dtb_k210_generic_begin
>     000000008012b571 D __dtb_k210_generic_end
>     000000008012b580 D __dtb_empty_root_begin
>     000000008012b5c8 D __dtb_empty_root_end
>     000000008012b5e0 D __dtb_end
> 
> The .dtb.init.rodata section contains the following two DTB files:
> 
>     arch/riscv/boot/dts/canaan/k210_generic.dtb
>     drivers/of/empty_root.dtb
> 
> This is not an immediate problem because the boot code chooses the
> first DTB, k210_generic.dtb. The second one, empty_root.dtb is ignored.
> However, relying on the link order (i.e., the order in Makefiles) is
> fragile.
> 
> Only the boot DTB should be placed in the .dtb.init.rodata because the
> arch boot code generally does not know the DT name, thus it uses the
> __dtb_start symbol to find it.
> 
> empty_root.dtb is looked up by name, so it can be moved to the generic
> .init.rodata section.
> 
> When CONFIG_OF_UNITTEST is enabled, more unittest DTBOs are embedded in
> the .dtb.init.rodata section. These are also looked up by name, so can
> be moved to the .init.rodata section.
> 
> I added the __initdata annotation to the overlay_info data array because
> modpost knows the .init.rodata section is discarded, and would otherwise
> warn about it.
> 
> The implementation is kind of cheesy; the section is .dtb.init.rodata
> under the arch/ directory, and .init.rodata section otherwise. This will
> be refactored later.
> 
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
> 
>  drivers/of/unittest.c | 2 +-
>  scripts/Makefile.dtbs | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Rob Herring (Arm) <robh@...nel.org>