TrustQuorum needs secret removal from memory when not in use

Open
#9,815 0 comments 0 reactions 1 assignee View on GitHub

@plaidfinch is already working on this.

Since Feb 13, 2026.

Assessment

This issue has not been assessed yet.

Description

trust quorum

There are two instances of when the rack secret (latest or prior epoch) is retrieved from the trust quorum NodeTask. Both occur as part of sled-agent reconciliation:

  1. A disk is being ensured and a key is being loaded as part of startup of the sled, or insertion of a new disk
  2. A new trust quorum configuration has committed and the keys for all disks need to be rotated.

In both cases, the current rack secret and all decrypted prior secrets are loaded from disk and cached in memory. There is a NodeTaskHandle::clear_secrets mechanism for removing those secrets when the caller utilizing KeyManager is done with them. Unfortunately, this method is not called. Additionally, the KeyManager itself caches the derived keys used for disk encryption and provides a clear method for those. This method is also not currently used.

We need to ensure that we limit the window that both the rack secrets and derived keys live in memory in case an attacker can read memory. Ideally we would be able to do this with RAII via Drop. Unfortunately, there is no async drop.

The simplest thing to do is to spawn a task that will call clear after a timeout for both caches. However, this still leaves a window between how long we actually need the keys for and the remainder of the timeout. A timeout of 5 minutes is probably (very much) long enough to prevent not being able to load and read the keys. Note that even if the keys are cleared, they can immediately be requested again, it just results in share exchange and rederivation.

In between the ideal of an async drop and the backstop of a timeout, is a mechanism to actually call the clear methods when we are done with them. We should do both that and the timeout.

Dominant language
Rust
Stars
572
Forks
97
Avg merge
2d 12h
Merged PRs (30d)
96

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from oxidecomputer/omicron

All issues in oxidecomputer/omicron

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.