Skip to content

Conversation

chrysn
Copy link
Member

@chrysn chrysn commented May 24, 2023

Contribution description

This adds support for SUIT manifest uploads to the rust-gcoap example.

Status

This is not quite complete, and may easily be moved in with the RIOT module demos, or more general CoAP abstraction components. Right now, as a PR it primarily serves to make #19601 better testable.

[edit: When this has stabilized a bit, I'd also review whether all the stacks need to be that much larger.]

SUIT implementation

This differs from what we have in the SUIT example (and the SUIT worker) in that this expects the manifest to be POSTed (blockwise, typically, due to the default message buffer sizes). This is IMO more aligned with SUIT because it doesn't turn devices into DDoS vectors when they fetch manifests.

Testing procedure

I haven't looked yet into how the SUIT makefile integration would need to be updated to automate this, so it's manual:

  • Have a riotboot flashed device; I'm using particle-xenon with riotboot-dfu
  • in examples/rust-gcoap, run make all riotboot/flash-slot0
  • Attach to the console to watch things or just to find the right address -- with the particle-xenon I'm going through CDC-ECM (but no matter the interface, you'll need an address).
  • Run make all suit/publish suit/notify SUIT_CLIENT='[fe80::a41b:b9ff:fe1f:894%enxa61bb91f1494]' SUIT_COAP_ROOT='coap://[fe80::25ed:8ab6:d530:ff10]' -- the SUIT_CAOP_ROOT needs to be a local address, as it is encoded in the manifest as a source of the remaining files. The SUIT_CLIENT doesn't actually matter -- the makefiles will POST the manifest address derived from the COAP_ROOT, but that'll fail due to the differences described above. (Still nice to find a 4.04 that tells us everything else works). This is run for the side effect of building both images and the manifest.
  • Have aiocoap-fileserver run in bin/particle-xenon/riotboot_files
  • Run aiocoap-client 'coap://[fe80::a41b:b9ff:fe1f:894%enxa61bb91f1494]/'suit -m POST --payload @bin/particle-xenon/suit_files/riot.suit.latest.bin --payload-initial-szx 2
    The command will return quite quickly (after sending about 7*64 bytes of manifest), then the worker thread will churn away as it downloads the full suitable manifest, flashes it and reboots.

@github-actions github-actions bot added Area: examples Area: Example Applications Area: OTA Area: Over-the-air updates Area: sys Area: System labels May 24, 2023
chrysn added a commit to chrysn/aiocoap that referenced this pull request May 24, 2023
This is not formally recommended in RFC 7959, but listed as a
quality-of-implementation consideration (and the effort is not undue on
this side, as the full request body is already available). Some
applications may require the size to be present (eg. [19659]).

[19659]: RIOT-OS/RIOT#19659
@chrysn
Copy link
Member Author

chrysn commented May 24, 2023

Brief side note: This does require the very latest version of aiocoap, as that used not to send Size1 (which is permissible, but the ad-hoc specification implied by this implementation is that Size1 is required, which is a valid requirement for an application to make).

chrysn added 4 commits May 26, 2023 17:04
This adds the suit_worker_try_prepare / suit_worker_trigger_prepared
pair for using the SUIT worker, and breaks suit_handle_manifest_buf out
of suit_handle_url (where the latter now calls the former).

As part of factoring out reaping of the zombie worker thread, a locking
error that deadlocks the SUIT worker in case the race between the mutex
being unlocked and the thread being reaped hits the necessary handling
code is fixed (and mutex_unlock is called in the error path).
Some modularizations is already started, but incomplete.
@chrysn chrysn force-pushed the rust-suit-update branch from f52189b to 400e13e Compare May 26, 2023 15:16
bors bot added a commit that referenced this pull request May 27, 2023
19601: SUIT: Prepared manifests r=chrysn a=chrysn

### Contribution description

While SUIT can generally be used already with manifests that are "dropped into memory" (by any mechanism), the convenient SUIT worker thread mechanism so far could not be used with it.

This adds the suit_worker_try_prepare / suit_worker_trigger_prepared
pair for using the SUIT worker, and breaks suit_handle_manifest_buf out
of suit_handle_url (where the latter now calls the former).

#### By-catch

As part of factoring out reaping of the zombie worker thread, a locking
error that deadlocks the SUIT worker in case the race between the mutex
being unlocked and the thread being reaped hits the necessary handling
code is fixed (and mutex_unlock is called in the error path).

### Testing procedure

SUIT tests should pass.

#19659 provides a demo of how the new API is used.

### Issues/PRs references

I think that the currently employed mechanism of having a resource to which a URL with the manifest gets posted is contrary to the design goals of SUIT -- the signed manifest should be what justifies the device to spend resources (eg. get data from a server), not a URI that is just *not* signed.

This PR makes it easier to implement a resource to which the manifest can be POSTed, rather than a CoAP URI that represents the manifest, as is proposed (but not mature) in 
#19659.

[edit: Adjusted to reflect decisions made during review]

Co-authored-by: chrysn <chrysn@fsfe.org>
lukgal-aa pushed a commit to lukgal-aa/aiocoap that referenced this pull request Jun 15, 2023
This is not formally recommended in RFC 7959, but listed as a
quality-of-implementation consideration (and the effort is not undue on
this side, as the full request body is already available). Some
applications may require the size to be present (eg. [19659]).

[19659]: RIOT-OS/RIOT#19659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: examples Area: Example Applications Area: OTA Area: Over-the-air updates Area: sys Area: System
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant