designs: firmware_update_via_blobs: Add notion of cleanup blob
Add the notion of a cleanup blob id that is present. This was invented
as a convenience mechanism for wiping the BMC's update artifacts on
failure. On memory constrained systems, having a 32MiB file sitting in
the RAM FS is wasteful on failure. One can simply reboot the BMC to
address this, and therefore this blob is only a convenience.
Deleting the artifacts on failure is not a default behavior because they
are meant to be harmless. This also allows a developer to use unsigned
images if they want without requiring a different update mechanism. The
developer would require console access, but with that access could flash
the "invalid" image if they chose.
Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Ie1bc184d24295ed61fd8be8fd48fb50c205235ac
diff --git a/designs/firmware_update_via_blobs.md b/designs/firmware_update_via_blobs.md
index c7cc9ea..f6cf89e 100644
--- a/designs/firmware_update_via_blobs.md
+++ b/designs/firmware_update_via_blobs.md
@@ -145,6 +145,29 @@
The update process used is not defined by this design.
+#### Cleanup Blob
+
+The cleanup blob id is always present. The goal of this blob is to handle
+deletion of update artifacts on failure, or success. It can be implemented to
+do any manner of cleanup required, but for systems under memory pressure, it is
+a convenient cleanup mechanism.
+
+The cleanup blob has no state or knowledge and is meant to provide a simple
+system cleanup mechanism. This could also be accomplished by warm rebooting
+the BMC. The cleanup blob will delete a list of files. The cleanup blob has
+no state recognition for the update process, and therefore can interfere with
+an update process. The host tool will only use it on failure cases. Any other
+tool developed should respect this and not employ it unless the goal is to
+cleanup artifacts.
+
+To trigger the cleanup, simply open the blob, commit, and close. It has no
+knowledge of the update process. This simplification is done through the
+design of a convenience mechanism instead of a required mechanism.
+
+Cleanup Blob | Note
+---------------- | -------------------------
+`/flash/cleanup` | Trigger Cleanup Mechanism
+
### Caching Images
Similarly to the OEM IPMI Flash protocol, the flash image will be staged in a