feat(storage): per-app/owner/system encryption live: gatekeeper hands seed + fresh flag, storage unlocks layer, init seeds areas from factory/ (empties on new key); rmdir op; test-qemu checks sealed home + reboot persistence
This commit is contained in:
10
docs/ipc.md
10
docs/ipc.md
@@ -97,8 +97,14 @@ gatekeeper (`types::gatekeeper`), handing it only the terminal, the keystore
|
||||
(a small disk of its own, told from the data disk by its size) and the
|
||||
virtio-rng device. Init calls `UNLOCK`, which returns once the owner is in,
|
||||
then `KEY`, whose reply is the master key; init passes it to storage
|
||||
(`SET_KEY`, from the unbadged holder only, each half once) and only then
|
||||
starts the permission manager and the desktop. If the gatekeeper cannot
|
||||
(`SET_KEY`, from the unbadged holder only, each half once), and a fresh
|
||||
32-byte seed (`SEED` → `SET_SEED`) for storage's randomness this boot.
|
||||
Storage's encrypted areas (`home/`, `system/`, each app's `data/<id>/`;
|
||||
crate `filecrypt`, layer `storage_server::encrypted`) open once both are
|
||||
in. With a new key (a fresh device, or one just wiped: `UNLOCK`'s word 1)
|
||||
init empties those areas and seeds them from the plaintext `factory/`;
|
||||
an area that is missing is seeded too. Only then does init start the
|
||||
permission manager and the desktop. If the gatekeeper cannot
|
||||
unlock, init stops there. The gatekeeper exits, and its capabilities go
|
||||
with it.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user