Transactional multi-image update scheme

[nvlsianpu]

This tickets describes idea of Hight level update mechanism which uses common package description for maintains requirements of installation software parts. This mechanism takes advantage of already provided swap algorithms flow as lower layer algorithm scheme:
Objectives:

• fix images dependency management for more than 2 images.
• Introduce firmware package updated. Currently MCUboot threats images update independently (it only checks dependency meets).

New firmware package description metadata

Idea assumes introduction of new meta data entity for describe the multi-image package: firmware package description. This entity can be also called firmware manifest.
Role: describe firmware package requirements which can be run on the device.

transaction package description: Firmware package description which describes firmware package update requirements. Some of that requirements might be already meet by current package installed on the device, therefore partial update of multi-image firmware device is allowed.

current state package description: Currently installed firmware manifest.

Idea for location: the primary slot as part of the MCUboot’s trailer.

Requirements for manifest:

• Describes all firmware parts using either SHA or version requirements
• signed (so it can be authenticated)
• versioned (?)
• it’s format is versioned

Open question: Package description which is using versions is ambiguous. In case mcuboot will do transaction revert basing on package description then the result of that might be different than initial device firmware package:

• this might be expected behaviour
• this might be unwanted behaviour
  • revert record might help (optional)
  • revert record might be signed if such service is available (optional)
  • revert record attacks possible (see threat section)

High level workflow:

1.1. States: Firmware package is installed.

All of the firmware parts are in their primary_slots. The package firmware is described by state manifest located in the the trailer of the primary slot of the image-0 (the main_primary_slot). The package is confirmed using dedicated flag (transaction-OK) in the main_primary_slot.

Manifest should be store in location which is easy to be calculated by the application (use constant offset to the slot ending).

1.2. State: Request of update transaction.

This state is initialized by the application action. Application provides transaction manifest which is stored in the trailer of the main_secondary_slot allong with transaction-magic-word.

Implementation Requirements:

• Not used trailer space should be erased. This must be check by mcuboot.

1.3. State: Preserving of the current manifest

MCUboot preserves current manifest by storing it to the trailer in main_secondary_slot

this state entering requirements:

• images which are are described in the transaction manifest are valid

1.4. State: Preserving of the main_image ending (optional)

If transaction manifest doesn't require a new main_image version then the main_image will be kept as is.

There is possible that current main image ending reaches into the same sector in which the MCUboot’s trailer is stored. As the swapping process requires trailer page(s) erasing - need to store the ending in the secondary slot.

this state entering requirements:

• current main image reaches the flash page which is also the flash page where trailer is located.
• ending area in secondary slot is erased or can be corrected in order to store the ending

1.5. State: swapping the main_image body (optional)

During this state main_image gets swapped using available swap mechanism.

1.6. State: swapping the manifest

last operation is write of transaction manifest in place of current manifest. The current manifest become the Previous manifest and the transaction manifest become the new manifest. During this operation ending of main image might be erased - in that case it has to be restored from its copy in the main_secondary_slot.

1.7. State: swapping rest of images.

During this state MCUboot is looping on swapping the rest of images using available swap mechanism.

Each image become swapped if it is required in order to meet requirements expressed in the new manifest.

Once each image gets copied its copy-done flag is set.

open question: all of copy-done flash might be moved to the main_primary_slot

maybe that is sub-state?

1.8. State: test run

Once all needed images are moved MCUboot boots application for test. During this state the running application might confirm Firmware package by writing transaction-OK flag. By that transaction manifest become state manifest and any next boot will run installed image.

1.9. State: revert detection

If MCUboot found transaction done but without transaction-OK flag the need to revert the transaction.
Very first action is to set the revert flag in the main primary slot.

1.10. State: revert main_image body (optional)
If needed the main image body gets reverted in order to meet previous manifest requirement.

1.11. State: revert the manifest
Previous manifest is written back to the main_primary slot.

During this operation ending of main image might be erased - in that case it has to be restored from its copy in the main_secondary_slot. After that trailer in main secondary slot should be erased.

1.12. State: revert rest of images
During this state MCUboot is looping on reverting the rest of images using available revert mechanism.

Each image become reverted if it is required in order to meet requirements expressed in the new manifest.

Once each image gets copied its copy-done flag is set.

note: might be proceeded before reverting of the manifest as well

2. threat analyse

2.1 revert record attack (internal and external memory)

If revert record will be used it’s open a way to compromise the device by replacing its FW or damaged FW. If attacker can trigger the revert (power cycle the device is enough to do so).

Result might be:

installation of unintended package, possible with older component with vulnerabilities

bricking the device in unrecoverable state (DoS) as revert need is recognized but couldn’t fulfil requirement from the revert record or requirements are unavailable.

To perform attack on manifest the attacker must have write access to the memory where the revert record is located.

counteraction: protect access to the memory region where the revert record is store. This is almost impossible when revert record is stored in a external memory. Easy to achieved for internal SoC memory.
Especially in states for which the revert record exists, the MCUboot doesn't boot any application, so if any other actor hasn't access to the memory where it is stored, then the revert record doesn't introduce any additional surface for the attack.

counteraction: sign the revert record with secret key.

For a revert record which is copy of previous manifest which based on exact SHA's this protection is provided as-is by the manifest signature.

For run-time generated revert record this requires cryptography which is able to preserve secret signing key.

3. Other Ideas