[Suit] On device resets during manifest processing

["Rønningstad, Øyvind" <[e-mail]>]

Hi
When implementing a SUIT manifest processor, it's essential to make sure that a power failure, or resets from other reasons, doesn't leave the system in a bad state.

In update procedures (fetch, install, process dependency), the "instructions" cannot be replayed. Or rather, certain procedures might be unrepeatable, for example with this sequence:

  1.  Copy from address 100 to 200
  2.  Copy from address 300 to 100

The final state will be erroneous if 1 is replayed after 2 has happened, since the source address 100 has changed. This means that the processor needs to non-volatilely cache its current state in some way, in case the chip is reset while processing the manifest.

The problem is that we can't know what the current state is. There might be some later instruction that relies on the state of a certain non-volatile memory location, but if a reset happens, that location is corrupted.

It's possible to construct command sequences that are impossible to properly guard against power failures, without caching the entire non-volatile memory component. For example:

  1.  Copy from component Foo (non-volatile) to component Bar (volatile)
  2.  Copy from somewhere to Foo
  3.  Copy from Bar to Baz (non-volatile)

If a reset occurs during 2 or 3, some or all of Foo will be overwritten, and Bar will be impossible to reconstruct, unless Bar has been cached in non-volatile memory between 1 and 2.

I think requiring all non-volatile components to be written to non-volatile memory when caching is not a viable solution. Rather, command sequences should be constructed in a way that, at most, the current parameter values and current instruction needs to be cached.

Even with well-constructed sequences, caching between every instruction is unnecessary, and would make it close to impossible to use volatile memory components as these always need to be re-initialized if a reset happens.

The best solution might be that the manifest author has to manually specify via a directive when the current state (current parameter values, current instruction) should be cached.

An alternative would be to always store at certain points, e.g. at the end of a sequence. This is awkward since it will interfere with the other reasons one has to group sequences in a certain way. This will also embed the decision of when to cache into the structure of the manifest, so there might as well be an explicit directive.

Another alternative is to say that all update procedures must be constructed in such a way that they are intrinsically safe from resets. This places the restriction that a component cannot serve as a copy destination after it has been a copy source, unless it was also a destination before it was a source. It also precludes the use of e.g. the swap directive (unless it has its own revert machinery). This will certainly be ok for a lot of applications, but may be too restrictive as a general rule.

(Certain directives like swapping and delta patching need their own internal state-saving in any case)

The final alternative is to have the manifest processor infer from the manifest which points it should perform caching at. This requires finding a simple and robust method of making this inference. It likely requires the manifest processor to be aware of when different memory components are used as copy sources, and also the lifetime of volatile components. This might become tricky if e.g. multiple component IDs refer to the same memory areas.

Regardless, I propose that we add some text about this in the manifest document, about the usage of volatile vs. non-volatile memory components, and procedures for recovering from resets. It might also make sense in the information model, if there is ever an update to that. Something like the following:

                THREAT.DEVICE.RESET: Forcing a reset of the device

                Classification: Tampering with data

                An attacker sends a valid update, then cuts power or otherwise forces a reset of the device while the update is being processed, leaving the device in an invalid state. Depending on how the manifest processor handles such resets, this could force unintended copying of data from a component that is in the wrong state, causing destruction of data, or booting or transmission of bad data.
All of this applies most strongly to the fetch, install, and process dependencies steps. The validate, load, and run steps already obviously need to handle device resets, but it might be good to mention that this includes resets that happen in the middle of any of the steps.

BR, Øyvind Rønningstad