Skip to content

Applet management #56

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

Open
ia0 opened this issue Mar 23, 2023 · 0 comments
Open

Applet management #56

ia0 opened this issue Mar 23, 2023 · 0 comments
Labels
crate:cli Modifies the users CLI crate:scheduler Modifies the platform for:usability Improves users (and maintainers) life needs:design Needs design to make progress

Comments

@ia0
Copy link
Member

ia0 commented Mar 23, 2023

Applets are currently baked in the platform. Actually only one applet. It should be possible to bundle, list, install, uninstall, enable, and disable applets using the CLI.

Design questions (similar to #47):

  • Should applet management be enabled while applets are running? Should it only be possible when powering up while some button is pressed? Most options are probably useful and should be controlled by compilation flags.
  • Which transport should be used? This could be done in a generic way by the board API, providing some serial transport.
  • Which protocol should be used? (including bundle format)
  • When updating an applet, should the previous applet be preserved or overwritten? This should probably be controlled by a flag to the CLI: wasefire update --overwrite.
  • Should this relate with platform upgrade? In particular should it share the same transport (and protocol)?
  • How is the public key for bundle signature verification accessed by the platform? Baked at compilation? Installed during a one-time operation in factory?
  • Similar questions if bundles are not only signed but also encrypted.
  • There must also be a notion of applet identity which is stable across versions and a notion of applet version.
  • When modules need pre-computation (see Interpreter performance and footprint #46) and it is done at module installation and persisted to flash (possibly with Pre-compute the size in flash of a module #54), some integrity check needs to be persisted as well, since when the applet will execute, we don't want to validate it and its pre-computation. A checksum is faster. This check is required for security reasons (modifying the flash after module installation to change the module behavior).
  • Could use FAT/USB as protocol/transport using ghostfat. Most of the tooling would just be the file browser and file editors of the user. See Setup application loading via ghostfat embedded-wasm/platform-nrf52#1 for the idea.
  • See Applet zeroization #79. Applet resources should be wiped when uninstalled (similarly for dynamic resources when disabled).
  • See Applet watchdog #71. Applets should probably be killed if they don't do any syscall after a given amount of computing time.
  • See Debugging interface to inspect platform and applets #68. The management could also provide debugging facilities to inspect a given applet.
@ia0 ia0 added needs:design Needs design to make progress crate:cli Modifies the users CLI for:usability Improves users (and maintainers) life crate:scheduler Modifies the platform labels Mar 23, 2023
This was referenced Mar 23, 2023
ia0 added a commit to ia0/wasefire that referenced this issue Apr 8, 2024
It currently only contains applet RPC and platform reboot. It will eventually also contain applet
management google#56 and platform update.
ia0 added a commit to ia0/wasefire that referenced this issue May 3, 2024
It currently only contains applet RPC and platform reboot. It will eventually also contain applet
management google#56 and platform update.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crate:cli Modifies the users CLI crate:scheduler Modifies the platform for:usability Improves users (and maintainers) life needs:design Needs design to make progress
Projects
None yet
Development

No branches or pull requests

1 participant