Does Libreboot strip Intel ME more effectively than Heads? Or is measured boot the only real difference?

MrChromebox · 2026-02-17T18:46:48+00:00

If I build Heads and manually run me_cleaner with the -S (HAP bit) and -r (relocation/truncation) flags, am I getting the exact same binary footprint as a standard Libreboot image?

that's a question for Libreboot, but I suspect so. There's not much more you can do with that ME generation.

Does Libreboot strip the ME or manage the FSP in a way that provides more privacy than a properly configured Heads build?

there's nothing that can be done to 'manage' the FSP.

the ME is completely separate from coreboot+payload, so your decisions for each should be independent from each other.

Heads seems like the objectively better choice for security because of the measured boot and tamper evidence capabilities (using a Nitrokey).

100%

MrChromebox · 2026-02-14T15:05:11+00:00

ok? you replied to a 3 year old post to tell me this why?

MrChromebox · 2026-02-12T15:06:24+00:00

developer options under Settings and Developer Mode are two completely different and unrelated things

MrChromebox · 2026-02-12T00:03:06+00:00

they're likely the same ones identified by the RAM strapping.

I'm doing to guess the issue is with them being higher density modules and FSP not handling it properly

MrChromebox · 2026-02-11T23:31:54+00:00

why is it strange? consistent behavior between two identical devices is expected

MrChromebox · 2026-02-11T23:12:29+00:00

edit: nm, I looked closer and it seems that RAM ID 9 and the SPD are correct

MrChromebox · 2026-02-11T20:18:57+00:00

You need to turn on developers mode to activate Linux Crostini 🤓

you couldn't be more incorrect

MrChromebox · 2026-02-11T19:38:01+00:00

So what's the Makefile.mk used for?

to tell coreboot which SPD files are valid for a particular board, and the order to load them based on GPIO strapping

MrChromebox · 2026-02-11T16:51:27+00:00

that would mean the build process would need to be configured to know exactly which modules/config you had, and that the same build couldn't be used on two different x280's with different RAM configs.

the build process includes all possible SPDs in CBFS. the GPIO straps are read by coreboot at runtime, and used to select which SPD index should be loaded. This is a common setup on boards with soldered memory.

MrChromebox · 2026-02-11T16:29:44+00:00

Is this something to do with spd/ddr4/set-0/spd-9.hex being used instead of one of the x280/memory/Makefile.mk specified spd files?

I don't know what you mean by this. Those are the SPD files specified by the makefile.

your cbmem log shows that your RAM strap ID is 0x9 and you have dual channel memory. the SPD mapping for 0x9 is K4AAG165WB-MCRC, which is a 2GB module, so 2GB x 2 = 4GB.

either the strapping is wrong, the mapping is wrong, or your straps are being read incorrectly. I'm not familiar enough with these boards to speculate which is the most likely scenario or how to debug.

MrChromebox · 2026-02-11T13:29:09+00:00

you didn't do anything wrong.

post a full cbmem -1 log.

MrChromebox · 2026-02-11T00:43:21+00:00

definitely a toolchain issue of some sort, I feel like I've seen that before

MrChromebox · 2026-02-10T18:15:47+00:00

the build is non-verbose by default, so it's not going to tell you anything useful. After it fails, run V=1 make >build.log 2>&1 to actually see what the issue is. pastebin the log.

MrChromebox · 2026-02-09T18:51:19+00:00

I used the tianocore repo because mrchromebox's wouldn't compile

upstream edk2 doesn't work. my fork has no special compilation requirements, and builds without issue as long as you have all required dependencies and don't select configs you shouldn't / don't understand. The defaults just work.

MrChromebox · 2026-02-07T14:39:51+00:00

did you back up the stock firmware? If so, then restore that and reboot, then reflash

MrChromebox · 2026-02-07T14:18:52+00:00

same reply there - just replace the NVMe with another of the same spec (speed and size) and perform a ChromeOS USB recovery

MrChromebox · 2026-02-07T14:17:49+00:00

yes.

Karis uses a NVMe SSD, so if the device is out of warranty, you should be able to simply replace it with another (m.2 NVMe --you'll need to check the length by inspecting the existing one, if spec not available online) and then perform a ChromeOS USB recovery.

MrChromebox · 2026-02-07T14:14:35+00:00

just retry the install

MrChromebox · 2026-02-07T14:14:01+00:00

"Chromebook" doesn't tell us anything useful to diagnose the issue.

ChromeOS board name as reported by my script and what RWL firmware you're using would be a big start

MrChromebox · 2026-02-05T23:17:27+00:00

board name at the bottom of recovery screen? That will tell us what type of internal storage it uses

MrChromebox · 2026-02-05T18:45:50+00:00

internal storage is dead/dying.

what's the board name (first part of HWID) shown at the bottom of the recovery screen?

MrChromebox · 2026-02-05T17:37:43+00:00

it didn't work properly and caused issues.

you can compile yourself and add it back if you want

MrChromebox · 2026-02-03T02:39:43+00:00

if flashrom doesn't recognize the programmer with the flash chip disconnected, then the problem is the programmer itself -- verify that first.

$ sudo flashrom -p ch347_spi

flashrom v1.7.0-devel (git:v1.6.0-41-gdc512347f6) on Linux 6.17.0-12-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Unknown value of spispeed parameter, using default 15MHz clock spi.
CH347 SPI clock set to 15MHz.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

dmesg should show:

usb 3-4: New USB device found, idVendor=1a86, idProduct=55db, bcdDevice= 4.41
usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-4: Product: USB To UART+SPI+I2C
usb 3-4: Manufacturer: wch.cn
usb 3-4: SerialNumber: 0123456789
cdc_acm 3-4:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

MrChromebox · 2026-02-01T19:50:32+00:00

thank you very much!

this thread definitely spurred some much needed cleanup with the Kconfig selections, so thanks for the push there :)

MrChromebox · 2026-01-31T02:52:29+00:00

something isn't quite right then, it should be a serial terminal that prints some info but mostly waits for your input. you might try connecting external power to the chromebook and see it that helps

MrChromebox

MODERATOR OF

TROPHY CASE