Vboot support in the flashrom plugin

[Michał Kopeć]

Hello,

We (3mdeb) are exploring the possibility of enabling fwupd on a laptop with coreboot firmware with vboot verified boot. We are looking to use the flashrom plugin to do this.

Vboot mandates that the firmware (the BIOS partition defined in the IFD) be split into one or two read-write update slots and one read-only recovery partition. The partitions are defined in the FMAP (flashmap) which is already supported by fwupd and libflashrom from what I can gather.

Our laptop only has one RW slot. We would like to be able to flash only the RW slot in a similar manner that the plugin currently only flashes the BIOS region it detects from the IFD. It's already possible with functions from libflashrom: https://github.com/mkopec/fwupd/commit/3f1ddc4e9ac147d35befd9626595f15217b99780

We're not sure how to best integrate this. One way would be to add a quirk "has-vboot" or "has-fmap". Additionally, for proper dual RW slot support we would need to be able to detect the currently booted slot and flash the other slot. There is currently no way to get this data from the kernel. Maybe we could start by only supporting flashing Slot A or always flashing both slots.

I would appreciate your advice on how to proceed.

--

Pozdrawiam, / Regards,

Michał Kopeć
Junior Embedded C Developer
https://3mdeb.com/

[Richard Hughes]

On Thu, 16 Dec 2021 at 14:11, Michał Kopeć <michal...@3mdeb.com> wrote:
> It's already possible with functions from libflashrom: https://github.com/mkopec/fwupd/commit/3f1ddc4e9ac147d35befd9626595f15217b99780

Eww :)

> We're not sure how to best integrate this. One way would be to add a quirk "has-vboot" or "has-fmap".

Can we auto-detect the FMAP on the existing firmware? I'd rather
things "just work" without quirk entries if that's possible.

> Additionally, for proper dual RW slot support we would need to be able to detect the currently booted slot and flash the other slot.

Agree.

> There is currently no way to get this data from the kernel.

Could the kernel export this somehow? How does the kernel know?

Richard

[Michał Kopeć]

On 12/16/21 17:37, Richard Hughes wrote:
> On Thu, 16 Dec 2021 at 15:04, Michał Kopeć<michal...@3mdeb.com> wrote:
>> I think we could try reading the FMAP first and if it fails then try the IFD instead, but i think we'd have to be careful not to break things for existing users of the plugin.
> All, do we need to know if fmap is required on plugin startup? I
> assumed we only needed to know at write time.
|||I guess we don't need to know the the FMAP before write time,
indeed.| ||
>> On ChromeOS there's an utility that reads this information from the CMOS, but it doesn't work on non ChromeOS devices. I think it needs the chromeos_acpi driver to work.
> If the functionality is designed for ChromeOS devices then I've got no
> problem reading out values the same way.

|On Chromebooks Vboot parameters are exposed via ACPI. This table is
exposed by the Linux chromeos_acpi driver and parsed by the updater
(including currently active slot). For proper A / B updates we would
need to know which slot is active to be able to flash the other one. |

||

|There is a driver on coreboot's side that places the the necessary
information in ACPI tables but it is highly Chromebook-specific and we
can't use it on non-ChromeOS devices.|

||

|||The ChromeOS firmware updater additionally checks if we could boot
from that slot after a reboot, and if so, flashes the other slot
automatically.| ||
> Richard

--
Pozdrawiam, / Regards,

Michał Kopeć

Junior Firmware Developer
https://3mdeb.com/