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: <dab96b787bef91240c719ea1a100396350135f99.camel@xry111.site>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ