Considerations about moving from FUM to Capsule Updates

[krystian-hebel]

Everything noted here is up to discussion, and thus it may not represent the final chosen solution.

Both mechanisms fulfill similar role - they are used to update the firmware. Supporting and testing both in all possible configurations takes a lot of time, and requires multiple reflashes for each tested binary.

It was suggested that FUM (as an entry in setup menu) should be retired now that we have support for capsule update. FUM itself can't be disabled because capsule update uses it's logic to disable flash write protections in order to perform the update, but it may be hidden from the user to avoid the confusion.

Current state

Currently, the configuration options for those are spread throughout multiple menus: settings related to capsule updates are located in Generic Drivers, core FUM and setup menu option - in Chipset, and auto-update sequence in FUM - in Payloads. This diagram depicts the current state, together with default values, if set:

Proposed transitional solution

In this solution, FUM was split into two separate options: core FUM functionality and another option to show it in the UEFI setup menu. Core FUM is no longer an option that can be manually selected in the menuconfig, instead it is automatically selected when either menu option or capsule update gets enabled. Menu option and capsule updates are mutually exclusive. Auto-update sequence in FUM is enabled by default for all platforms except Protectli, which is caused by Protectli platforms having custom iPXE menu.

This allows for switching to capsules one platform at a time, to not block the transition in case there are unpredictable problems for some of them, or justified requests from a client not to do so.

Final state

After the last platform has switched to capsule update, the right part of the diagram (FUM option in menu and auto-update) can be removed.

Impact on end users

• No FUM entry in UEFI setup menu. Manual flashing requires disabling all protection mechanisms manually.
• Capsule update flow doesn't change.

Approximate list of tasks

Initial tasks:

• edk2: split FUM and menu option to use separate variables.
• coreboot: move Kconfig options around to get to the transitional state, update edk2 Makefile accordingly, modify defconfigs as needed.

Per-platform:

• coreboot: switch from FUM to capsules by modifying platform defconfig.
• Run tests.

After final platform switches away from user-selectable FUM:

• edk2: remove code for displaying FUM entry.
• coreboot: remove Show FUM option and Auto-update sequence in FUM from Kconfig and Makefile.