Coreboot Picks Up A New Kabylake Chromebook "Fizz"

[phoronix]

Phoronix: Coreboot Picks Up A New Kabylake Chromebook "Fizz"

It may not be as exciting as hearing Dell looking at Coreboot, but another Intel-powered Chromebook is now supported by mainline Coreboot...

http://www.phoronix.com/scan.php?page=news_item&px=Coreboot-KBL-Fizz-Chromebook

[MiUNX]

Any subject experts on the topic of low level coding (I code higher level :-( ). From my understanding coreboot is useless in protecting you, considering this separate CPU (CPU within CPU), whether it's the Intel IME or the AMD PSP have direct access to everything (memory, network, etc) and all coreboot does is use the public interface/api of the cpu. So assuming the IME/PSP are created and/or embedded with hostile code, there is no protecting against it, in any way shape or form.... thoughts?

[starshipeleven]

Any subject experts on the topic of low level coding (I code higher level :-( ). From my understanding coreboot is useless in protecting you, considering this separate CPU (CPU within CPU), whether it's the Intel IME or the AMD PSP have direct access to everything (memory, network, etc) and all coreboot does is use the public interface/api of the cpu. So assuming the IME/PSP are created and/or embedded with hostile code, there is no protecting against it, in any way shape or form.... thoughts?

Correct. Coreboot is mostly a way to not pay the usual BIOS vendors (and get a far higher quality board firmware imho).

Libreboot or whatever is the de-blobbed version can't boot any system where there is a IME/PSP as these things need a blob firmware.

[MiUNX]

Apologies, I meant libreboot.

My understanding of IME and PSP are that these are additional cpus inside the main cpu. For example, AMD uses an ARM cpu (this is what they call PSP).

This embedded ARM (PSP) cpu exposes instructions to the firmware (the blob ("microcode") or libreboot.).

I meant that even libreboot will not be able to protect your pc from a hostile psp (hostile hardware (we don't know what's happening inside), as apposed to hostile "software") and that there would be no way to verify other than "open hardware".

Thoughts?

[tajjada]

For me, the biggest advantage of coreboot is its technical design. The fact that it is super minimalistic, very fast, and can be hooked up to load just about anything (SeaBIOS, TianoCore EFI, GRUB, a Linux kernel directly, ...).

I am sick and tired of horrible messy firmware that never works properly. Every PC that I have used has had weird quirks in its UEFI implementation (some worse than others) that I have to work around (one of the worse examples: on my laptop, I had to rename the Microsoft folder in the EFI partition, in order to get dual boot to work, because otherwise the firmware detected the Windows bootloader (I presume it has a hardcoded path for it) and automatically deleted my rEFInd boot entry and unconditionally booted Windows, so I had to boot into a live iso to reconfigure the boot entries to be able to boot back into Linux...). I hate the piece of shit that is UEFI. I mean, it can be a nice idea in theory, but I have yet to see a good implementation that is not buggy as hell. This means that it is super frustrating in practice.

This is my main reason for wanting FOSS firmware. I want my firmware to work and to be reliable. I want nice firmware. When something is FOSS (particularly when it's a popular project), it never stays broken for long. I know it will be fixed and improved over time. With proprietary stuff ... not so much.

Being FOSS also has the nice extra safety and security advantage of people (incl. myself and also security experts) being able to read the code and know exactly what it's doing. But I really don't like it when people act like that's the only reason for the Coreboot project to exist, and ignore its technical and purely practical merits. Coreboot is awesome. I wish it supported more hardware, and more modern hardware.

I would be infinitely happier if Coreboot supported my systems despite ME/PSP coprocessors. Sure, ideally, I'd like them to not be there, executing unknown vendor code in the background, but I don't mind them, in the sense that I am doing perfectly fine right now with them being there. Having Coreboot would be a massive improvement over vendor UEFI in terms of pure usability, security or not, and I'd be a lot happier if I could use it.

[Tomin]

I would be infinitely happier if Coreboot supported my systems despite ME/PSP coprocessors. Sure, ideally, I'd like them to not be there, executing unknown vendor code in the background, but I don't mind them, in the sense that I am doing perfectly fine right now with them being there. Having Coreboot would be a massive improvement over vendor UEFI in terms of pure usability, security or not, and I'd be a lot happier if I could use it.

Indeed. I don't think there is an UEFI payload that has configuration menu like most vendor UEFI implementation have. Or am I wrong here? It should support selecting boot device and changing clock speeds and such. That is something we'd need in addition to hardware support.

[starshipeleven]

My understanding of IME and PSP are that these are additional cpus inside the main cpu. For example, AMD uses an ARM cpu (this is what they call PSP).

This embedded ARM (PSP) cpu exposes instructions to the firmware

See the FAQ of libreboot for a better explanation

https://libreboot.org/faq.html#intelme

https://libreboot.org/faq.html#amd

In either cases, this hardware is initialized before the x86 CPU and if its initialization fails (i.e. its firmware blob isn't provided), then the x86 CPU won't be started and the system will stay dead.

Libreboot/Coreboot/UEFI are loaded on the x86 CPU and this happens AFTER the secure processor is up and running.

Then, this secure processor has an API that allow stuff running on x86 processor with the right crypto signatures to be loaded and executed in its safe heaven with total control over everything. The board firmware can't stop this communication as it is not in charge of the system.

(the blob ("microcode") or libreboot.).

The microcode is a relatively benign form of firmware as it deals with very specific low-level stuff like teaching a specific digical circuit how to react to some specific low-level stimuli, in anything remotely modern it's present in either blob form or burned to a on-chip ROM (usually both, and is updated on boot to correct eventual issues discovered after the chip was manufactured).

Libreboot, Coreboot, UEFI are board firmwares that provide a user interface, and usually have some kind of network stack for PXE booting, a GUI, support input devices and are basically a tiny OS in their own right.

Also the firmware blobs running in the IME or PSP are pretty much OSes in their own right.

I meant that even libreboot will not be able to protect your pc from a hostile psp (hostile hardware (we don't know what's happening inside), as apposed to hostile "software") and that there would be no way to verify other than "open hardware".

Given what I said above, either open hardware or a device without such security processors.

[tajjada]

Indeed. I don't think there is an UEFI payload that has configuration menu like most vendor UEFI implementation have. Or am I wrong here? It should support selecting boot device and changing clock speeds and such. That is something we'd need in addition to hardware support.

I think this is true, but only because the existing open-source UEFI payloads have been designed for use cases like virtual machines (TianoCore OVMF), or embedded-like use cases, and not desktop PCs. And I think this is mostly because of Coreboot's poor support for desktop PCs. I don't think anyone is going to develop a fancy open-source UEFI payload with nice menus and overclocking and stuff like that if it cannot be used anywhere, so Coreboot needs to better support desktop motherboards and CPUs first, for that to happen.

[starshipeleven]

Indeed. I don't think there is an UEFI payload that has configuration menu like most vendor UEFI implementation have. Or am I wrong here? It should support selecting boot device and changing clock speeds and such. That is something we'd need in addition to hardware support.

Afaik the EFI payload can switch the GPU to graphics mode so they could show that stuff if needed.

Making a ncurses-like interface for such stuff isn't terribly hard as it isn't hardware-specific, if there is some usecase it will get whipped together in no time.

For that matter, not even BIOS payload has a true interface like that.

[tajjada]

Afaik the EFI payload can switch the GPU to graphics mode so they could show that stuff if needed.

Making a ncurses-like interface for such stuff isn't terribly hard as it isn't hardware-specific, if there is some usecase it will get whipped together in no time.

For that matter, not even BIOS payload has a true interface like that.

Ofc all of this is possible and not too hard. I think Tomin meant that currently there is no FOSS UEFI that provides the kind of user interface and functionality that proprietary vendor UEFI implementations have. Which is why, in my reply, I said that it is unlikely that there will be demand for such a thing to be developed, until Coreboot properly supports modern desktop PCs.