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:   Tue, 1 Mar 2022 11:18:56 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Huacai Chen <chenhuacai@...il.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, 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>,
        Jonathan Corbet <corbet@....net>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Yanteng Si <siyanteng@...ngson.cn>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH V6 09/22] LoongArch: Add boot and setup routines

On Tue, Mar 1, 2022 at 5:17 AM Huacai Chen <chenhuacai@...il.com> wrote:
> On Mon, Feb 28, 2022 at 7:35 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> > On Mon, 28 Feb 2022 at 12:24, Arnd Bergmann <arnd@...db.de> wrote:
> > > On Mon, Feb 28, 2022 at 11:42 AM Huacai Chen <chenhuacai@...il.com> wrote:
> > > Can't you just use the UEFI protocol for kernel entry regardless
> > > of the bootloader? It seems odd to use a different protocol for loading
> > > grub and the kernel, especially if that means you end up having to
> > > support both protocols inside of u-boot and grub, in order to chain-load
> > > a uefi application like grub.
> > >
> >
> > I think this would make sense. Now that the EFI stub has generic
> > support for loading the initrd via a UEFI specific protocol (of which
> > u-boot already carries an implementation), booting via UEFI only would
> > mean that no Linux boot protocol would need to be defined outside of
> > the kernel at all (i.e., where to load the kernel, where to put the
> > command line, where to put the initrd, other arch specific rules etc
> > etc) UEFI already supports both ACPI and DT boot
>
> After one night thinking, I agree with Ard that we can use RISCV-style
> fdt to support the raw elf kernel at present, and add efistub support
> after new UEFI SPEC released.

I think that is the opposite of what Ard and I discussed above.

> If I'm right, it seems that RISC-V passes a0 (hartid) and a1 (fdt
> pointer, which contains cmdline, initrd, etc.) to the raw elf kernel.
> And in my opinion, the main drawback of current LoongArch method
> (a0=argc a1=argv a2=bootparamsinterface pointer) is it uses a
> non-standard method to pass kernel args and initrd. So, can the below
> new solution be acceptable?
>
> a0=bootparamsinterface pointer (the same as a2 in current method)
> a1=fdt pointer (contains cmdline, initrd, etc., like RISC-V, I think
> this is the standard method)

It would seem more logical to me to keep those details as part of the
interface between the EFI stub and the kernel, rather than the
documented boot interface.

You said that there is already grub support using the UEFI
loader, so I assume you have a working draft of the boot
protocol. Are there still open questions about the interface
definition for that preventing you from using it as the only
way to enter the kernel from a bootloader?

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ