fw: Persistent storage syscalls

[mchack-work]

Placeholder! Please fill in.

Implement persistent storage syscalls:

1. Retrieve information about if the device app has an allocated storage area or not.

2. Allocate or deallocate a storage area. The FW shall return status indicating if the allocation was successful or not.

3. Perform read or write operations of data to the allocated storage area.

(Cut from investigation report.)

A list of current syscalls:

    BLAKE2S = 0,
    ALLOC_AREA,
    DEALLOC_AREA,
    WRITE_DATA,
    READ_DATA,
    ERASE_DATA,
    PRELOAD_STORE,
    PRELOAD_STORE_FINALIZE,
    PRELOAD_DELETE,
    MGMT_APP_REGISTER,
    MGMT_APP_UNREGISTER,

Implement support for a device manager application with more priveleged access to flash.

[dehanj]

Unimplemented features and/or open questions

• USS for a preloaded app. The preloaded app should be able to use the USS. The USS then needs to be stored in the partition table, in order for the pre-loaded app to be able to start up without a user supplying the USS on every boot. It could also mean an option to enable that a user has to supply the USS at each boot. This is still an open question. How do we securely store the USS in flash?

• Auto start of a pre-loaded device app 1) auto-start (unless a cmd comes), 2) Wait for cmd, either start pre-loaded or load another app. Can be configurable when installing a pre-loaded app.

• App digest from device to client when installing a pre-loaded app

• Management app privileges How much power should the management app have? In the current PoC it can only register/unregister itself and store/delete a preloaded app. Should it be able to 1) erase arbitrarily storage area? 2) manipulate the partition table? 3) "Factory reset"? 4) Access the entire storage?

Some of these might be useful if someone wants to completely erase the storage or have forgotten the USS to an app that has an allocated area.

• Redundancy of the partition table in flash Write to alternative pages, if something goes wrong during a write it is possible to restore to the previous and only the "latest" change is lost.

• The glue between the hardware and firmware, regarding syscalls, syscall wrappers etc. High probability that the current PoC implementation could change.