linux-kernel - Re: [PATCH v2 2/2] efi/fdt: ignore dtb when acpi option is used with force

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: <CAMj1kXFOdGaYiVWOyFEK+Lz97YdzAu+AWj5trZBTL+Xc_DXnmA@mail.gmail.com>
Date: Mon, 25 Nov 2024 18:53:14 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Levi Yun <yeoreum.yun@....com>
Cc: broonie@...nel.org, sami.mujawar@....com, sudeep.holla@....com, 
	pierre.gondois@....com, hagarhem@...zon.com, catalin.marinas@....com, 
	will@...nel.org, guohanjun@...wei.com, Jonathan.Cameron@...wei.com, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-efi@...r.kernel.org
Subject: Re: [PATCH v2 2/2] efi/fdt: ignore dtb when acpi option is used with force

On Mon, 25 Nov 2024 at 18:46, Levi Yun <yeoreum.yun@....com> wrote:
>
> Hi Ard.
>
> > I take it this is working around buggy firmware that passes both a DT
> > and ACPI tables, and the DT in question is broken?
> >
> > If so, this should be fixed in the firmware. The EFI stub does not
> > reason at all about ACPI boot vs DT boot, and I would prefer to keep
> > it that way, especially because this code is shared with other
> > architectures. For instance, the meaning of acpi= could differ between
> > architectures, or they may not implement ACPI in the first place.
>
> What I concern is that It doesntt necessary to check DT
> otherwise if the FDT variable in variable storage's contents is
> corrupted, it would complain while it check in early_init_dt_scan()
> thou the dt isn't used in boot process.
>

The DT is not stored in a variable.

If CONFIG_EFI_ARMSTUB_DTB_LOADER is enabled, it may be provided via
dtb= on the command line, but I have little sympathy for a user that
passes both dtb= *and* acpi=force, so this is a scenario that we can
ignore.

Otherwise, it is taken from a EFI config table, which is just a
<guid,addr> tuple describing a location in physical memory where the
firmware has placed a DT. If the firmware puts a corrupted DT there,
the firmware should be fixed instead.

acpi=force is intended to force the use of ACPI tables on a system
that provides both.

> also, although acpi= could differ from architecture, the force option's menaing
> seems the same over architecture (ignore DT boot with ACPI tables).
>
> So I think the check the "acpi=force" option to prevent loading DT seems
> good.
>

The EFI stub does not care about ACPI vs DT boot, and I'd prefer to
keep it that way unless there is a good reason.

Which real-world problem does this patch aim to solve?