3 ms·

An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor

by snvzz 3y ago

An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader. We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u-boot spl to opensbi to u-boot flow, with UEFI on the works on the latter chip.

chriscappuccio 3y ago
RISC V will end at the same fate when implemented by the same vendors
asveikau 3y ago
If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
- snvzz 3y ago
  >If boot firmware implemented it, I wouldn't count on it being updated very often. That's precisely the problem when it's not possible to upgrade that boot firmware without the vendor's help. Or why x86 firmware contains microcode, yet we still have to update it later.
- KennyBlanken 3y ago
  AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. The updates can often contain pretty substantial changes, like resizable BAR support. Further: I'm typing this on a Macbook Pro which is running right now only because I was able to pull the bootrom (which is UEFI), add a NVME driver from a newer Macbook Pro, package it back up, and flash it back to the older Macbook Pro. This let me use an NVME drive in a machine released before they added NVME support to that system's bootrom. The only side effect was that the OS didn't fully support NVME standby modes so power consumption was slightly higher, but even that was fixed in a later OS update which was released after NVME drives were in several models.
  - asveikau 3y ago
    > AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. And very few people update their BIOS with any frequency. But most people update their OS.
- cesarb 3y ago
  > If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Not only that, but updating firmware is always riskier than updating the OS. If an OS update is broken, you can easily use the firmware to recover (booting from the OS install media and working from there); recovering from a failed firmware update can be much harder and/or obscure.
  - SoftTalker 3y ago
    In some cases nearly impossible for the owner of the hardware. Supermicro BIOS updates advise that in case of failed updates, it may be necessary to send the board back to be reflashed, presumably via some sort of direct hardware connection.
nemetroid 3y ago
No thanks. Early boot software should only do the bare minimum required to hand over control to the real operating system. If this means some code duplication between operating systems, that’s OK.
- snvzz 3y ago
  In contrast, I prefer starting the kernel on a cpu that doesn't have known microcode bugs, which implies doing the upgrade earlier, be it in firmware or bootloader. Fortunately, fwupd, together with UEFI capsule, can make upgrading firmware very easy and safe. Ideally, a CPU wouldn't have to get that many microcode updates anyway.
bpye 3y ago
I haven’t checked the changes here, but even if your FW carries a recent ucode at boot, you may find yourself wanting to update the ucode at runtime without a reboot. This is certainly possible on Linux.
nazgulsenpai 3y ago
I don't know to what extent but I believe that's what AMD's openSIL project aims to do. https://github.com/openSIL/openSIL https://github.com/openSIL/openSIL
m_z_s 3y ago
I totally agree, BUT (there is always a but) a fully open boot process is also fully open for maliciousness. e.g. With full access to all hardware you could tell the PMIC (Power Management IC) to output the maximum voltage for some pins to permanently damage/destroy the SoC or other hardware on the board. This would also require that the hardware being damaged is also under-clocked for maximum effectiveness. I love that I have full access to all the hardware, but I always keep in mind that the second that I run other peoples software on my hardware it always opens the possibility that it is no longer my hardware.

by snvzz 3y ago

chriscappuccio 3y ago

RISC V will end at the same fate when implemented by the same vendors

asveikau 3y ago

If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.

snvzz 3y ago
>If boot firmware implemented it, I wouldn't count on it being updated very often. That's precisely the problem when it's not possible to upgrade that boot firmware without the vendor's help. Or why x86 firmware contains microcode, yet we still have to update it later.
KennyBlanken 3y ago
AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. The updates can often contain pretty substantial changes, like resizable BAR support. Further: I'm typing this on a Macbook Pro which is running right now only because I was able to pull the bootrom (which is UEFI), add a NVME driver from a newer Macbook Pro, package it back up, and flash it back to the older Macbook Pro. This let me use an NVME drive in a machine released before they added NVME support to that system's bootrom. The only side effect was that the OS didn't fully support NVME standby modes so power consumption was slightly higher, but even that was fixed in a later OS update which was released after NVME drives were in several models.
- asveikau 3y ago
  > AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. And very few people update their BIOS with any frequency. But most people update their OS.
cesarb 3y ago
> If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently. Not only that, but updating firmware is always riskier than updating the OS. If an OS update is broken, you can easily use the firmware to recover (booting from the OS install media and working from there); recovering from a failed firmware update can be much harder and/or obscure.
- SoftTalker 3y ago
  In some cases nearly impossible for the owner of the hardware. Supermicro BIOS updates advise that in case of failed updates, it may be necessary to send the board back to be reflashed, presumably via some sort of direct hardware connection.

nemetroid 3y ago

No thanks. Early boot software should only do the bare minimum required to hand over control to the real operating system. If this means some code duplication between operating systems, that’s OK.

snvzz 3y ago
In contrast, I prefer starting the kernel on a cpu that doesn't have known microcode bugs, which implies doing the upgrade earlier, be it in firmware or bootloader. Fortunately, fwupd, together with UEFI capsule, can make upgrading firmware very easy and safe. Ideally, a CPU wouldn't have to get that many microcode updates anyway.

bpye 3y ago

I haven’t checked the changes here, but even if your FW carries a recent ucode at boot, you may find yourself wanting to update the ucode at runtime without a reboot. This is certainly possible on Linux.

nazgulsenpai 3y ago

I don't know to what extent but I believe that's what AMD's openSIL project aims to do. https://github.com/openSIL/openSIL https://github.com/openSIL/openSIL

m_z_s 3y ago

I totally agree, BUT (there is always a but) a fully open boot process is also fully open for maliciousness. e.g. With full access to all hardware you could tell the PMIC (Power Management IC) to output the maximum voltage for some pins to permanently damage/destroy the SoC or other hardware on the board. This would also require that the hardware being damaged is also under-clocked for maximum effectiveness. I love that I have full access to all the hardware, but I always keep in mind that the second that I run other peoples software on my hardware it always opens the possibility that it is no longer my hardware.