[jackpot51]

SPI is easy, and well understood. For firmware editing I often use an external flasher for updating the ROM, and use flashrom to do so. Accessing the SPI bus on the Intel chipset, from the computer itself, is undocumented and usually requires reverse engineering.

[monocasa]

Which chipset? It was documented (albeit not super well) in the handful of Intel chipsets I've had to support for firmware updates.

[jackpot51]

Kaby Lake and Kaby Lake R, for example

[monocasa]

OK, neat, it looks like they haven't changed it in eons. It's PCI device 00:1f.5 and is documented in all of the PCH docs (so Vol 1 for overview, Vol 2 for registers). Sometimes it's disabled by firmware as a sort of 'security' mechanism.

Yeah, there's not a whole lot there in the docs, but it's PIO SPI that handles most of the flash addressing for you, so it's not the most complex thing in the world to begin with. More "fill the buffer and go" sort of deal.

[amluto]

But, if your firmware cares about preventing flashable rootkits, then these registers should be locked such that you can only flash from SMM or during initial boot. The fact that AFUEFI works at all on a System76 laptop is a bad sign IMO.

[jackpot51]

It absolutely is locked, and needs to be unlocked and flashed while in EFI mode.

[amluto]

What do you mean “in EFI mode”? Do you mean EFI Boot Services or something else? I’m trying to understand what makes AFUEFI special that causes it to be able to write the SPI flash when regular software can’t. If I understand your blog post right, AFUEFI run like any other .efi program, which seems insufficiently locked down to me.

[jackpot51]

That is good to know. We will also need to unlock the flash descriptor, which is more proprietary code to reverse engineer.

[monocasa]

For just doing updates, you shouldn't have to (or be able to) touch the flash descriptor, AFAIK. It's fixed at manufacturing time (without touching the flash with an external programmer of course).