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 12:02:00 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     WANG Xuerui <kernel@...0n.name>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        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>,
        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, 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.

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.

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ