Open
Description
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.