linux-kernel - Re: [External] [PATCH v2 1/3] riscv: obtain ACPI RSDP from 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: <87sfa1toap.fsf@all.your.base.are.belong.to.us>
Date:   Thu, 06 Jul 2023 10:52:14 +0200
From:   Björn Töpel <bjorn@...nel.org>
To:     运辉崔 <cuiyunhui@...edance.com>
Cc:     Jessica Clarke <jrtc27@...c27.com>,
        Emil Renner Berthing <emil.renner.berthing@...il.com>,
        Andrew Jones <ajones@...tanamicro.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        rminnich@...il.com, Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Len Brown <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 <linux-kernel@...r.kernel.org>,
        linux-acpi@...r.kernel.org, geshijian@...edance.com,
        weidong.wd@...edance.com, graf@...zon.de
Subject: Re: [External] [PATCH v2 1/3] riscv: obtain ACPI RSDP from FFI.

运辉崔 <cuiyunhui@...edance.com> writes:

> Hi Björn,
>
> On Wed, Jul 5, 2023 at 10:43 PM Björn Töpel <bjorn@...nel.org> wrote:
>>
>> Jessica Clarke <jrtc27@...c27.com> writes:
>>
>> > On 3 Jul 2023, at 19:58, Emil Renner Berthing <emil.renner.berthing@...il.com> wrote:
>> >>
>> >> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <cuiyunhui@...edance.com> wrote:
>> >>>
>> >>> Hi drew,
>> >>>
>> >>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <ajones@...tanamicro.com> wrote:
>> >>>>
>> >>>>
>> >>>> (This is a reply to a non-existent cover letter.)
>> >>>
>> >>> This has been discussed many times with Ard, Please refer to :
>> >>> https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@bytedance.com/
>> >>
>> >> Hi Yunhui,
>> >>
>> >> From that discussion it was mentioned that that arm supports 3 methods
>> >> of booting:
>> >>  direct + devicetree
>> >>  EFI + devicetree
>> >>  EFI + ACPI
>> >> ..but not
>> >>  direct + ACPI
>> >>
>> >> To me it isn't obvious from that or this thread, and since arm seems
>> >> to be doing fine without the 4th option I'm curious why that's
>> >> necessary on riscv?
>> >
>> > If anything we should be removing option 1, because that’s not a
>> > cross-OS standard (though RISC-V’s SBI direct booting is at least not
>> > tied to the OS). Any application-class platform spec is going to
>> > mandate EFI, because, whatever your thoughts of EFI are, that is *the*
>> > standard. And if you’re willing to pick up all the complexity of ACPI,
>> > what’s a bit of EFI (especially if you only go for a minimal one a la
>> > U-Boot)?
>>
>> Well said!
>>
>> Yunhui, why not simply add a minimal UEFI stub to Coreboot (like Jess
>> points out above)?
>
> In fact, in the v1 email, Coreboot's maintainer Ron has made it clear
> that Coreboot does not support EFI, and it is necessary to transmit
> firmware information through DTS on RISC-V.

It clear that Coreboot doesn't support UEFI today. We're "arguing" that
it's less work/verification adding the neccesary minimal UEFI plumbing
for Coreboot, than jumping through hoops in the kernel to work around
it.

I'm getting some UEFI FUD vibes here. I also think that parts of UEFI is
kind of ugly, but it's, as Jess says, *the* spec and honestly, a bit
what's expected (Hi CXL).

UEFI is a specification, and implementing the minimal requirements for
UEFI is not that of a big deal. Look at Alex Graf's (et al) work on
u-boot UEFI. U-boot is small/lean/open *and* manage to support enough
UEFI for ACPI.

The whole "Oh, UEFI is so bad, bloated, and closed" hand-wavery is a bit
tiring. :-(

...these last four sections is more of a beer discussion. I'll take my
"my FW is better than yours" rants elsewhere. ;-)


Björn