| Crates.io | sed-key |
| lib.rs | sed-key |
| version | 0.1.5 |
| created_at | 2025-09-22 20:53:13.05116+00 |
| updated_at | 2025-11-12 03:45:01.274751+00 |
| description | Tool + library for controlling NVMe SED/OPAL lock states on Linux |
| homepage | https://github.com/daveman1010221/sed-key |
| repository | https://github.com/daveman1010221/sed-key |
| max_upload_size | |
| id | 1850621 |
| size | 99,204 |
sed-key is a Rust command-line tool and reusable library for locking, unlocking, and querying the lock state of NVMe Self-Encrypting Drives (SED) using the TCG OPAL protocol under Linux.
It’s intentionally minimal — ideal for early-boot or recovery environments — and supports both direct CLI use and programmatic invocation from other Rust code.
It wraps the Linux ioctls for OPAL discovery and lock/unlock, providing:
OPAL_LOCK_UNLOCK command with your Admin1 password.sed-key binary to view lock status or unlock drives interactively.do_lock, do_unlock, or do_status directly from your own code.--features real-hardware for integration on test drives.This software talks directly to your block devices using raw IOCTLs.
Mistakes can lock you out of your drive, or even crash a running kernel.
You run this at your own risk.
With Cargo:
cargo install sed-key
sudo sed-key status /dev/nvme0n1
This prints the parsed OPAL locking feature flags and whether the device is locked.
Pass the device path and optionally a password argument:
sudo sed-key unlock /dev/nvme0n1 mypassword
Similarly, to lock the device:
sudo sed-key lock /dev/nvme0n1 mypassword
All commands exit with nonzero on error so you can use them in shell scripts:
# Example: unlock with key from a file if the drive reports locked
if sudo sed-key status /dev/nvme0n1 | grep -q "LOCKED"; then
sudo sed-key unlock /dev/nvme0n1 "$(cat /etc/keys/nvme0n1.key)"
fi
# Or perhaps:
# Use sed-key directly; password piped on stdin
if ! echo -n "$PW" | sed-key unlock "$dev" -; then
rc=$?
echo "ERROR: unlock failed for $dev (rc=$rc)" >&2
exit $rc
fi
All tests run safely without touching hardware by default:
cargo test
Property-based tests and regression corpus ensure deterministic runs.
For real hardware tests, explicitly enable:
cargo test --features real-hardware -- --ignored
Required environment:
export SED_KEY_TEST_DEV=/dev/nvme1
export SED_KEY_TEST_PW=mysecret
Never run these on a mounted or production drive.
When running under Miri or in CI, hardware IOCTLs are replaced by a fabricated discovery page. Example:
MIRI_SED_LOCKED=1 cargo miri run -- status /dev/nvme0n1
This lets the parser and property-based tests run without touching real drives.
If you have Rust installed, you can build and run directly:
git clone https://github.com/daveman1010221/sed-key.git
cd sed-key
cargo build --release
If you have Nix installed with flakes enabled:
git clone https://github.com/daveman1010221/sed-key.git
cd sed-key
nix build .#default
This Nix build performs a fully offline, reproducible release build of sed-key.
use sed_key::{do_status, do_unlock, use_mock_backend};
fn main() -> anyhow::Result<()> {
use_mock_backend();
do_unlock("/dev/nvme0".into(), Some("pw".into()))?;
do_status("/dev/nvme0".into())?;
Ok(())
}
This allows scripting or testing drive control directly from Rust code.
Licensed under MIT.