4 ms·
> There's already some starting work on UEFI for RISC-V That makes me deeply sad.
by Zaak 9y ago
> There's already some starting work on UEFI for RISC-V
That makes me deeply sad.
- rwmj 9y agoWhy? UEFI is open source. It's standardized, and provides standard interfaces to boot-time device drivers and to operating systems above. It provides a reasonable command line (TBH much preferable to u-boot). It works well with Linux and Windows. It's complicated, but it's solving a complicated problem.
- jabl 9y agoParts of this presentation has some explanation: https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit... (obviously you can ignore Intel x86 specific stuff like the ME). OpenPOWER apparently does something similar, i.e. a minimal firmware that loads a Linux kernel + simple userspace from flash.
- rwmj 9y agoOn RISC-V the machine layer (like ME) will be completely open source, and so will UEFI. You're inventing a problem that doesn't exist.
- jabl 9y agoOpen source is a necessary but not sufficient criterion. Leaving aside the issue of user-replacable signing keys if some kind of measured boot system is in use, and availability of documentation so you can replace the firmware if you want, which isn't really UEFI's fault, there's other issues with UEFI as well. Such as: - Why does it take 8 minutes to boot a UEFI server vs. 17 seconds with NERF? Minnich's opinion is that it's the braindead way UEFI initializes stuff. E.g. if thingy A needs thingy B, it will initialize thingy B regardless of whether it has already been initialized, etc.. Leading to a combinatorial explosion. Whereas Linux builds a dependency tree and initializes each thing only once, in the correct order. - UEFI option ROM's apparently mostly contain x86-64 code and not UEFI byte code. Some clever guys at SUSE had managed to work around that on aarch64 by using qemu to run the option ROM's, and since the x86-64 and aarch64 data structure layouts are more or less the same (endianness, alignment etc.) they could share the memory space. I mean, it's an awesomely clever hack, but do we really want a Frankenstein thing like this be the bright future we're striving for? - UEFI is amazingly complicated. Say if you want to load the kernel over HTTPS, you need a TCP stack, HTTP, TLS etc. Sure, Linux is also complicated, but I'm sure Linux is 1000x more battle tested than the UEFI stack. And, if you're going to run Linux anyway, you're not increasing the attack surface by running Linux as your firmware & boot loader. And, if you're using booting Linux from the rom flash, you can use Linux native drivers to access the NIC, storage, USB, whatever and don't need the kind of hacks mentioned above on non-x86. Sure, using Linux as firmware & boot loader might be politically untenable to some proprietary OS vendors. But so what? Let them solve their own problems!
- daurnimator 9y agoSee http://www.youtube.com/watch?v=V2aq5M3Q76U http://www.youtube.com/watch?v=V2aq5M3Q76U
- Zaak 9y agoExactly. UEFI is a bad idea implemented badly.
- deleted 9y ago[deleted]