-
Notifications
You must be signed in to change notification settings - Fork 2.1k
rust-gcoap: Add SUIT update endpoint #19659
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
chrysn
wants to merge
4
commits into
RIOT-OS:master
Choose a base branch
from
chrysn-pull-requests:rust-suit-update
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
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). |
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.
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
make all riotboot/flash-slot0
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.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.