linux-kernel - Re: [PATCH 1/6] arm64: Unconditionally call unflatten_device

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: <20240117175448.GB2779523-robh@kernel.org>
Date: Wed, 17 Jan 2024 11:54:48 -0600
From: Rob Herring <robh@...nel.org>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org,
	patches@...ts.linux.dev, linux-um@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org, kunit-dev@...glegroups.com,
	linux-kselftest@...r.kernel.org, devicetree@...r.kernel.org,
	Frank Rowand <frowand.list@...il.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>
Subject: Re: [PATCH 1/6] arm64: Unconditionally call unflatten_device_tree()

On Tue, Jan 16, 2024 at 05:27:18PM -0800, Stephen Boyd wrote:
> Quoting Mark Rutland (2024-01-16 03:51:14)
> > Hi Stephen,
> > 
> > On Fri, Jan 12, 2024 at 12:07:44PM -0800, Stephen Boyd wrote:
> > > Call this function unconditionally so that we can populate an empty DTB
> > > on platforms that don't boot with a firmware provided or builtin DTB.
> > > There's no harm in calling unflatten_device_tree() unconditionally.
> > 
> > For better or worse, that's not true: there are systems the provide both a DTB
> > *and* ACPI tables, and we must not consume both at the same time as those can
> > clash and cause all sorts of problems. In addition, we don't want people being
> > "clever" and describing disparate portions of their system in ACPI and DT.
> > 
> > It is a very deliberate choice to not unflatten the DTB when ACPI is in use,
> > and I don't think we want to reopen this can of worms.
> 
> Hmm ok. I missed this part. Can we knock out the initial_boot_params in
> this case so that we don't unflatten a DTB when ACPI is in use?

You mean so we don't unflatten the boot DTB, but instead unflatten the 
empty one, right? That sounds fine.

Another thing to check is kexec because it will still need the original 
DTB I think. Though if you are doing ACPI boot and kexec'ing, kexec may 
write out everything needed by the next kernel and the empty DTB would 
work just fine. Of course those users booting with ACPI and then 
kexec'ing to DT boot will be broken. Perhaps that's a feature...

Rob