pub struct SecMem<S: Zeroize> { /* private fields */ }sec_mem only.Expand description
A hardware-accelerated secure memory container for isolating sensitive data from the OS.
SecMem uses raw Linux syscalls (mmap, mprotect, mseal, mlock) and Intel Memory Protection Keys
(MPK/WRPKRU) to physically isolate cryptographic keys or passwords from the rest of the process.
It strictly guards against buffer overflows via msealed guard pages, and actively prevents memory
dumping using MADV_DONTDUMP, MADV_DONTFORK, and PR_SET_DUMPABLE(0).
When the encryption feature is enabled, data is permanently XOR/ChaCha20 blinded at rest in RAM,
mathematically neutralizing /proc/self/mem exploit attempts or physical cold-boot attacks.
§Examples
use sec_mem::SecMem;
// Create a highly protected memory vault
let mut secure_key = SecMem::new([0xAAu8; 32]);
// Access is granted exclusively within this closure bounds
secure_key.access_mut(|key| {
key[0] = 0xBB;
// Data is processed here...
});
// Instantly upon closure exit, memory is zeroized, re-encrypted, and hardware-locked.Implementations§
Source§impl<S: Zeroize> SecMem<S>
impl<S: Zeroize> SecMem<S>
Sourcepub fn access_mut<F, R>(&mut self, f: F) -> R
pub fn access_mut<F, R>(&mut self, f: F) -> R
Access secret for mutation
Sourcepub fn constant_time_eq(&self, other: &Self) -> Choice
pub fn constant_time_eq(&self, other: &Self) -> Choice
Constant-time equality comparison
Sourcepub fn seal_guard_pages(&self)
pub fn seal_guard_pages(&self)
Explicitly applies Linux memory sealing (mseal) to the guard pages.
WARNING: mseal permanently locks the memory region’s permissions.
Because Linux prevents munmap on sealed memory, calling this method
means the guard pages (and thus the allocation) will leak and remain in RAM
until the process terminates. It should only be used for global, long-lived
singletons (like root application keys).
Requires Linux 6.10+. Fails silently on older kernels.