Raspberry Pi implementation of the boot protocol should be a standalone process
I'm trying to re-think how de-couple several components in SysOTA. Currently there are three pieces living inside one process, where it is very convenient to do certain things, which contribute to the problem of "big fat daemon". Those are:
- The adapter between RAUC and boot protocol implementations
- The NetOTA-aware check&apply layer
- The implementation of the Raspberry Pi boot protocol
The first part is responsible for adapting boot protocols, a SysOTA concept, to work with RAUC. It is also a participant of the update and rollback system and needs to interact with RAUC boot and install handlers. I think this is the last element to be split out. This part has minimal state (boot mode) and configuration (boot protocol to use).
The second part is the topmost layer which is aware of NetOTA and uses its APIs as a library. This part contains both configuration and state.
The last part, is the precise piece of code which integrates with the Raspberry Pi bootloader. This part is stateless, except for the state of the boot system itself and needs one piece of configuration: the location of the boot partition mount point. It also has one required input: the location of the directory which contains boot assets, relative to the system image inside RAUC bundles.
I think the last element is the first one to be split out. Here's why:
-
This element doesn't have any state unique to itself that is not inside the boot partition. This is actually good, as all it needs from the outside is to drive the boot configuration system in an appropriate way. It is also privileged in the sense that it requires access to the boot partition. This allows putting precise sandbox and hardening around this component and to restrict access to the boot partition to the rest of the services.
-
We already have a D-Bus bridge that exposes all boot protocol methods over D-Bus. This makes it natural to replace the existing in-memory calls inside the RAUC adapter with D-Bus calls. This would allow pi-boot to be a standalone program, with different bus name. This would also allow us to specialize a device by installing a specific implementation of the boot protocol implementation, removing one of the elements of the current configuration system.
-
It would allow 3rd party boot protocol implementations to exist and now need to use Go.
The exact interface could be one of D-Bus or sub-process handler. That remains to be explored.