Microsoft bring an open-source model of Component Firmware Update (CFU) for peripheral developers

Microsoft announced an open-source model for Component Firmware Update (CFU), for Windows developers. CFU enables delivering firmware updates for peripheral components through Windows Update by using CFU drivers. This protocol aims to enable system and peripheral developers to leverage the CFU protocol. It allows them to easily and automatically push firmware updates to Windows Update for their firmware components.

CFU aims to bring smooth updates via Windows updates and verify the firmware version before download. CFU permits but does not specify authentication, encryption, rollback policies/ methods, or recovery of bricked firmware.

Overview of CFU

The CFU driver is the host and is created by the device manufacturer. It is delivered via a Windows Update. Then the driver is installed once the device is detected by Windows.

Primary and sub-components

A hierarchical system with a primary component and subcomponents is followed in a CFU compatible system. A primary component implements CFU on the device side and can receive updates for itself and the connected sub-components. A device may have multiple primary components with or without additional sub-components.

Offers and payloads

A CFU driver which is the host, may contain multiple firmware images for a primary component and its sub-components. A package in the host consists of an offer, a payload and other information. The offer contains information about the payload to allow the primary component in deciding if it is acceptable. A payload is the firmware image.

Offer Sequence

The primary component can accept, reject, or skip the offer of firmware update. On accepting, the payload is delivered immediately. On rejecting or skipping, the host cycles through all other offers in the list.

Host independence

The host’s (CFU driver) decisions are independent of the offers’ contents or payloads. It does not necessarily use any logic and simply sends the offers and the accepted payloads.

Payload delivery

On an offer being accepted, the host proceeds to download the firmware image or referred as the payload. Delivery is done in three phases—beginning, middle, and end. The payload is a set of addresses and fixed-size arrays of bytes.

Payload validation and authentication

Validation of the incoming firmware update is an important aspect. The primary component should verify bytes after each write ensuring that the data is stored properly before proceeding with the next set of data bytes. A CRC or hash should also be calculated on download, to be verified after the download is complete, ensuring the data wasn’t modified in transit.

In addition, a cryptographic signature mechanism is recommended to provide end-to-end protection. An encryption mechanism can also be employed for confidential downloads. On image authentication, the properties should be validated against the offer and other rules the device manufacturer may specify. CFU does not specify any rules to be applied.

Payload Invocation

The CFU Protocol is run at the application level in the primary component. The component can continue to do other tasks as long it can receive and store the incoming payload without significant disruptions. The only real disruption occurs when the new firmware must be invoked.

There are two recommended ways to avoid that disruption.

A very generic approach is to use a small bootloader image to select one of multiple images to run when the device is reset. This is typically at boot time. The image selection algorithm is specific to the implementation. It is typically based on an algorithm which involves code version, and an indication of successful image validation.

Another invocation method is to physically swap the memory of the desired image with the active address space. This is done upon reset. A disadvantage of this method is that it requires specialized hardware. The advantage being all images are statically linked to the same address space eliminating the need for a bootloader.

CFU limitations

There are some limitations of the protocol.

It cannot update a bricked component that can no longer run the protocol.

CFU does not provide any security.

The CFU protocol requires extra memory to store the incoming images which helps in non-disruptive updates.

Updating sub-component images larger than the component’s available storage requires dividing the sub-component image into smaller packages

The CFU protocol allows pausing the download, so care needs to be taken for proper validation.

CFU assumes that the primary component has set validation rules. If they need to be changed, the component must first be successfully updated by using the old rules first, only then new rules can be applied.