-
Notifications
You must be signed in to change notification settings - Fork 204
Composefs Backend Garbage Collection #1699
-
In a talk with @travier about what we should consider to be the source of truth while performing a gc operation - the repository or the bootloader entries.
The crux of the issue is that the bootloader partition is unencrypted and unverifiable, so a malicious actor can, in theory, make changes to the bootloader entries in such a way that we end up gc-ing stuff we're not supposed to (this is if we consider the bootloader entries to be the source of truth). So, ideally we'd only want to rely on the bootloader entries for order of deployments and nothing else.
On the other hand, considering the repository as the source of truth is not quite feasible as during a deployment deletion we want to get rid of the bootloader entries first as we wouldn't want to boot from an entry that is in some inconsistent state due to the delete operation being interrupted.
The scenario
Delete op is interrupted just after bootloader entry deletion, but before GC op is performed on the repository
When we want to perform a GC op in the future, we must find the diff between the ESP/boot state vs what we actually expected the state to be from the repository. This approach would work quite well
In practical terms, during a GC run:
- Query the composefs repository for all known deployment entries (i.e. the present EROFS images)
- Enumerate existing bootloader entries
- Compute the diff
- For any entry found only in the repo but not in the bootloader entries, we mark it for GC
Hopefully I didn't miss anything crucial
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
Replies: 2 comments 1 reply
-
The crux of the issue is that the bootloader partition is unencrypted and unverifiable, so a malicious actor can, in theory, make changes to the bootloader entries in such a way that we end up gc-ing stuff we're not supposed to (this is if we consider the bootloader entries to be the source of truth). So, ideally we'd only want to rely on the bootloader entries for order of deployments and nothing else.
We must have the booted system's composefs digest (from the kargs) as a fixed GC root and we won't prune its content, regardless of what we find in the BLS entries. i.e. even if we're missing a BLS entry for the booted due to corruption/attack, we won't delete files backing the running OS.
For non-booted AFAICS the worst that could happen is that a deployment is missing some backing files right?
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
I missed the point in the original post. Basically, we wouldn't want to trust the bootloader config files themselves. Instead, what we'd ideally do, is compute the current state of the repo vs the state found in ESP/boot.
For non-booted AFAICS the worst that could happen is that a deployment is missing some backing files right?
We could end up deleting the state directory which would make the entry unbootable. And yes, we'd never GC anything related to currently booted entry.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
We know what state directory we booted from and so know not to delete it right?
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1