| 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
| ||
|
Message-ID: <7659f4c0970fac6113c290b0f3a4889bf6504cfd.camel@wdc.com>
Date: Thu, 27 Feb 2020 02:09:09 +0000
From: Atish Patra <Atish.Patra@....com>
To: "palmer@...belt.com" <palmer@...belt.com>
CC: "alexios.zavras@...el.com" <alexios.zavras@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"michal.simek@...inx.com" <michal.simek@...inx.com>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"abner.chang@....com" <abner.chang@....com>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel.schaefer@....com" <daniel.schaefer@....com>,
Anup Patel <Anup.Patel@....com>,
"kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"arnd@...db.de" <arnd@...db.de>,
"rppt@...ux.ibm.com" <rppt@...ux.ibm.com>,
"bp@...e.de" <bp@...e.de>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"greentime.hu@...ive.com" <greentime.hu@...ive.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"agraf@...raf.de" <agraf@...raf.de>,
"will@...nel.org" <will@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"mingo@...nel.org" <mingo@...nel.org>,
"allison@...utok.net" <allison@...utok.net>,
"han_mao@...ky.com" <han_mao@...ky.com>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
"ardb@...nel.org" <ardb@...nel.org>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"leif@...iainc.com" <leif@...iainc.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/5] Add UEFI support for RISC-V
On Wed, 2020-02-26 at 15:46 -0800, Palmer Dabbelt wrote:
> On Tue, 25 Feb 2020 17:10:32 PST (-0800), Atish Patra wrote:
> > This series adds UEFI support for RISC-V. Currently, only boot time
> > services have been added. Runtime services will be added in a
> > separate
> > series. This series depends on some core EFI patches
> > present in current in efi-next and following other patches.
> >
> > U-Boot: Adds the boot hartid under chosen node.
> > https://lists.denx.de/pipermail/u-boot/2020-February/401227.html
> >
> > Linux kernel: SBI v0.2 and HSM extension support. This series is a
> > mandatory
> > pre-requisite for UEFI support as only single core can boot EFI
> > stub and
> > Linux via UEFI. All other cores are brought up using SBI HSM
> > extension.
> > http://lists.infradead.org/pipermail/linux-riscv/2020-February/008513.html
> >
> > OpenSBI: master (commit: ge3f69fc1e934)
> >
> > Patch 1 just moves arm-stub code to a generic code so that it can
> > be used
> > across different architecture.
> >
> > Patch 3 adds fixmap bindings so that CONFIG_EFI can be compiled and
> > we do not
> > have create separate config to enable boot time services.
> > As runtime services are not enabled at this time, full generic
> > early ioremap
> > support is also not added in this series.
> >
> > Patch 4 and 5 adds the PE/COFF header and EFI stub code support for
> > RISC-V
> > respectively.
> >
> > The patches can also be found in following git repo.
> >
> > https://github.com/atishp04/linux/tree/wip_uefi_riscv
> >
> > The patches have been verified on Qemu using bootefi command in U-
> > Boot.
> > Here is a boot log.
> >
> > Atish Patra (5):
> > efi: Move arm-stub to a common file
> > include: pe.h: Add RISC-V related PE definition
> > RISC-V: Define fixmap bindings for generic early ioremap support
> > RISC-V: Add PE/COFF header for EFI stub
> > RISC-V: Add EFI stub support.
> >
> > arch/arm/Kconfig | 2 +-
> > arch/arm64/Kconfig | 2 +-
> > arch/riscv/Kconfig | 21 +++
> > arch/riscv/Makefile | 1 +
> > arch/riscv/configs/defconfig | 1 +
> > arch/riscv/include/asm/Kbuild | 2 +-
> > arch/riscv/include/asm/fixmap.h | 21 ++-
> > arch/riscv/include/asm/io.h | 1 +
> > arch/riscv/include/asm/sections.h | 13 ++
> > arch/riscv/kernel/Makefile | 4 +
> > arch/riscv/kernel/efi-header.S | 107 ++++++++++++++
> > arch/riscv/kernel/head.S | 15 ++
> > arch/riscv/kernel/image-vars.h | 52 +++++++
> > arch/riscv/kernel/vmlinux.lds.S | 27 +++-
> > drivers/firmware/efi/Kconfig | 6 +-
> > drivers/firmware/efi/libstub/Makefile | 20 ++-
> > .../efi/libstub/{arm-stub.c => efi-stub.c} | 7 +-
> > drivers/firmware/efi/libstub/riscv-stub.c | 135
> > ++++++++++++++++++
> > include/linux/pe.h | 3 +
> > 19 files changed, 420 insertions(+), 20 deletions(-)
> > create mode 100644 arch/riscv/include/asm/sections.h
> > create mode 100644 arch/riscv/kernel/efi-header.S
> > create mode 100644 arch/riscv/kernel/image-vars.h
> > rename drivers/firmware/efi/libstub/{arm-stub.c => efi-stub.c}
> > (98%)
> > create mode 100644 drivers/firmware/efi/libstub/riscv-stub.c
>
> I'm in favor of adding EFI support, and I'd rather have it sooner
> than later so
> we don't paint ourselves into a corner. I'm not sure what happened
> to the
> RISC-V EFI spec process, though, which would be my only worry here
> (also I
> haven't looked at the code :)). Do we have enough of a spec through
> the EFI
> process that this is all kosher on their end?
>
The RISC-V platform is already merged in UEFI spec. The latest UEFI
spec can be found here.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf
Section 2.3.7: RISC-V Platforms
There are some modification required in the current spec. For example:
The current spec assumes that UEFI will execute in M mode only and
should perform handoff control to OS in M-mode as well. This is not
entirely correct as we can do this in S-mode as well.
We are in the process of creating an ECR so that next release will have
the correct information.
> Given that this definately isn't for these RCs, I'm going to leave it
> in my
> review queue. It might be best to get the "move stuff to generic"
> work merged
> on its own, as then we can carry less diff around.
>
>
Yup. It's definitely not rc material. Given that RISC-V specific
section is already merged in UEFI spec, can we aim for 5.7 merge window?
> Thanks!
--
Regards,
Atish
Powered by blists - more mailing lists