What more vulnerabilities hides in the proprietary UEFI?
I have no interest whatsoever to install MS Windows, is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS?
I have no interest whatsoever to install MS Windows, is there any motherboards out there for AMD64/X86_64 that comes without UEFI/BIOS?
Your computer needs UEFI/BIOS for hardware initialization and launching your boot process.
There is a open implementation tho, see https://libreboot.org/
> The Libreboot project provides free, open source (libre) boot firmware based on coreboot, replacing proprietary BIOS/UEFI firmware on specific Intel/AMD x86 and ARM based motherboards, including laptop and desktop computers. It initialises the hardware (e.g. memory controller, CPU, peripherals) and starts a bootloader for your operating system.
Most UEFI vulnerabilities seem to come from bugs in the open source reference implementation making it down to the proprietary firmware.
That said: as much as you would expect from any low-level C program. I hope that EDK will eventually find itself rewritten in a safer language to it easier to spot mistakes. I would say Rust would be the best fit, but I admit that it's not a perfect fit; sadly, we lack safe low-level languages.
As for running without UEFI/BIOS: most ARM devices have an alternate bootloader (usually uBoot with some proprietary magic) but I don't know if that's much better. This approach usually requires per-device support from the operating system you want to install.
Rust is a safe low-level language. You can start writing your UEFI implementation in rust today [1], [2]
> As for running without UEFI/BIOS: most ARM devices have an alternate bootloader
UEFI/BIOS is not a bootloader, they initialize hardware and then pass on responsibility to a bootloader. Popular bootloaders are the Windows bootloader, grub, etc etc.
I see Rust as a C++ replacement more than a C replacement. I'm not sure if object oriented languages (well, "struct with functions" in Rust's case) with vtables and dynamic allocation and the like are a good match for that kind of code. Rust, as a language, simply can't deal with running out of memory; all allocations are assumed to succeed, which is a dangerous assumption, especially in low-level code like this.
Unfortunately, we don't really have a common C replacement with Rust-like safety guarantees. I'm hoping Zig will be able to provide some safety to the C ecosystem, but it's still a ways away from 1.0.
> UEFI/BIOS is not a bootloader
You're right, I meant "bootstrapping system". I'm sure there's better terminology here but the word escapes me at the moment.
One could, of course, write their own allocator and heap tracking system as part of the UEFI firmware, or reimplement the entire thing without any of the standard library and simply relying on the core library, but if you want to deal with fallibility, you'll have to reimplement every part of the language toolkit and use Option<> or Result<> for every API call, which would only complicate the rewrite more.
> you'll have to reimplement every part of the language toolkit
You shouldn't need to, those APIs already exist. Like https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m... for example. Maybe there's some coverage missing, I personally use no heap when I'm working in this context.
The chromebook variant already runs coreboot, with all changes upstreamed: https://frame.work/blog/introducing-the-framework-laptop-chr...
You're going to need firmware anyway, otherwise your OS implements the firmware responsibilities, and you then GOTO 1, and have other problems.