linux-kernel - Re: [PATCH V15 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, 3 Jun 2022 13:48:45 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     WANG Xuerui <kernel@...0n.name>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        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>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kernel Mailing List <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 <linux-efi@...r.kernel.org>,
        WANG Xuerui <git@...0n.name>, Yun Liu <liuyun@...ngson.cn>
Subject: Re: [PATCH V15 11/24] LoongArch: Add boot and setup routines

On Fri, 3 Jun 2022 at 12:37, WANG Xuerui <kernel@...0n.name> wrote:
>
> On 6/3/22 18:02, Arnd Bergmann wrote:
> > On Fri, Jun 3, 2022 at 11:27 AM WANG Xuerui <kernel@...0n.name> wrote:
> >> On 6/3/22 15:20, Huacai Chen wrote:
> >>> Add basic boot, setup and reset routines for LoongArch. Now, LoongArch
> >>> machines use UEFI-based firmware. The firmware passes configuration
> >>> information to the kernel via ACPI and DMI/SMBIOS.
> >>>
> >>> Currently an existing interface between the kernel and the bootloader
> >>> is implemented. Kernel gets 2 values from the bootloader, passed in
> >>> registers a0 and a1; a0 is an "EFI boot flag" distinguishing UEFI and
> >>> non-UEFI firmware, while a1 is a pointer to an FDT with systable,
> >>> memmap, cmdline and initrd information.
> >>>
> >>> The standard UEFI boot protocol (EFISTUB) will be added later.
> >>>
> >>> Cc: linux-efi@...r.kernel.org
> >>> Cc: Ard Biesheuvel <ardb@...nel.org>
> >>> Reviewed-by: WANG Xuerui <git@...0n.name>
> >>> Reviewed-by: Jiaxun Yang <jiaxun.yang@...goat.com>
> >>> Co-developed-by: Yun Liu <liuyun@...ngson.cn>
> >>> Signed-off-by: Yun Liu <liuyun@...ngson.cn>
> >>> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> >> Would you please look at this patch, which has all the arch-independent
> >> changes backed out, and Ack if it is fit for mainlining?
> >>
> >> I communicated a little with Huacai about the approach for supporting
> >> alternative boot protocols down the road, and we agreed to carry the
> >> respective changes downstream. And if needs truly arise for modifying
> >> common EFI logic, we can do so in a non-rushed manner later.
> >>
> >> For the current status of the code, apparently it just accepts the
> >> standard efistub-shape FDT pointer from (whatever booting the image),
> >> and everything onwards are fully using the common code without
> >> modification as you can see from the diffstat. I rebased my BPI support
> >> patch on top of this (basically translating Loongson BPI data structures
> >> into the expected FDT form), and can confirm the boot can progress to
> >> the same point as before -- indeed the SVAM changes etc. are not
> >> necessary for a working system, and the code remains working.
> > I'm a bit lost here: Does this mean the v15 version is back to the old
> > pre-efistub interface and allows booting with existing firmware, or
> > is it now left out completely? I still see a kernel_entry() function
> > in head.S, and I see references to loongson_sysconf, but I don't
> > see if that is what gets passed in from the bootloader.
> It's not the same interface as in some of the very early revisions; the
> earlier versions relied on "struct bootparamsinterface" or BPI, while
> it's the same FDT-based interface to initialize EFI from, as in
> arch/arm64 and arch/riscv I believe. No Loongson-specific things remain now.

OK, excellent.

> >
> > I really want to make sure that without the EFI stub, there is no
> > other way to boot the kernel that would have to get maintained
> > in the long run.
> Yeah this is the case right now. No LoongArch bootloader that I know of
> can prepare the EFI stub-shaped FDT that the current code expects, and I
> don't know of any future Loongson plan to do that either (Loongson's
> previous in-house efforts all looked something different). So it's
> pretty safe to say the current code wouldn't get frozen once mainlined.

The use of DT is part of the internal stub <-> kernel ABI, and if
LoongArch does not make use of DT otherwise, I could well imagine
changing this down the road.

I'll send out some RFC patches for review after the merge window closes.