4 ms·

As usual, there are prophetic warnings from Linus: https://yarchive.net/comp/linux/efi.html https://yarchive.net/comp/linux/efi.html BIOS should be simple, be

As usual, there are prophetic warnings from Linus: https://yarchive.net/comp/linux/efi.html https://yarchive.net/comp/linux/efi.html BIOS should be simple, because it is buggy anyway. Handing over to a bootloader in the MBR is all that a BIOS should do. Now one is at the mercy of NVRAM, grub2 and loads of gratuitous complexity.

bzb3 6y ago
"New software will eventually contain bugs", and then bringing it up 14 years later, seems to bring nothing to the table.
- chris_wot 6y ago
  Hence the “prophetic” bit.
paol 6y ago
EFI really was a step in completely the wrong direction. Massive complexity & feature set for no good reason. Legacy BIOS had to go, it was designed at the time of 8086 and DOS and was really out of step with modern HW and OS needs. The replacement could have been even simpler though, now that OSes really want to take over everything themselves and no longer lean on the BIOS that way that DOS used to. Instead EFI created a monster and now we're stuck with it.
- vbezhenar 6y ago
  BIOS is a good idea. It should have been expanded. For example I should be able to download Nvidia driver, install it into BIOS and then talk to it via standard interface (something like Vulkan). Now every operating system can just utilize that interface and use well tested driver from manufacturer, rather than ask manufacturer to write that driver for every operating system.
  - cptroot 6y ago
    "Via Standard Interface" I don't think you can gloss over the differences between say DirectX and Metal that easily. Maybe you're arguing they should be gotten rid of, but I think that's rather pie in the sky.
  - lucian1900 6y ago
    That’s a nice idea, but the history of graphics APIs and drivers suggests otherwise. The path between the hardware and the application has only gotten shorter and more direct, not less.
  - cesarb 6y ago
    > install it into BIOS and then talk to it via standard interface Isn't that how it's worked since forever? The graphics card already comes with a driver in a flash ROM chip, the BIOS installs it during boot, and programs can talk to it through the standard INT 10h interface. AFAIK, modern graphics cards also already come with an EFI driver in the same flash ROM chip, which the BIOS installs during boot when in EFI mode, and EFI programs and operating systems can talk to it through standard EFI interfaces.
  - LargoLasskhyfv 6y ago
    You just described [1] https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware
- 6c696e7578 6y ago
  Not at all like systemd then. I had hoped by now we'd be using something that took the arguably good qualities (simple unit files) and none of the complexity (why does it implement DNS?) and we could have the better subset. It will continue to bite until enough people petition it's replacement. Don't get me wrong, some of the features are good, but the kitchen sink is not.
  - otterley 6y ago
    systemd does not implement DNS. There's a helper program that can resolve DNS queries (systemd-resolved), but it is optional. systemd is largely architected the way you'd hope it to be. systemd itself, the core program, is responsible only for maintaining the lifecycle of other programs. The other functionality is provided by satellite daemons, which you can choose to use (or not use!) at will. Now, distro maintainers may choose to use the whole kit-and-caboodle, but that is a deliberate decision on their part. It's not forced by the systemd authors, and you are free to override your distro maintainer's choice if you so desire.
    - kasabali 6y ago
      > systemd does not implement DNS. There's a helper program that can resolve DNS queries (systemd-resolved), but it is optional. So it implements DNS. ...and I must add, implements it badly [0] > Now, distro maintainers may choose to use the whole kit-and-caboodle, but that is a deliberate decision on their part. It's not forced by the systemd authors Not forced, instead they "gently push" [1] 0. https://news.ycombinator.com/item?id=8595335 https://news.ycombinator.com/item?id=8595335 1. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
- guerby 6y ago
  I hope RISC-V will get booting right. https://linuxplumbersconf.org/event/4/contributions/381/attachments/297/501/Linux_plumbers_bootflow.pdf https://linuxplumbersconf.org/event/4/contributions/381/atta... https://www.phoronix.com/scan.php?page=news_item&px=UEFI-RISC-V-Linux-Patches https://www.phoronix.com/scan.php?page=news_item&px=UEFI-RIS... Early discussions (cannot find a trace online, from my mail archives): From: ron minnich Subject: Re: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 08:46:07 -0800 At Google and other places, we've been struggling now for years with overly complex firmware that is implemented incorrectly, enabling exploits and other bad things. The list of things vendors get wrong in firmware, both enabling exploits and enabling others to enable exploits, is long and it continues to this day. There is an unbelievable amount of money out there all involving firmware exploits, very little of it involving nice people. I'm currently working on deleting all use of the x86 version of M mode, i.e. SMM. There are many proposals out there for deleting SMM from the architecture. I've also shown at a talk in 2017 how we could redirect SMM interrupts back into the kernel. We're also removing all use of callbacks into UEFI on x86. We're almost there. Which is why I'm a bit unhappy to see this (to me) cancerous growth in proposals for M- mode code. PPP in firmware? Really? multiple serial devices? really? We've been here before, in the 1970s, with something called the BIOS. If you're not familiar with it, go take a look, or you can take my word for it that these proposals implement that idea. We spent over 20 years freeing ourselves from it on x86. Why go back to a 50 year old model on a CPU designed to be in use for 50 years? My early understanding of M mode was that it was an Alpha PALCode like thing, enabling access to resources that were behind a privilege wall. I did not like it that much, but I was OK: it was very limited in function, and the kernel could replace it, or at least measure it. I also accept that every cpu vendor uses m mode like things (e.g. ARM TF) for reasonable purposes and also (let's be honest here) for dealing with chipset mistakes. But that does not mean you need to recreate BIOS. The SBI should be hard to add to, deliberately. It should be used only when there are no possible alternatives. It needs to be open source and held in common. It should be possible for a kernel to replace or at least measure it. And, further, there needs to be some work done on why you add to it, and why you don't, with bias against adding to it. This proposal works against those ideals, as it explicitly enables vendor-specific forks of the SBI. Sure, this can happen, but why make it so easy? see https://github.com/riscv/riscv-sbi-doc/pull/12 https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts. Also, I've had discussions with some security folks in our firmware community about the fact that the PMP can be used in a way that the kernel can not measure the SBI, since SBI might read-protect itself. This is a real step backwards, FYI. Not sure if it can be changed at this point. ron p.s. For interleaving debug and console output firmware, use the oldest trick in the book: ASCII is 7 bits. Since console out is 8 bits, reserve 128 values for console out, and 128 for debug stream, and if the debug stream needs 8 bit for some words, you know what to do. It's very easy and doesn't require that we add multiple UART support to SBI.
- wizzwizz4 6y ago
  XSFI, the Extremely Simple Firmware Interface (currently in its second draft) is a good solution. https://www.alm.website/misc/specs/xsfi https://www.alm.website/misc/specs/xsfi It could be implemented in UEFI, and bundled with disks as a compatibility layer, for machines that support UEFI but not XSFI.
- rhn_mk1 6y ago
  Few will remember but Intel came up with something simpler: Simple Firmware Interface. Wikipedia only mentions the mobile platform, but it was also what the card-based Xeon Phi was using (own research).
- twic 6y ago
  This is part of the mess that Oxide Computer wants to clean up, right? Are they going to use EFI at all? Anyone from Oxide around?
badrabbit 6y ago
I really do miss the simplicity of grub 0.97,keeping it as long as I can on my older boxes.
- kd913 6y ago
  Grub simple? If you want simple use systemd-boot. It's a hell of a lot leaner than grub ever was. The config is sane and doesn't require a billion additional modules to be installed. It should be the default at this point, especially after all of this fiasco.
  - badrabbit 6y ago
    Next thing I will hear "Linux simple? Systemd-kernel is a lot leaner" I think we have different definitions of lean and simple. After about a decade of Linux use I just found out Grub has modules thanks to you. You point it a disk and it installs. You edit the config file and that works. That's my experience it. I have had many debates with people who like systemd-isms , it's a fundamental difference in use case and philosophy.
    - kd913 6y ago
      Systemd-boot is not originally designed in systemd philosophy. It was originally gummiboot and got adopted into systemd project. The explicit design goal was to be a minimal alternative to grub.
trasz 6y ago
How is EFI responsible for a security bug in open source bootloader that's not even EFI-specific?
zabardasth 6y ago
It's a lot simpler on embedded devices. U-Boot for example is extremely simple and much more robust than GRUB or LILO.
CSDude 6y ago
Like the biggest attack vector was BIOS, they wanted to secure that with UEFI, it was nothing but headaches with my dual boot installs.
hnarn 6y ago
I’m not saying Linus isn’t extremely competent, much more so than I and probably anyone reading this will ever be, but in general terms I think anyone arguing against complexity in software design, while in a way “doing the Lord’s work” even in my own opinion, will never be wrong: in the cases where their prophecies never come true, the opinion will still be considered by most to be “correct in theory”, and if something does break down the line, the opinion can be referred to as prophetic. So, while I agree that we should keep things simple and modular, it’s a thankless job trying to solve issues and being forced to add complexity. Nobody defends complexity, and maybe we shouldn’t, in order to stay on our toes, but defending simplicity is also about the safest thing you can do.

bzb3 6y ago

"New software will eventually contain bugs", and then bringing it up 14 years later, seems to bring nothing to the table.

chris_wot 6y ago
Hence the “prophetic” bit.

paol 6y ago

EFI really was a step in completely the wrong direction. Massive complexity & feature set for no good reason. Legacy BIOS had to go, it was designed at the time of 8086 and DOS and was really out of step with modern HW and OS needs. The replacement could have been even simpler though, now that OSes really want to take over everything themselves and no longer lean on the BIOS that way that DOS used to. Instead EFI created a monster and now we're stuck with it.

vbezhenar 6y ago
BIOS is a good idea. It should have been expanded. For example I should be able to download Nvidia driver, install it into BIOS and then talk to it via standard interface (something like Vulkan). Now every operating system can just utilize that interface and use well tested driver from manufacturer, rather than ask manufacturer to write that driver for every operating system.
- cptroot 6y ago
  "Via Standard Interface" I don't think you can gloss over the differences between say DirectX and Metal that easily. Maybe you're arguing they should be gotten rid of, but I think that's rather pie in the sky.
- lucian1900 6y ago
  That’s a nice idea, but the history of graphics APIs and drivers suggests otherwise. The path between the hardware and the application has only gotten shorter and more direct, not less.
- cesarb 6y ago
  > install it into BIOS and then talk to it via standard interface Isn't that how it's worked since forever? The graphics card already comes with a driver in a flash ROM chip, the BIOS installs it during boot, and programs can talk to it through the standard INT 10h interface. AFAIK, modern graphics cards also already come with an EFI driver in the same flash ROM chip, which the BIOS installs during boot when in EFI mode, and EFI programs and operating systems can talk to it through standard EFI interfaces.
- LargoLasskhyfv 6y ago
  You just described [1] https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware
6c696e7578 6y ago
Not at all like systemd then. I had hoped by now we'd be using something that took the arguably good qualities (simple unit files) and none of the complexity (why does it implement DNS?) and we could have the better subset. It will continue to bite until enough people petition it's replacement. Don't get me wrong, some of the features are good, but the kitchen sink is not.
- otterley 6y ago
  systemd does not implement DNS. There's a helper program that can resolve DNS queries (systemd-resolved), but it is optional. systemd is largely architected the way you'd hope it to be. systemd itself, the core program, is responsible only for maintaining the lifecycle of other programs. The other functionality is provided by satellite daemons, which you can choose to use (or not use!) at will. Now, distro maintainers may choose to use the whole kit-and-caboodle, but that is a deliberate decision on their part. It's not forced by the systemd authors, and you are free to override your distro maintainer's choice if you so desire.
  - kasabali 6y ago
    > systemd does not implement DNS. There's a helper program that can resolve DNS queries (systemd-resolved), but it is optional. So it implements DNS. ...and I must add, implements it badly [0] > Now, distro maintainers may choose to use the whole kit-and-caboodle, but that is a deliberate decision on their part. It's not forced by the systemd authors Not forced, instead they "gently push" [1] 0. https://news.ycombinator.com/item?id=8595335 https://news.ycombinator.com/item?id=8595335 1. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
guerby 6y ago
I hope RISC-V will get booting right. https://linuxplumbersconf.org/event/4/contributions/381/attachments/297/501/Linux_plumbers_bootflow.pdf https://linuxplumbersconf.org/event/4/contributions/381/atta... https://www.phoronix.com/scan.php?page=news_item&px=UEFI-RISC-V-Linux-Patches https://www.phoronix.com/scan.php?page=news_item&px=UEFI-RIS... Early discussions (cannot find a trace online, from my mail archives): From: ron minnich Subject: Re: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 08:46:07 -0800 At Google and other places, we've been struggling now for years with overly complex firmware that is implemented incorrectly, enabling exploits and other bad things. The list of things vendors get wrong in firmware, both enabling exploits and enabling others to enable exploits, is long and it continues to this day. There is an unbelievable amount of money out there all involving firmware exploits, very little of it involving nice people. I'm currently working on deleting all use of the x86 version of M mode, i.e. SMM. There are many proposals out there for deleting SMM from the architecture. I've also shown at a talk in 2017 how we could redirect SMM interrupts back into the kernel. We're also removing all use of callbacks into UEFI on x86. We're almost there. Which is why I'm a bit unhappy to see this (to me) cancerous growth in proposals for M- mode code. PPP in firmware? Really? multiple serial devices? really? We've been here before, in the 1970s, with something called the BIOS. If you're not familiar with it, go take a look, or you can take my word for it that these proposals implement that idea. We spent over 20 years freeing ourselves from it on x86. Why go back to a 50 year old model on a CPU designed to be in use for 50 years? My early understanding of M mode was that it was an Alpha PALCode like thing, enabling access to resources that were behind a privilege wall. I did not like it that much, but I was OK: it was very limited in function, and the kernel could replace it, or at least measure it. I also accept that every cpu vendor uses m mode like things (e.g. ARM TF) for reasonable purposes and also (let's be honest here) for dealing with chipset mistakes. But that does not mean you need to recreate BIOS. The SBI should be hard to add to, deliberately. It should be used only when there are no possible alternatives. It needs to be open source and held in common. It should be possible for a kernel to replace or at least measure it. And, further, there needs to be some work done on why you add to it, and why you don't, with bias against adding to it. This proposal works against those ideals, as it explicitly enables vendor-specific forks of the SBI. Sure, this can happen, but why make it so easy? see https://github.com/riscv/riscv-sbi-doc/pull/12 https://github.com/riscv/riscv-sbi-doc/pull/12 for other thoughts. Also, I've had discussions with some security folks in our firmware community about the fact that the PMP can be used in a way that the kernel can not measure the SBI, since SBI might read-protect itself. This is a real step backwards, FYI. Not sure if it can be changed at this point. ron p.s. For interleaving debug and console output firmware, use the oldest trick in the book: ASCII is 7 bits. Since console out is 8 bits, reserve 128 values for console out, and 128 for debug stream, and if the debug stream needs 8 bit for some words, you know what to do. It's very easy and doesn't require that we add multiple UART support to SBI.
wizzwizz4 6y ago
XSFI, the Extremely Simple Firmware Interface (currently in its second draft) is a good solution. https://www.alm.website/misc/specs/xsfi https://www.alm.website/misc/specs/xsfi It could be implemented in UEFI, and bundled with disks as a compatibility layer, for machines that support UEFI but not XSFI.
rhn_mk1 6y ago
Few will remember but Intel came up with something simpler: Simple Firmware Interface. Wikipedia only mentions the mobile platform, but it was also what the card-based Xeon Phi was using (own research).
twic 6y ago
This is part of the mess that Oxide Computer wants to clean up, right? Are they going to use EFI at all? Anyone from Oxide around?

badrabbit 6y ago

I really do miss the simplicity of grub 0.97,keeping it as long as I can on my older boxes.

kd913 6y ago
Grub simple? If you want simple use systemd-boot. It's a hell of a lot leaner than grub ever was. The config is sane and doesn't require a billion additional modules to be installed. It should be the default at this point, especially after all of this fiasco.
- badrabbit 6y ago
  Next thing I will hear "Linux simple? Systemd-kernel is a lot leaner" I think we have different definitions of lean and simple. After about a decade of Linux use I just found out Grub has modules thanks to you. You point it a disk and it installs. You edit the config file and that works. That's my experience it. I have had many debates with people who like systemd-isms , it's a fundamental difference in use case and philosophy.
  - kd913 6y ago
    Systemd-boot is not originally designed in systemd philosophy. It was originally gummiboot and got adopted into systemd project. The explicit design goal was to be a minimal alternative to grub.

trasz 6y ago

How is EFI responsible for a security bug in open source bootloader that's not even EFI-specific?

zabardasth 6y ago

It's a lot simpler on embedded devices. U-Boot for example is extremely simple and much more robust than GRUB or LILO.

CSDude 6y ago

Like the biggest attack vector was BIOS, they wanted to secure that with UEFI, it was nothing but headaches with my dual boot installs.

hnarn 6y ago

I’m not saying Linus isn’t extremely competent, much more so than I and probably anyone reading this will ever be, but in general terms I think anyone arguing against complexity in software design, while in a way “doing the Lord’s work” even in my own opinion, will never be wrong: in the cases where their prophecies never come true, the opinion will still be considered by most to be “correct in theory”, and if something does break down the line, the opinion can be referred to as prophetic. So, while I agree that we should keep things simple and modular, it’s a thankless job trying to solve issues and being forced to add complexity. Nobody defends complexity, and maybe we shouldn’t, in order to stay on our toes, but defending simplicity is also about the safest thing you can do.