Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence

["Kończyk, Sylwester" <[e-mail]>]

Hi Michael,

> Does this mean that there is an APP_A slot, and an APP_B slot, and also a "running" slot, or are you referring just to the manifest here?

Referring to your question (related to Example 2) - Purpose of that example is to demonstrate one of possible implementations of "stream-to-secure" approach mentioned by Brendan and justify that even in that case we can observe distinct staging, installation, and invocation procedures.

In this specific example - one of APP_* slots is active (or "running") at specific moment, APP_A here. APP_B is not running at that time, so overwriting its content at step 1d is feasible. Both APP_* are represented as distinct components in manifest. For sake of simplicity, slot for the manifest itself is not directly mentioned in this example, however moment when "candidate" manifest is stored in device non-volatile memory is reflected in step 2d.

BTW - someone may claim that "stream-to-secure" should be implemented similarly to "A/B Image Template", draft-ietf-suit-manifest-24. Unfortunately, that approach has its own issues, limiting its applicability in systems I am aware of. I will not elaborate it here, as it is a separated topic. 

With Regards,

Sylwester

-----Original Message-----
From: Michael Richardson <[e-mail]> 
Sent: Friday, December 22, 2023 4:06 PM
To: Kończyk, Sylwester <[e-mail]>; Brendan Moran <[e-mail]>; [e-mail]
Subject: Re: [Suit] draft-ietf-suit-trust-domains: proposal of new command sequence


Kończyk, Sylwester wrote:
    > Example 1:
    > Example 2:

    > System similar to one described in Example 1, but there are two slots
    > for the APP. Name it: APP_A and APP_B. And let's bring SUIT manifest to
    > the picture. Staging area is still there, but its size is reduced, just
    > to hold candidate manifest (an envelope, without integrated payloads).
    > Let's assume that initially the app is booted from APP_A, so APP_A is active.

    > Would you agree that following flow correctly describes logical steps:

    > 1.  Staging procedure is carried out by the APP (precisely - APP_A).
    > *   APP_A downloads candidate manifest to staging area.
    > *   APP_A verifies signature of the candidate manifest.
    > *   APP_A verifies applicability of the candidate manifest.
    > *   APP_A downloads APP_B image directly to APP_B slot (executing instructions encoded in candidate manifest)
    > 2.  Installation procedure is carried out by the BL.
    > *   BL verifies signature of the candidate manifest.
    > *   BL verifies applicability of the candidate manifest.
    > *   BL verifies APP_B (executing instructions encoded in candidate manifest)
    > *   BL overwrites currently installed manifest with candidate manifest
    > (only if previous step is successful).

Does this mean that there is an APP_A slot, and an APP_B slot, and also a "running" slot, or are you referring just to the manifest here?

    > Example 3:

    > More complex, yet still memory - constrained system. BL, APP_A, APP_B,
    > staging area, but additionally another non-trusted environment, this
    > time for the Radio. Name it - RAD. And we have extra requirements -

:-)

I read your entire email, and it all made sense to me.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide