linux-kernel - Re: Steps forward for the LoongArch UEFI bringup patch? (was: Re: [PATCH V14 11/24] LoongArch: Add boot and setup routines)

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:   Fri, 03 Jun 2022 17:32:07 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     WANG Xuerui <kernel@...0n.name>, Ard Biesheuvel <ardb@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>
Cc:     linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Huacai Chen <chenhuacai@...il.com>,
        Guo Ren <guoren@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-efi@...r.kernel.org, WANG Xuerui <git@...0n.name>,
        Yun Liu <liuyun@...ngson.cn>, Jonathan Corbet <corbet@....net>,
        Arnd Bergmann <arnd@...db.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Airlie <airlied@...ux.ie>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Steps forward for the LoongArch UEFI bringup patch? (was: Re:
 [PATCH V14 11/24] LoongArch: Add boot and setup routines)

On Thu, 2022-06-02 at 22:09 +0800, WANG Xuerui wrote:

> For this, I don't know if Huacai should really just leave those 
> modification in the downstream fork to keep the upstream Linux clean of 
> such hacks, because to some degree dealing with such notoriety is life, 
> it seems to me. I think at this point Huacai would cooperate and tweak
> the patch to get rid of the SVAM and other nonstandard bits as much as
> possible, and I'll help him where necessary too.

To me any new firmware for PC-like platforms should implement UEFI.  For
embedded platforms device tree support will be added later.

For those guys impossible or unwilling to upgrade the firmware, it may
be possible to implement a compatibility layer and the booting procedure
will be like:

old firmware -> bootloongarch.efi -> customized u-boot -> bootloongarch64.efi (grub) -> efi stub (kernel)
                --------- compatibility layer --------    ^^^^^^^^ normal UEFI compatible stuff ^^^^^^^^^

new firmware -> bootloongarch64.efi (grub) -> efi stub (kernel)

The old firmware route would be similar to the booting procedure of
Asahi Linux.  I think this can be implemented because it's already
implemented on M1 even while Apple is almost completely uncooperative.

Just my 2 cents. I know almost nothing about booting.
-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University