Hacker News Reader

Comment by verbatim | Hacker News Reader

This article doesn't seem to explain why they have a hard dependency on a proprietary tool to flash the firmware.

There are no alternatives to AFUEFI?

I am the engineer at System76 that has been working on the low-level firmware update procedure.

The only alternative is to reverse engineer the SPI flashing method. We have switched to using FPT, the Intel Flash Programming tool, on new models. This means that we need to reverse engineer the SPI update method, which is something the flashrom project has had success in doing for older Intel chipsets.

SPI is a standard, right? What is the problem in using SPI?

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.

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

Kaby Lake and Kaby Lake R, for example

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.

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.

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

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.

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

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

Can’t you add a bit of code to your firmware to accept a special EFI capsule that’s really just an EFI program (or a firmware volume containing an AFUEFI and the payload)? This wouldn’t work for UpdateCapsule, but it should work as a UEFI 2.4+ capsule-on-disk.

If fwupd won’t support a capsule-on-disk, I personally volunteer to nudge them. But I bet they already support it or would be very willing to add support.

Based on there comments in the article, I'd say that was their conclusion:

    There is no other way to interpret this email other than LVFS won’t work well for us. UpdateCapsule is not supported by over a decade of machines in the field and could not be added without a firmware update.

Please don't use code blocks for quotes. This is truncated and unreadable on mobile. Just use a normal paragraph with a ">" prefix.

Reply on news.ycombinator.com