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]

Message-ID: <CAMj1kXHfqkU2QxvjTkGBSkEcTf_HirbdOReOJwdpgz3hM8fBHw@mail.gmail.com>
Date:   Sun, 25 Jun 2023 09:42:47 +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, 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 Sun, 25 Jun 2023 at 09:33, 运辉崔 <cuiyunhui@...edance.com> wrote:
>
> Hi Ard,
>
> On Sat, Jun 24, 2023 at 8:52 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > How do you intend to provide the ACPI core with the memory attribute
> > information that it needs to access SystemMemory OpRegions?
>
> Regarding memory segments and attributes, our solution does not need
> to build a memmap table in coreboot like EFI to connect to linux ACPI
> core.
>

So how do you expect the code below will behave?

arch/arm64/kernel/acpi.c:
270:void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
271-{
272-   efi_memory_desc_t *md, *region = NULL;
273-   pgprot_t prot;
274-
275-   if (WARN_ON_ONCE(!efi_enabled(EFI_MEMMAP)))
276-           return NULL;

acpi_os_ioremap() is used by all ACPI core code that needs to map MMIO
regions or DRAM from AML code. AML does not pass memory type
attributes, so we have to consult the EFI memory map for these.

As I have explained to you multiple times, ACPI on arm64 is *broken*
without the EFI memory map.

> Because the memory segment and attributes have been passed through the
> "memory" node and "reserved-memory" node attributes of DTS.
>
> For Linux, no matter what kind of memory attributes of the firmware,
> it is ultimately connected to the memblock module.
>

Incorrect. We are talking about any physical region here, not just
DRAM. And some DRAM regions may not be covered by memblock.

> So the memory attributes you consider can be done through the existing
> DTS (like Ron said before, Chrombook does everything through DTS).
>
> So can we come to a consensus? Then start reviewing the code?
>

No, sorry. Please try to understand the objections that I am raising
first. I am not saying this to annoy you, I am saying this because
your approach is flawed.