4 ms·

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

by tonoto 3y ago

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?

yencabulator 3y ago
You might like these https://frame.work/blog/open-sourcing-our-firmware https://frame.work/blog/open-sourcing-our-firmware https://support.system76.com/articles/open-firmware-systems/ https://support.system76.com/articles/open-firmware-systems/
- oarmstrong 3y ago
  Framework has open sourced the EC firmware, not the boot firmware. The UEFI implementation is still closed source proprietary InsydeH2O software.
  - yencabulator 3y ago
    Yes, but at least they're making soothing noises about going in that direction. Here's notes on coreboot work: https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791 https://community.frame.work/t/responded-coreboot-on-the-fra... The chromebook variant already runs coreboot, with all changes upstreamed: https://frame.work/blog/introducing-the-framework-laptop-chromebook-edition https://frame.work/blog/introducing-the-framework-laptop-chr...
- tonoto 3y ago
  I do like the direction that Framework is going and I hope they will deliver to more countries during 2024.
shzhdbi09gv8ioi 3y ago
> 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/ 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.
Aissen 3y ago
Did you read the article about how this is a bug in the open source reference implementation ? You're going to need firmware anyway, otherwise your OS implements the firmware responsibilities, and you then GOTO 1, and have other problems.
mkopec 3y ago
Some piece of code has to configure the CPU, initialize memory before you can even think about loading an OS...
transpute 3y ago
Coreboot on MSI with Raptor Lake, https://www.phoronix.com/news/Dasharo-1.1.2-MSI-Z690-A https://www.phoronix.com/news/Dasharo-1.1.2-MSI-Z690-A
fsflover 3y ago
My Librem 14 laptop came with coreboot/Pureboot.
jeroenhd 3y ago
> What more vulnerabilities hides in the proprietary UEFI? 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.
- shzhdbi09gv8ioi 3y ago
  > 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. 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. 1: https://rust-osdev.github.io/uefi-rs/HEAD/ https://rust-osdev.github.io/uefi-rs/HEAD/ 2: https://github.com/rust-osdev/uefi-rs/tree/main/template https://github.com/rust-osdev/uefi-rs/tree/main/template
  - jeroenhd 3y ago
    Rust is _a_ safe language, but if you're interacting with a lot of low-level hardware, you end up with a lot of unsafe {} code and manual analysis that takes away some of the advantages. 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.

by tonoto 3y ago

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?

yencabulator 3y ago

You might like these https://frame.work/blog/open-sourcing-our-firmware https://frame.work/blog/open-sourcing-our-firmware https://support.system76.com/articles/open-firmware-systems/ https://support.system76.com/articles/open-firmware-systems/

oarmstrong 3y ago
Framework has open sourced the EC firmware, not the boot firmware. The UEFI implementation is still closed source proprietary InsydeH2O software.
- yencabulator 3y ago
  Yes, but at least they're making soothing noises about going in that direction. Here's notes on coreboot work: https://community.frame.work/t/responded-coreboot-on-the-framework-laptop/791 https://community.frame.work/t/responded-coreboot-on-the-fra... The chromebook variant already runs coreboot, with all changes upstreamed: https://frame.work/blog/introducing-the-framework-laptop-chromebook-edition https://frame.work/blog/introducing-the-framework-laptop-chr...
tonoto 3y ago
I do like the direction that Framework is going and I hope they will deliver to more countries during 2024.

shzhdbi09gv8ioi 3y ago

> 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/ 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.

Aissen 3y ago

Did you read the article about how this is a bug in the open source reference implementation ? You're going to need firmware anyway, otherwise your OS implements the firmware responsibilities, and you then GOTO 1, and have other problems.

mkopec 3y ago

Some piece of code has to configure the CPU, initialize memory before you can even think about loading an OS...

transpute 3y ago

Coreboot on MSI with Raptor Lake, https://www.phoronix.com/news/Dasharo-1.1.2-MSI-Z690-A https://www.phoronix.com/news/Dasharo-1.1.2-MSI-Z690-A

fsflover 3y ago

My Librem 14 laptop came with coreboot/Pureboot.

jeroenhd 3y ago

> What more vulnerabilities hides in the proprietary UEFI? 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.

shzhdbi09gv8ioi 3y ago
> 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. 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. 1: https://rust-osdev.github.io/uefi-rs/HEAD/ https://rust-osdev.github.io/uefi-rs/HEAD/ 2: https://github.com/rust-osdev/uefi-rs/tree/main/template https://github.com/rust-osdev/uefi-rs/tree/main/template
- jeroenhd 3y ago
  Rust is _a_ safe language, but if you're interacting with a lot of low-level hardware, you end up with a lot of unsafe {} code and manual analysis that takes away some of the advantages. 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.