Libre boot

[Enigmatic]

Any guys out there using Libre or Core boot?
I find it hard to compile the Coreboot tools, but found it easy to dump the bios firmware.
Anyone know when they say compatable hardware is it strictly speaking? Or can there be some success stories out there on some laptops and mobo's with fast cpu support.

[Cat on Linux]

no, haven't used it, as Rogue already mentioned in his detailed post, you need to have very specific hardware to do so.

[Enigmatic]

Hopfully China makes new CPUs that respect Freedom. Untill than we can keep taking Hwawaii employee hostage.

I think purism uses coreboot on newer hardware, not sure. However I know intel has non-free firmware that cannot be removed on the newer achetecture. pretty much every thing effected by spectre and meltdown.

[Marlock]

yeah, Purism is working with coreboot and contributing to its codebase

I definitely wouldn't risk bricking any hardware flashing coreboot or libreboot on non-oficially-supported hardware! that most likely has near-null chance to work!

[Enigmatic]

:( Sad, I'd have to overwrite my EFI bios.
Hopefully coreboot gets Over clocking support.
If you brick it you can always flash it back :).

I know it's not the most exciting thing booting a PC. However I think doing it with no closed source or binary blobs is a very good thing.

Amd's secure processor bugs me to no end. Same with intel. Also so does me Uefi bios. I may use efi to boot my OS but the Uefi bios has a network stack which apperently you can turn off but I need to figure out how to read wireshark dumps to see if that's really the case.

[Marlock]

I am hopeful that coreboot and similar projects will take a much bigger importance in 2019, with luck we will get some plain home consumer mobos supported too...

it's not completely impossible, but it is definitely non-trivial to flash a bios chip on a mobo after it becomes unbootable... it's easy only on a few mobos that have special features like dual-bios or recovery bios


about AMD's secure processor, i get that any closed source parallel system is a big trust issue... but does AMD offer any remotely manageable bios like intel? to me that is the most disastrous part of the concept, and afaik only intel went so far, but I may be oblivious to similar "offerings" from amd

ps: I had an intel NUC with this remotely manageable uefi "feature"... bought the thing without knowing this, and reading their sales pitch description of it was enough to know it was dangerous and stupid, disabled it ling before their security scandal broke open... it is simply a terrible, terrible idea!

[Enigmatic]

Actually dual bios seems to complicate matters a little bit. Not much though as long as it can be written to. I've seen Dell bios being very difficult to dump I couldn't read the 32 bit part of the system with flashrom.

Heres the thing though. Intel AMT does have remote feature but at least it can be acessed by the end user (although the OEM gets to decide if Minix is bootable in the bios..). It's odd the default password is admin yet when you set one it requires a special character. It's like all Iphones having default root password of alpine. Inside intel MBEX there is a bunch of Root certificates much like a web browser has.

Heres the other thing it's not just intel and AMD. Motherboard manufacturers play a big part in this. They implement the intel features how they see fit. You see intel ME is now needed to boot the computer. Seems like an artificial lock. I've bricked my laptop you see, actually on my paticular dell model the intel AMT network stack was removable and it boots. However, the Dell bios has it's own network stack and I couldn't read the eeprom with flashrom :(. It's a newer model I think 2015-2016.

Lots of Bios implementations have their own network stacks, not including Intel or AMD. Which is a pain in the but if you trust them or not.Which is why we need some talented individuals to build and work on the Efi code for grub.This is the part I think is not trivial. There are not enough people working on this tbh, and I am only been using linux full time as my operating system for a year with no coding experience. The people reverse engineering and writing code for stuff like libreboot and efibootmgr are doing good work. I think the coreboot team could aways use some dumps of peoples firmware as they do not have unlimited resources. It seems they really like to work on thinkpads though.

Sadly I am not experienced enough to really contribute much. Actually I don't think Intel had nefarious plans with intel AMT. However I think a certain branch of US government saw utility in it and maybe helpped guide future implementations. Not sure but that's just my guess. Look at the newer mobo's compaired to Server. Why are gaming Mobos riddiled with new features. Yet, are cheap? I know server market is different, and they willing to spend more. However I find it strange the desktop mobo's have this persistant kind of implementations and coming at a lower cost.

[Enigmatic]

I noticed Dell bios has a 'Secure boot' section that signs to boot.
It wouldn't let me boot into my linux install if 'secure' boot is on.

Heres the thing looking at new Mobos for 'enthusiasts' I looked at the books that come with the boards. For the new intel 9900k . Lots of OEM used to show you where the bios eeprom chip was on the board.

Now I couldn't find in their books where it was. Also more dual bios. Gigabyte seems more open but who knows how good thier uefi bios implementation is?

Seriously on my desktop I have a removable bios chip. After Haswell I have a hard time finding 'enthusiast' boards with that feature. It's not only fustrating it stops me from buying them. Maybe I'll save money on a cheaper mobo in the future. No laptop will have removable bios but at least you can find it. Now all these new 'gaming' mobos are covered in plastic and leds. Which believe me, makes things harder :)

[Aoi Blue]

I really think a new Open Source bootloader needs to be made with the UEFI standard. It should change the implementation of Secure Boot to always allow non-Microsoft certificates, and allow installing of certificates from side-load medium (such as USB flash drives.)

It should furthermore allow boot to load in non-secureboot means if the boot verification fails. It should notify both the user and the Operating System that this is the case. It should prompt the user before continuing giving the "Do not require Secure Boot on this bootloader" to prevent future prompts.

A second system should also be installed to provide the OS with hashes of the bootloader to provide a secondary security measure, since this is how secure boot should have worked anyhow.

[Marlock]

What do you think of Purism's efforts to implement a user-controled verification of the boot chain?

To me they are the single current viable concept for this (and it looks like their implementation works well too) that doesn't sacrifice freedom whilst actually having a complete trust chain...

But obviously there might be other I'm not aware of.

[Enigmatic]

anything post Skylake needs the Intel ME kernel still. If you remove it, it won't boot.
It has the HAP bit however if it works is hit or miss. But with it on it's invisible to the OS.

Get a good Core2duo or Core2quad. They are one of the best where you can remove the whole thing.

Risc-v look promising. I hope they get more manufacturing.

[Aoi Blue]

Quite a few motherboards now implement user verification of the bootchain. Specifically they do not disable all SecureBoot functions just because you turn off (or don't enable) the verified boot mode. This means the other crypto checks are in place.

Also, almost all motherboards now permit you to install third party keys as well as there being a secondary signer that Microsoft provides to many Linux distro producers. (Microsoft provided that signer under threat of lawsuit, and has on several occasions tried to undermine it.)

[Marlock]

AFAIK Purism are hard at work on disabling and/or replacing as much of Intel's firmware binary blobs as they can despite providing a modern and powerful x86 architecture cpu... not everyone can simply get away from the chip architecture/performance requirements, so i see their effort as a good thing actually...

There were some pretty detailed posts in 2018 on their attempts to reverse engineer the uefi bios for their offered hardware, so I always assumed they were very serious about what they are doing, but obviously it is a work in progress, so blobs are still needed to some (gradually diminishing) extent. They use a version of Coreboot on their most recent offerings and have been very transparent on the progress of the opensource substitution of firmware.

About the boot sequence verification, they are implementing a version of HEADS, which means boot sequence is signed by the user and verified, but not just the OS... the firmware itself gets verified too (afaik this is not usual, with secure boot just meaning firmware verifying OS), there is an interface to generate alerts that should work even in case of a compromised firmware, and the user can choose to trust and re-sign the whole thing at any given time.

I think this post sumarizes their efforts well:
https://puri.sm/posts/protecting-the-digital-supply-chain/

[Aoi Blue]

Originally posted by Marlock:

AFAIK Purism are hard at work on disabling and/or replacing as much of Intel's firmware binary blobs as they can despite providing a modern and powerful x86 architecture cpu... not everyone can simply get away from the chip architecture/performance requirements, so i see their effort as a good thing actually...

There were some pretty detailed posts in 2018 on their attempts to reverse engineer the uefi bios for their offered hardware, so I always assumed they were very serious about what they are doing, but obviously it is a work in progress, so blobs are still needed to some (gradually diminishing) extent. They use a version of Coreboot on their most recent offerings and have been very transparent on the progress of the opensource substitution of firmware.

About the boot sequence verification, they are implementing a version of HEADS, which means boot sequence is signed by the user and verified, but not just the OS... the firmware itself gets verified too (afaik this is not usual, with secure boot just meaning firmware verifying OS), there is an interface to generate alerts that should work even in case of a compromised firmware, and the user can choose to trust and re-sign the whole thing at any given time.

I think this post sumarizes their efforts well:
https://puri.sm/posts/protecting-the-digital-supply-chain/

Hope they do this with AMD's hardware next. It should be easier, as AMD provides far more Open hardware and far more open source support than Intel.

Honestly, though, considering Intel's current hold on the server market, I think Intel should be prioritised. This is coming from someone who actually prefers AMD himself.

[Marlock]

Actually Intel does provide quite a lot of opensource support in general (10x more code contributed to their GPU stack in 2017 than AMD to theirs and all that...), but not yet much in this specific area.

They did recently announce they will probably opensource their FSP soon:
https://www.phoronix.com/scan.php?page=news_item&px=Intel-Open-Source-FSP-Likely

[Enigmatic]

Purism is using the work of Nicola Corna and others, I'm pretty sure they just use his python script. Anyone can do it.
As now Intel ME is easier to deal with than AMD's proprietary blob. Intel puts it with the Bios. AMD has a subsystem if I'm not mistaken, is probably harder to deal with.

Most CPU's 'modern' can't run without microcode now.