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

[Brendan Moran <[e-mail]>]

Hi Sylwester,

I think I haven't been completely clear on this. Please see my comments inline.

Best Regards,
Brendan

On Wed, Jan 17, 2024 at 7:23 AM Kończyk, Sylwester
<sylwester.konczyk=[e-mail]> wrote:
> To make sure I understand your examples - When you are mentioning "System Validation sequence" - are you referring to SUIT_Command_Sequence suit-validate? In case of "load sequence" mentioned in your last post - does it refer to SUIT_Command_Sequence suit-install?  As I understand, the trick would be to execute suit-validate twice, first time - prior to suit-install, second time, in invocation procedure, prior to suit-load.

[BM] For lazy installation, I am referring exclusively to the elements
of the Invocation Procedure.
By "System Validation sequence," I meant suit-validate.
By "load sequence," I meant suit-load.

Suppose there is a device that has a staging area (Component ID
["Staging"]) and an active firmware (Component ID ["Active"]). A
manifest (JSON-style) that would satisfy your needs is as follows:

{
    "suit-authentication-wrapper" : "omitted",
    "suit-manifest" : {
        "suit-common": {
            "suit-components" : [
                ["Staging"],
                ["Active"]
            ],
            "suit-shared-sequence" : [
                "suit-directive-set-component-index", 0,
                "suit-directive-override-parameters", {
                    "suit-parameter-image-digest" : "<Staging image digest>"
                },
                "suit-directive-set-component-index", 1,
                "suit-directive-override-parameters", {
                    "suit-parameter-image-digest" : "<Installed image digest>"
                }
            ]
        },
        "suit-payload-fetch" : [
            "suit-directive-set-component-index", 0,
            "suit-directive-override-parameters", {
                "suit-parameter-uri" : "https://suit.example/lazy-install.bin"
            },
            "suit-directive-fetch", 2,
            "suit-condition-image-match", 2
        ],
        "suit-validate" : [
            "suit-directive-set-component-index", 1,
            "suit-directive-try-each", [
                [
                    "suit-directive-set-component-index", 1,
                    "suit-condition-image-match", 2
                ],
                [
                    "suit-directive-set-component-index", 0,
                    "suit-condition-image-match", 2
                ]
            ]
        ],
        "suit-load": [
            "suit-directive-set-component-index", 1,
            "suit-directive-try-each", [
                [
                    "suit-condition-image-match", 2
                ],
                [
                    "suit-directive-override-parameters", {
                        "suit-parameter-source-component" : 0
                    },
                    "suit-directive-copy", 2,
                    "suit-condition-image-match", 2
                ]
            ]
        ],
        "suit-invoke":[
            "suit-directive-set-component-index", 1,
            "suit-directive-invoke", 2
        ]
    }
}

As you can see, each time the device boots, the bootloader uses
suit-validate to check whether EITHER the active image is correct OR
the staged image is correct. If EITHER condition is true, then it
proceeds to suit-load. During suit-load, the manifest directs the
bootloader to determine whether the active image is correct. If it is
not, the bootloader (having already verified that the staged image is
correct) copies the staged image into the active image component. Once
the copy is finished, the bootloader verifies that the active image is
correct. Then, it proceeds to suit-invoke. suit-invoke simply invokes
the active image, having already verified that it is correct.

>
>
>
> Logical steps, applying “lazy installation” on examples from my post would look like:
>
> 1.            Staging procedure carried out by the APP.
>
>                 - suit-dependency-resolution
>
>                 - suit-payload-fetch
>

[BM]: Step 2 not needed.

> 3.            Invocation procedure carried out by the BL.
>
>                 - suit-validate
>
>                 - suit-load
>
>                 - suit-invoke

... SNIP ...

>
> Getting to conclusion - both solutions ("lazy installation" and introduction of suit-pre-install-validate) would work. The only question is what is simpler, or rather what kind of simplicity should be sacrificed:
>
> Having two dedicated validation sequences - in that case existing specification shall be extended.

[BM]: The specification would be slightly more complex. I don't know
if it is enough additional complexity to be an issue. The bigger
problem is that suit-install could exist in one of two procedures.
This leads to some implementation challenges that I find quite
concerning. Changing this requires a change to the Manifest
Specification. It seems that it would be safer to add two sequences:
one pre-install-validation sequence and a separate,
post-validation-install sequence, then group both of these in a
separate procedure--would these new sequences be severable? I would
assume so since they are not needed once installation has completed;
that said, they should be minimal in size, which makes the value of
severing them questionable.

> Adding extra logic to suit-validate and execute it twice - it will require a more complex content of suit-install.

[BM]: As I described above, suit-install is not executed twice.
suit-load is used instead.

>
>
> Obviously, I would prefer to have dedicated suit-pre-install-validate at disposal. I see following benefits of such approach:
>
> Having clear separation of two concerns - validation prior to installation and validation prior to invocation. I would be glad to have similar clarity as it is already achieved for invocation procedure and three available command sequences.
> Simplified logic in appropriate sequences, causing that definition (creation) of manifest would be less error prone.
> suit-pre-install-validate could be severed after installation, therefore space reserved for installed manifest could be smaller.

[BM]: As described above, suit-load is for loading images into their
executable locations, post validation. While suit-load can be used for
loading into volatile RAM, it can also be used for loading into NVRAM.
This seems to be your use case.

My big question is whether you see sufficient semantic difference,
between this type of loading operation and a discrete installation
step, that we would require a whole new procedure. I'm definitely open
to that, I just want to be sure we have covered the alternatives
first.