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

Message-ID: <CAEEQ3w=495snOz3UNBO4dpgyfZs3jQoRKo4QRAXXqR5-0j4SWA@mail.gmail.com>
Date:   Fri, 28 Apr 2023 11:17:56 +0800
From:   运辉崔 <cuiyunhui@...edance.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>,
        ron minnich <rminnich@...il.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

Hi Ard, Mark,

On Thu, Apr 27, 2023 at 8:52 PM Ard Biesheuvel <ardb@...nel.org> wrote:

> 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.

Judging from the current kernel, getting acpi smbios, memmap tables is
not just a way to have EFI, right?
smbios:SMBIOS_ENTRY_POINT_SCAN_START
acpi:CONFIG_ACPI_LEGACY_TABLES_LOOKUP
memmap: e820

Our current situation is that coreboot does not support EFI, but supports fdt,
but we need to support ACPI,  and riscv does not have a reserved
address segment
like x86 that can be used, so our current solution is to pass acpi and
other tables through fdt.

Based on this, do you have a better suggestion ?

Thanks，
Yunhui