linux-kernel - Re: [PATCH V6 09/22] 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]

Message-ID: <CAMj1kXFgCu659zGuZPpRLYPzFemtBv0jsOt1Yz0U0-R4DucqTw@mail.gmail.com>
Date:   Wed, 2 Mar 2022 09:58:07 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Huacai Chen <chenhuacai@...il.com>
Cc:     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 Wed, 2 Mar 2022 at 09:56, Huacai Chen <chenhuacai@...il.com> wrote:
>
> Hi, Arnd & Ard,
>
> On Tue, Mar 1, 2022 at 6:19 PM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > 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.
> Hmm, I thought that new UEFI SPEC is a requirement of efistub, maybe I'm wrong?
>
> >
> > > 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?
> Things become simple if we only consider efistub rather than raw elf.
> But there are still some problems:
> 1, We want the first patch series as minimal as possible, efistub
> support will add a lot of code.
> 2, EFISTUB hides the interface between bootloader and raw kernel, but
> the interface does actually exist (efistub itself is also a
> bootloader, though it binds with the raw kernel). In the current
> implementation (a0=argc a1=argv a2=bootparaminterface), we should
> select EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER which is marked as
> deprecated. Is this acceptable? If not, we still need to change the
> bootloader-kernel interface, maybe use the method in my previous
> email?

Why do you need this?

> 3, I know things without upstream means "nothing" for the community,
> but if we can provide raw elf kernel support to be compatible with
> existing products (not just a working draft, they are widely used
> now), it also seems reasonable.
>
> Huacai
>
> >
> >         Arnd