4 ms·

Even better, dump that UEFI crap. Not even Rust can fix stupid. Just directboot a static kernel and kexec() the real kernel -- like petitboot has been doing s

Even better, dump that UEFI crap. Not even Rust can fix stupid. Just directboot a static kernel and kexec() the real kernel -- like petitboot has been doing since forever: https://github.com/open-power/petitboot/blob/master/README.md https://github.com/open-power/petitboot/blob/master/README.m... Unless you like writing everything (display drivers, disk drivers, filesystem drivers, network stacks...) twice. Which is where these bugs come from...

weinzierl 3y ago
I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.
- delusional 3y ago
  They have a custom bootloader https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.
  - ciupicri 3y ago
    Yeah, if I remember correctly even AMD was amazed of what they did.
  - pbronez 3y ago
    Oxide co-founder Jessie Frazelle published an ACM Queue article about the security advantages of open source firmware in 2019: https://queue.acm.org/detail.cfm?id=3349301 https://queue.acm.org/detail.cfm?id=3349301
- p_l 3y ago
  It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control. TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.
- steveklabnik 3y ago
  Others have already given good answers but also here’s a talk about this subject: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
dvdkon 3y ago
You'd need to either have drivers in the kernel for everything, with no common fallback ("the ARM approach"), or have standards at the hardware/HW firmware level. Having a firmware-level abstraction layer that papers over this for fallback may not be the best idea, but it works without too much politicking.
mkopec 3y ago
I would like to be able to ensure that only boot loaders signed with my private key can be executed. Secure Boot serves that purpose well, can I do that with your approach? Likewise, demand and use cases for network boot exist, otherwise it wouldn't be here. Same goes for every other feature most users would consider bloat.
- crotchfire 3y ago
  Yes of course you can. Just run `signify -V` in userspace under the pre-kexec() kernel to check the signature on the post-kexec() kernel/initrd. You can network boot too; just run `busybox udhcpc`. I think you misread my comment. I never described signature-checking or network boot as bloat. I said it was stupid to have to implement these things twice (once in mainline Linux and then all over again in kooky UEFI-land with its bizzarre API, ABI, and wacky rules). I still think it is stupid to do that, because it is. We have working, high-quality, battle-tested implementations of all this stuff. Use them.
devaiops9001 3y ago
This petitboot thing is very cool. Thank you for sharing this.
yjftsjthsd-h 3y ago
So here we have security vulnerabilities in an open source UEFI implementation, resulting in a thread about how UEFI is too complex. So your solution... is to use the actual Linux kernel plus some glue code as your boot firmware? I love Linux, but it is neither simple nor free of security vulnerabilities; what exactly does this buy us? Edit: On reading another reply, I see your argument for having fewer implementations; that's not nothing, but it only really helps if everything is on Linux, which isn't going to help most desktops (and I hope we can agree that NT in firmware is not better) or the rest of the world that isn't on Linux (say, the BSDs).

weinzierl 3y ago

I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.

delusional 3y ago
They have a custom bootloader https://github.com/oxidecomputer/phbl https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.
- ciupicri 3y ago
  Yeah, if I remember correctly even AMD was amazed of what they did.
- pbronez 3y ago
  Oxide co-founder Jessie Frazelle published an ACM Queue article about the security advantages of open source firmware in 2019: https://queue.acm.org/detail.cfm?id=3349301 https://queue.acm.org/detail.cfm?id=3349301
p_l 3y ago
It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control. TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.
steveklabnik 3y ago
Others have already given good answers but also here’s a talk about this subject: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

dvdkon 3y ago

You'd need to either have drivers in the kernel for everything, with no common fallback ("the ARM approach"), or have standards at the hardware/HW firmware level. Having a firmware-level abstraction layer that papers over this for fallback may not be the best idea, but it works without too much politicking.

mkopec 3y ago

I would like to be able to ensure that only boot loaders signed with my private key can be executed. Secure Boot serves that purpose well, can I do that with your approach? Likewise, demand and use cases for network boot exist, otherwise it wouldn't be here. Same goes for every other feature most users would consider bloat.

crotchfire 3y ago
Yes of course you can. Just run `signify -V` in userspace under the pre-kexec() kernel to check the signature on the post-kexec() kernel/initrd. You can network boot too; just run `busybox udhcpc`. I think you misread my comment. I never described signature-checking or network boot as bloat. I said it was stupid to have to implement these things twice (once in mainline Linux and then all over again in kooky UEFI-land with its bizzarre API, ABI, and wacky rules). I still think it is stupid to do that, because it is. We have working, high-quality, battle-tested implementations of all this stuff. Use them.

devaiops9001 3y ago

This petitboot thing is very cool. Thank you for sharing this.

yjftsjthsd-h 3y ago

So here we have security vulnerabilities in an open source UEFI implementation, resulting in a thread about how UEFI is too complex. So your solution... is to use the actual Linux kernel plus some glue code as your boot firmware? I love Linux, but it is neither simple nor free of security vulnerabilities; what exactly does this buy us? Edit: On reading another reply, I see your argument for having fewer implementations; that's not nothing, but it only really helps if everything is on Linux, which isn't going to help most desktops (and I hope we can agree that NT in firmware is not better) or the rest of the world that isn't on Linux (say, the BSDs).