linux-kernel - Re: [External] Re: [PATCH] firmware: added a firmware information passing method FFI

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]

Date:   Thu, 27 Apr 2023 13:52:25 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     ron minnich <rminnich@...il.com>,
        运辉崔 <cuiyunhui@...edance.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>, rafael@...nel.org,
        lenb@...nel.org, jdelvare@...e.com, yc.hung@...iatek.com,
        angelogioacchino.delregno@...labora.com,
        allen-kh.cheng@...iatek.com, pierre-louis.bossart@...ux.intel.com,
        tinghan.shen@...iatek.com, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
 passing method FFI

On Thu, 27 Apr 2023 at 12:24, Mark Rutland <mark.rutland@....com> wrote:
>
> On Wed, Apr 26, 2023 at 09:04:56PM -0700, ron minnich wrote:
> > The device tree is self describing data. Adding new information is easy. If you
> > add new information to a node, and older software does not know about it, it is
> > no big deal.
>
> It's true that it's easy to add fields to an extensible format, but that wasn't
> my point of contention. The *semantic* (e.g. all of the relevant DT bindings)
> and *consumption* of that data is the important part, and that's what I was
> referring to, though I appreciate my wording did not make that clear.
>
> > So I can't agree with this comment: "We'd have to create entirely new ways to
> > pass that information, which is not
> > very desirable."
> >
> > The whole point of the dt is that you can always add new ways to pass
> > information, by design.
> >
> > Adding memory attributes would be quite easy.
>
> I don't disagree that is physically possible, and in isolation adding
> properties to a DT is trivial, but the approach proposed is not "easy" unless
> you ignore the cost of specifying analogues for all the EFI portions that you
> plan to omit, ensuring that those stay functionally equivalent to their EFI
> analogues as EFI and ACPI evolve over time, developing and maintaining the code
> which must consume that, avoiding the issues that will arise due to novel
> interactions (as e.g. DT and ACPI are mutually exclusive today, by design),
> etc.
>

Indeed. Currently, Linux/arm64 supports two boot methods

- direct kernel boot
- EFI boot

and two types of hardware descriptions

- device tree (DT)
- ACPI

and the only combination we do not support is ACPI without EFI, as
ACPI on arm64 depends on the EFI memory map.

What this patch seems to be proposing is a combination of all of
these, i.e., doing a pseudo-EFI direct kernel boot where the EFI
dependencies of ACPI are being fulfilled by ad-hoc descriptions passed
in via DT.

I am concerned that this will result in a maintenance burden for Linux
with very little gain, so I feel we should not go down this road.