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:   Mon, 26 Jun 2023 10:22:45 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     运辉崔 <cuiyunhui@...edance.com>
Cc:     ron minnich <rminnich@...il.com>,
        Mark Rutland <mark.rutland@....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,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-acpi@...r.kernel.org,
        葛士建 <geshijian@...edance.com>,
        韦东 <weidong.wd@...edance.com>
Subject: Re: [External] Re: [PATCH] firmware: added a firmware information
 passing method FFI

On Mon, 26 Jun 2023 at 10:05, 运辉崔 <cuiyunhui@...edance.com> wrote:
>
> Hi Ard,
>
> On Mon, Jun 26, 2023 at 2:43 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> > I think all of this belongs under arch/riscv
>
> Could you look at the content of the patch again? As we discussed
> before, we need to connect to the ACPI and the SMBIOS entry
> At least this part of the code has to be placed in the corresponding place:
> drivers/acpi/osl.c: acpi_os_get_root_pointer()
> drivers/firmware/dmi_scan.c:dmi_scan_machine()
>
> Because obtaining firmware information through DTS belongs to the
> content of the driver firmware, it is appropriate to put this piece of
> code in drivers/firmware/ffi.c.
>
> So I insist on the current revision, what do you think?
>

DT support for SMBIOS can live in generic code, but the binding has to
be sane. As I suggested before, it probably makes sense to supplant
the entrypoint rather than just carry its address - this means a 'reg'
property with base and size to describe the physical region, and at
least major/minor/docrev fields to describe the version.

In any case, there is really no point in supporting both entrypoints
(this applies to the ACPI root pointer as well).

For the ACPI side, you should just implement
acpi_arch_get_root_pointer() under arch/riscv, and wire it up in
whichever way you want. But please check with the RISC-V maintainers
if they are up for this, and whether they want to see this mechanism
contributed to one of the pertinent specifications.

So NAK on the current revision, in case this was unclear.