SoylentNews is people
SoylentNews
UEFI Boot Support Published For RISC-V On Linux
Western Digital's Atish Patra sent out the patch series on Tuesday for adding UEFI support for the RISC-V architecture. This initial UEFI Linux bring-up is for supporting boot time services while the UEFI runtime service support is still being worked on. This RISC-V UEFI support can work in conjunction with the U-Boot bootloader and depends upon other recent Linux kernel work around RISC-V's Supervisor Binary Interface (SBI).
Building off the common (U)EFI code within the Linux kernel, the RISC-V bring-up so far is just over four hundred lines of code. Depending upon how quickly this code is reviewed, the initial UEFI RISC-V support could land for the Linux 5.7 cycle. So far this RISC-V UEFI boot support has been tested under QEMU.
Unified Extensible Firmware Interface (UEFI).
See also: Linux EFI Going Through Spring Cleaning Before RISC-V Support Lands
Related:
Western Digital to Transition Consumption of Over One Billion Cores Per Year to RISC-V
Western Digital Publishes RISC-V "SweRV" Core Design Under Apache 2.0 License
(Score: 1, Insightful) by Anonymous Coward on Friday February 28 2020, @06:29PM (1 child)
That is the sole purpose for UEFI: providing enhanced backdoor opportunities and less user control over the firmware stack for their hardware, as well as mandating (in)secure signed platform boot. Of course for now SOME hardware can disable it, but you will note almost no hardware actually supports user signed or unsigned trusted boot bringup to allow implementing the signing key in flash while bringing one's system up to trusted status with a user compiled open source or audited trusted execution environment.
RISC-V has turned from a platform claimed to liberate us all to another part of the problem. In order for us to regain control of the hardware and software ecosystem it is time hardware and software engineers who still believe get together and design a successor to the AT/ATX PC clone architecture with trusted platform security intended to protect the end user, not the governments and cabals of media and technology companies which have trojaned the security of the entire globe.
(Score: 2) by Rich on Saturday February 29 2020, @03:10PM
If WD would see gains to be made from locking users out, why would they give away the keys? Making something like BIOS/OpenFirmware/UEFI isn't black magic and rather than using FORTH oder some bytecode, they could just stick to R-V binary, after all it's what they want to push through. So they'd cook their own soup and force a standard that the container crowd needs to use. When the world has adopted it, they'd do a minor revision and announce to the world that they are now the single signing authority for R-V. Of course, in.. er... order to guarantee coherent platform management to data center users, you'd have to bundle their platform snoop... supporting blob to get signed. Or something the like.
For their NAS stuff, it has no benefits. They control the whole stack and can tivoize it (german saying:) until the doctor comes. Only effect from UEFI is longer boot times.
The only one I see benefitting is Microsoft, because they couldn't manage drivers/images for the emerging zoo of R-V hardware in-house. With UEFI they can ship a single image. So I could very well imagine that MS contracted that job with WD for, er... Azure cloud server requirements.