Flashkeeper: a device that can be permanently installed on common SOIC-8/WSON flash chips.

It attaches to the chip either by being soldered or with a peel-and-stick layer and spring-loaded contacts/low-profile solder-down flex cable (solderless), interfacing with the SPI flash pins for easy PCH<->SPI introspection, write protection, and external reprogramming (unbricking).

For users concerned with physical attacks on their systems, for whom easy access to SPI flash pins may be seen as a risk, a variant including a microcontroller (MCU/FPGA) will also be developed, allowing authenticated external reprogramming and Write Protection (WP) control; independently verifying the SPI flash image/bootstream against a user-controlled detached signature of it at each boot, prior of the platform owner typing any requested secret leading to booting the Operating System (OS): trusting the state of the bootchain.

An Nlnet funded project.

Wyng-backup is now mature, supports a yet unchallenged encryption+authentication scheme, comes with a helper for Qubes metadata backup/restoration and supports BTRFS/LVM2 over LUKS.

This presentation will showcase my use cases:

• Through Qubes-SSH, with a USB multi-SSD drives adapter tray, turning test RPI5 into a powerful router + RAID5 controller for backup/restoration over QubesOS through networked WIFI/talescape/hidden onion service for small delta restoration when roaming.
• Remote cloud based, low cost of hosting, read-only accessible clean states without personal data stored. This use case could be moved forward and be enforced over firmware as a service: on a non-formatted internal SSD not being provisioned at all!

But the question remains: what do we really want?

Heads is a rolling release.

How to cope with so many downstream forks? What would be the ideal release process and interactions between forks and upstream?