11 ms·

It is so disappointing that ARM and RISC-V is adopting UEFI, we had a chance of a clean break, but noo, let's make persistent firmware level root kits easy and

It is so disappointing that ARM and RISC-V is adopting UEFI, we had a chance of a clean break, but noo, let's make persistent firmware level root kits easy and cross platform with EFI bytecode. Yep, network stack with hard coded web addresses in your firmware, brilliant idea. /rant

ahoka 3y ago
These are all solving use cases. What do you suggest hardware vendors should do?
- rwaksmunski 3y ago
  Apple created a minimal bootloader for their Apple Silicon machines, seems to be working great.
  - Novosell 3y ago
    Apple also controlls their entire software and hardware stack, a bit different
    - surajrmal 3y ago
      Oxide managed to do something similar as well: https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl
      - yencabulator 3y ago
        Oxide also controls their entire software and hardware stack (theirs is open source, at least)... Neither vendor has to worry about modularity or weird configurations.
- tremon 3y ago
  Open their software drivers and publish accurate specifications.
  - yjftsjthsd-h 3y ago
    And then what? We implement a dozen different incompatible bootloaders for it? The value in UEFI is that it lets us use a common interface for booting, regardless of how it's implemented. (To be clear, I overwhelmingly prefer FOSS and open specs, but we need to be clear about what things solve what problems)
Avamander 3y ago
UEFI is a necessary evil, we just have to get better, open-source implementations. Device Trees and alternatives are absolutely horrid especially in comparison.
- oynqr 3y ago
  Device trees aren't an alternative to UEFI, but to ACPI.
  - Avamander 3y ago
    True, I skipped a step in my comment. My assumption is that ACPI and UEFI/BIOS usually exist together. Without UEFI you have to find an alternative to both, and neither DTs and the (bootloader) alternatives are pleasant.
    - mschuster91 3y ago
      What's so wrong with u-boot? Most of the trouble people have with it is "thanks" to chipset vendors who forked their version somewhere 10-ish years ago and completely mutilated it instead of putting in the effort to get their stuff upstreamed. The only major thing it can't boot to my knowledge is Windows, but it might be doable if you chain-load Grub.
      - surajrmal 3y ago
        uboot needs to be modified to run a given operating system if it wasn't already supported (or a shim pretending to be one of the supported operating systems needs to be used). UEFI provides a way to support all operating systems through a standardized interface. uboot implementing UEFI interface provides the best of both worlds.
        stragies 3y ago
        "implement just enough UEFI to boot stuff, not the whole kitchen sink" I believe is the target of the uboot project
snvzz 3y ago
On RISC-V, UEFI (typically edk2) is a payload for SBI (typically opensbi). If you hate edk2, you can run something else e.g. u-boot, the linux kernel or your own code. If you hate opensbi, look at oreboot, which implements something equivalent to u-boot SPL + opensbi in rust.
solarkraft 3y ago
I'm personally (uneducatedly) mostly for it because I like the way things "just work" on PCs. No matter what components you put on, the thing will boot. A sibling mentions that this is due to ACPI - I guess then I want that too. Needing a separate build for nearly every different SBC sucks and I'm happy about anything that will broaden compatibility here.
- rcxdude 3y ago
  It's entirely because it's expected in PCs and not expected on SBCs. Devicetree exists and can solve this problem, but it means the SBC and ARM SoC vendors would need to upstream their drivers like x86 vendors do. Until you have that ACPI vs devicetree is irrelevant for the purposes of improving this situation.
  - surajrmal 3y ago
    This is a narrow view. There are more operating systems out there than just Linux. Standardizing peripherals the ways PCs have done would have many benefits. Device tree basically forces operating systems to need per board images instead of a generic image that works on most boards. This doesn't scale well, especially on operating systems without a stable driver abi.
    - rcxdude 3y ago
      There's nothing about device tree which forces this. It's just how it's normally used because of said constraints. The ideal device tree situation would be it is provided by the SBC vendor and then passed into the generic image, just like ACPI. The reason this isn't done is this generic image doesn't exist at the moment. Switching to ACPI still means this generic image doesn't exist.
    - megous 3y ago
      It's the reverse. DTs allow having a common image, where just the DT differs (and can be selected on boot, or passed from FW if it's not part of the OS image).
    - 3y ago
hsbauauvhabzb 3y ago
Hardware root kits make me lose sleep at night - has there been evidence outside of academia that they’re used?
- shzhdbi09gv8ioi 3y ago
  Yes, for a long time. Criminals have used hardware rootkits since at least 2008, but the most famous one is Intel Active Management Technology. Wikipedia explains: > Intel Active Management Technology, part of Intel vPro, implements out-of-band management, giving administrators remote administration, remote management, and remote control of PCs with no involvement of the host processor or BIOS, even when the system is powered off. Remote administration includes remote power-up and power-down, remote reset, redirected boot, console redirection, pre-boot access to BIOS settings, programmable filtering for inbound and outbound network traffic, agent presence checking, out-of-band policy-based alerting, access to system information, such as hardware asset information, persistent event logs, and other information that is stored in dedicated memory (not on the hard drive) where it is accessible even if the OS is down or the PC is powered off. Some of these functions require the deepest level of rootkit, a second non-removable spy computer built around the main computer. Sandy Bridge and future chipsets have "the ability to remotely kill and restore a lost or stolen PC via 3G". Hardware rootkits built into the chipset can help recover stolen computers, remove data, or render them useless, but they also present privacy and security concerns of undetectable spying and redirection by management or hackers who might gain control. https://en.wikipedia.org/wiki/Rootkit#Firmware_and_hardware https://en.wikipedia.org/wiki/Rootkit#Firmware_and_hardware
  - mavhc 3y ago
    Not sure that if you pay extra for vPro on your computer and it comes with a vPro sticker on the front, that counts as a rootkit. Well, except for the 100s of bugs in vPro that cause it to completely insecure...
surajrmal 3y ago
UEFI does not mean you need a network stack. Your dislike is of a particular implementation of the UEFI specification. The part of the spec that is being used is the contract between the bootloader and operating system which gets loaded. There are a large number of benefits that come from standardizing this interface, and most of the drawbacks you perceive can be avoided depending on how vendors go about the implementation.

ahoka 3y ago

These are all solving use cases. What do you suggest hardware vendors should do?

rwaksmunski 3y ago
Apple created a minimal bootloader for their Apple Silicon machines, seems to be working great.
- Novosell 3y ago
  Apple also controlls their entire software and hardware stack, a bit different
  - surajrmal 3y ago
    Oxide managed to do something similar as well: https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl
    - yencabulator 3y ago
      Oxide also controls their entire software and hardware stack (theirs is open source, at least)... Neither vendor has to worry about modularity or weird configurations.
tremon 3y ago
Open their software drivers and publish accurate specifications.
- yjftsjthsd-h 3y ago
  And then what? We implement a dozen different incompatible bootloaders for it? The value in UEFI is that it lets us use a common interface for booting, regardless of how it's implemented. (To be clear, I overwhelmingly prefer FOSS and open specs, but we need to be clear about what things solve what problems)

Avamander 3y ago

UEFI is a necessary evil, we just have to get better, open-source implementations. Device Trees and alternatives are absolutely horrid especially in comparison.

oynqr 3y ago
Device trees aren't an alternative to UEFI, but to ACPI.
- Avamander 3y ago
  True, I skipped a step in my comment. My assumption is that ACPI and UEFI/BIOS usually exist together. Without UEFI you have to find an alternative to both, and neither DTs and the (bootloader) alternatives are pleasant.
  - mschuster91 3y ago
    What's so wrong with u-boot? Most of the trouble people have with it is "thanks" to chipset vendors who forked their version somewhere 10-ish years ago and completely mutilated it instead of putting in the effort to get their stuff upstreamed. The only major thing it can't boot to my knowledge is Windows, but it might be doable if you chain-load Grub.
    - surajrmal 3y ago
      uboot needs to be modified to run a given operating system if it wasn't already supported (or a shim pretending to be one of the supported operating systems needs to be used). UEFI provides a way to support all operating systems through a standardized interface. uboot implementing UEFI interface provides the best of both worlds.
      - stragies 3y ago
        "implement just enough UEFI to boot stuff, not the whole kitchen sink" I believe is the target of the uboot project

snvzz 3y ago

On RISC-V, UEFI (typically edk2) is a payload for SBI (typically opensbi). If you hate edk2, you can run something else e.g. u-boot, the linux kernel or your own code. If you hate opensbi, look at oreboot, which implements something equivalent to u-boot SPL + opensbi in rust.

solarkraft 3y ago

I'm personally (uneducatedly) mostly for it because I like the way things "just work" on PCs. No matter what components you put on, the thing will boot. A sibling mentions that this is due to ACPI - I guess then I want that too. Needing a separate build for nearly every different SBC sucks and I'm happy about anything that will broaden compatibility here.

rcxdude 3y ago
It's entirely because it's expected in PCs and not expected on SBCs. Devicetree exists and can solve this problem, but it means the SBC and ARM SoC vendors would need to upstream their drivers like x86 vendors do. Until you have that ACPI vs devicetree is irrelevant for the purposes of improving this situation.
- surajrmal 3y ago
  This is a narrow view. There are more operating systems out there than just Linux. Standardizing peripherals the ways PCs have done would have many benefits. Device tree basically forces operating systems to need per board images instead of a generic image that works on most boards. This doesn't scale well, especially on operating systems without a stable driver abi.
  - rcxdude 3y ago
    There's nothing about device tree which forces this. It's just how it's normally used because of said constraints. The ideal device tree situation would be it is provided by the SBC vendor and then passed into the generic image, just like ACPI. The reason this isn't done is this generic image doesn't exist at the moment. Switching to ACPI still means this generic image doesn't exist.
  - megous 3y ago
    It's the reverse. DTs allow having a common image, where just the DT differs (and can be selected on boot, or passed from FW if it's not part of the OS image).
  - 3y ago

hsbauauvhabzb 3y ago

Hardware root kits make me lose sleep at night - has there been evidence outside of academia that they’re used?

shzhdbi09gv8ioi 3y ago
Yes, for a long time. Criminals have used hardware rootkits since at least 2008, but the most famous one is Intel Active Management Technology. Wikipedia explains: > Intel Active Management Technology, part of Intel vPro, implements out-of-band management, giving administrators remote administration, remote management, and remote control of PCs with no involvement of the host processor or BIOS, even when the system is powered off. Remote administration includes remote power-up and power-down, remote reset, redirected boot, console redirection, pre-boot access to BIOS settings, programmable filtering for inbound and outbound network traffic, agent presence checking, out-of-band policy-based alerting, access to system information, such as hardware asset information, persistent event logs, and other information that is stored in dedicated memory (not on the hard drive) where it is accessible even if the OS is down or the PC is powered off. Some of these functions require the deepest level of rootkit, a second non-removable spy computer built around the main computer. Sandy Bridge and future chipsets have "the ability to remotely kill and restore a lost or stolen PC via 3G". Hardware rootkits built into the chipset can help recover stolen computers, remove data, or render them useless, but they also present privacy and security concerns of undetectable spying and redirection by management or hackers who might gain control. https://en.wikipedia.org/wiki/Rootkit#Firmware_and_hardware https://en.wikipedia.org/wiki/Rootkit#Firmware_and_hardware
- mavhc 3y ago
  Not sure that if you pay extra for vPro on your computer and it comes with a vPro sticker on the front, that counts as a rootkit. Well, except for the 100s of bugs in vPro that cause it to completely insecure...

surajrmal 3y ago

UEFI does not mean you need a network stack. Your dislike is of a particular implementation of the UEFI specification. The part of the spec that is being used is the contract between the bootloader and operating system which gets loaded. There are a large number of benefits that come from standardizing this interface, and most of the drawbacks you perceive can be avoided depending on how vendors go about the implementation.