Martin's Blog

Secure Allocation of Memory: A 2025 Update

Introduction

In 2002, secure memory allocation meant calling mlock() and hoping keys didn’t land in swap. Today it involves hardware-encrypted RAM, CPU-isolated enclaves, and defenses against attacks that didn’t exist 20 years ago—speculative execution exploits, Rowhammer bit-flipping, and memory bus interposers costing under $100. This post examines the current state of the art for protecting sensitive cryptographic material in memory, covering OS APIs, hardware technologies, modern crypto library approaches, and the new attack landscape.

The 2002 Baseline Versus Today’s Reality

The original 2002 article focused on mlock() preventing swap writes, avoiding core dumps, and zeroing memory on free. Those fundamentals remain relevant, but the threat model has expanded dramatically. Cold boot attacks demonstrated in 2008 showed that DRAM retains data after power loss [1]. Spectre and Meltdown in 2018 revealed that CPUs leak secrets through speculative execution [2]. Rowhammer variants continue to emerge—the Phoenix attack achieved root privilege escalation on DDR5 systems in 109 seconds during 2025 research [3].

The good news: hardware vendors responded with transparent memory encryption (Intel TME, AMD SME), per-VM isolation (Intel TDX, AMD SEV-SNP), and OS developers added stronger APIs. Linux kernel 5.14 introduced memfd_secret(), which removes pages entirely from kernel address space—the kernel literally cannot read your secrets even if compromised [4].

Modern OS Memory Locking APIs

Linux: mlock() Evolved and memfd_secret() Arrived

The mlock() family gained the mlock2() syscall in kernel 4.4 with the MLOCK_ONFAULT flag, allowing pages to be locked only when first accessed rather than immediately [5]. This improves efficiency for sparse allocations. The default unprivileged RLIMIT_MEMLOCK remains modest (typically 64KB), but processes with CAP_IPC_LOCK have no limits [6].

The most significant development is memfd_secret(), added in kernel 5.14 and enabled by default since 6.5 [4]:

1int fd = syscall(SYS_memfd_secret, FD_CLOEXEC);
2ftruncate(fd, secret_size);
3void *secret = mmap(NULL, secret_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

This creates anonymous RAM-backed memory with extraordinary properties: the kernel removes these pages from its own page tables. Even a kernel compromise cannot directly access the memory—attackers must reconstruct page tables or spawn a privileged process. The memory is automatically locked (never swapped), and hibernation is blocked while active regions exist [7]. When kernel exploits are a realistic threat model, memfd_secret() provides meaningful defense-in-depth.

Windows: AWE for Serious Protection, VBS Enclaves for Isolation

Windows VirtualLock() has a critical limitation that surprises many developers: it locks pages into the working set, not into physical RAM. Pages can still be written to the page file under memory pressure [8]. For guaranteed non-paged memory, Address Windowing Extensions (AWE) is required [9]:

1ULONG_PTR numPages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
2PULONG_PTR pageArray = malloc(numPages * sizeof(ULONG_PTR));
3AllocateUserPhysicalPages(GetCurrentProcess(), &numPages, pageArray);
4void *mem = VirtualAlloc(NULL, numPages * PAGE_SIZE, MEM_RESERVE | MEM_PHYSICAL, PAGE_READWRITE);
5MapUserPhysicalPages(mem, numPages, pageArray);

AWE memory is physically present and locked until explicitly freed. The catch: it requires SeLockMemoryPrivilege, which must be explicitly granted via Group Policy.

macOS: Secure Enclave for Keys

macOS implements POSIX-compliant mlock(), but Apple’s stronger play is the Secure Enclave—a hardware-isolated coprocessor present on Apple Silicon and T2 chips [10]. Private keys generated in the Secure Enclave never leave it; the main CPU only sees ciphertext and operations performed inside:

1let privateKey = try SecureEnclave.P256.Signing.PrivateKey()
2let signature = try privateKey.signature(for: data)

Keys are tied to the device’s unique identifier and cannot be exported. The Secure Enclave has its own Memory Protection Engine using an ephemeral AES key generated at boot [10]. For applications where P-256 ECC keys suffice, this is the strongest protection available on Apple platforms—bypassing all software-based memory vulnerabilities entirely.

Hardware Memory Encryption Becomes Standard

AMD SME and SEV: Transparent Encryption with Per-VM Isolation

AMD’s Secure Memory Encryption (SME) embeds an AES engine in the memory controller that encrypts all data written to DRAM using a random ephemeral key generated at boot. On 4th Gen EPYC (Genoa), this upgraded to 256-bit AES-XTS compliant with FIPS 140-3 [11]. Transparent SME (TSME) requires no OS changes—all memory is encrypted automatically.

Performance overhead is minimal: Cloudflare benchmarked 0.699% average performance reduction across diverse workloads with TSME enabled on EPYC processors [12].

Secure Encrypted Virtualization (SEV) extends this to per-VM encryption keys managed by the AMD Secure Processor (an ARM Cortex-A5 microcontroller). SEV-SNP (Secure Nested Paging) adds memory integrity protection via a Reverse Map Table (RMP) that tracks ownership of every 4KB page, preventing hypervisor-based replay, remapping, and corruption attacks [13]. The guarantee: VMs always see the data they last wrote.

Intel TME and TDX: Multi-Key Encryption and Trust Domains

Intel’s Total Memory Encryption (TME) provides full-memory AES-XTS encryption with an ephemeral key, similar to AMD SME. TME-MK (Multi-Key) supports up to 32,767 keys, enabling per-page or per-VM encryption.

Trust Domain Extensions (TDX) creates hardware-isolated VMs called Trust Domains protected from the hypervisor via a dedicated TDX module running in a new “SEAM” CPU mode. Each Trust Domain gets a unique encryption key, and memory integrity is protected by SHA-3-256 MACs.

ARM CCA: Realms for Mobile and Server

ARM’s Confidential Compute Architecture (CCA) extends the processor to four execution worlds (versus two with TrustZone) [14]. Realms are confidential computing environments isolated from both the normal OS and the secure world. A Granule Protection Table (GPT) enforced in hardware tracks page ownership, and the Realm Management Monitor (RMM) manages realm lifecycle. Silicon with CCA support began appearing in 2024-2025, targeting smartphones, servers, and automotive systems.

Cold Boot Attacks and Memory Persistence

The 2008 Princeton cold boot research demonstrated that DRAM retains data for seconds at room temperature and minutes when cooled [1]. Modern memory shows faster decay but remains vulnerable. DDR5’s faster refresh rates (32ms vs 64ms) and improved scrambling provide some protection, but 2024 research achieved 36-41% data preservation rates under optimal attack conditions [15]. The TEE.fail attack (2025) demonstrated DDR5 memory bus interposition compromising Intel TDX and AMD SEV-SNP using interposers costing $50-1,000 [16].

Hardware memory encryption (TME/SME) provides strong defense—even if DRAM contents are dumped after a cold boot, the encrypted data is useless without the ephemeral key, which exists only in CPU registers and is lost on power cycle.

For systems without hardware encryption, TRESOR stores AES keys exclusively in x86 debug registers and performs all encryption in CPU registers—keys never touch RAM [17]. Performance is comparable to standard AES with AES-NI acceleration.

Rowhammer: A Persistent and Evolving Threat

Rowhammer exploits DRAM physics—rapid row access induces bit flips in adjacent rows [18]. Despite vendor mitigations, new variants continue bypassing defenses. Half-Double (2021) demonstrated bit flips at 2-row distance—an inherent silicon property, unfixable by Target Row Refresh [19]. ZenHammer (2024) achieved the first successful Rowhammer on AMD Zen architecture. Phoenix (2025) bypassed DDR5 TRR achieving root in 109 seconds on SK Hynix modules [3].

The JEDEC Per-Row Activation Counting (PRAC) standard published April 2024 tracks row activations and triggers mitigation at thresholds—this will appear in future DDR5 revisions and is built into LPDDR6 from launch. Until then, increased refresh rates and memory encryption provide defense-in-depth.

Spectre, Meltdown, and Speculative Execution

The 2018 Spectre/Meltdown disclosure fundamentally changed processor security [2]. Attacks continue evolving. Research in 2024 revealed that Spectre vulnerabilities persist in the latest AMD and Intel processors [20]. Full anti-Spectre mitigations impose approximately 25% performance overhead on Linux systems. Hardware mitigations include IBRS, STIBP, retpolines, and continuous microcode updates.

Memory encryption (TME/SME) doesn’t directly prevent speculative execution attacks—those exploit CPU caching behavior, not DRAM contents. Confidential computing (SGX, TDX, SEV-SNP) provides isolation but faces its own speculative execution challenges requiring careful mitigation.

Modern Crypto Libraries: Defense in Depth

OpenSSL’s Secure Heap

OpenSSL provides an optional secure heap initialized early in application lifecycle [21]:

1CRYPTO_secure_malloc_init(1048576, 16);  // 1MB secure heap
2void *key = OPENSSL_secure_malloc(32);
3// Use key...
4OPENSSL_secure_clear_free(key, 32);  // Zero then free

The secure heap uses mlock() to prevent swapping, MADV_DONTDUMP to prevent core dumps, and guard pages to catch overflows.

libsodium: Guard Pages and Canaries

libsodium’s sodium_malloc() provides comprehensive protection [22]: guard pages before and after allocations (PROT_NONE), 16-byte canaries detecting buffer underflows (verified on free), automatic memory locking and core dump prevention, and memory filled with 0xdb on allocation (detecting uninitialized reads).

1void *key = sodium_malloc(32);
2// Use key...
3sodium_free(key);  // Canary check, zero, unlock, free

BoringSSL: Automatic Zeroing on Every Free

Google’s BoringSSL simplified the API: OPENSSL_free() always zeros memory before freeing—no separate clear_free function needed [23]. Every allocation includes a size prefix enabling automatic clearing without explicit size parameters.

Rust Crypto: Ownership-Based Security

Rust’s ownership model enables deterministic secret cleanup [24]:

1use zeroize::Zeroizing;
2let password = Zeroizing::new(String::from("secret"));
3// Automatically zeroed when dropped

The zeroize crate uses write_volatile and atomic memory fences to prevent compiler optimization. The secrecy crate wraps secrets with explicit expose_secret() access, preventing accidental logging [25].

Rust’s memory safety prevents use-after-free and double-free, but does not prevent side-channel attacks. Speculative execution vulnerabilities exist at hardware level regardless of language. However, deterministic cleanup timing and explicit secret handling significantly reduce exposure compared to garbage-collected languages.

Hardened Allocators: Beyond Library-Specific Solutions

For system-wide protection, GrapheneOS hardened_malloc provides guard pages, random canaries, zero-on-free, slot randomization, and ARM MTE support [26].

Compiler Challenges: Defeating Dead Store Elimination

Compilers routinely eliminate “unnecessary” memory writes, including security-critical zeroing:

1char password[32];
2// use password
3memset(password, 0, 32);  // Compiler may remove as "dead store"
4return;

Platform-specific solutions emerged: Windows provides SecureZeroMemory() (inline assembly, never optimized). BSD and glibc offer explicit_bzero() (OpenBSD 5.5+, glibc 2.25+) [27]. C11 Annex K defines memset_s() with limited adoption. The Linux kernel uses memzero_explicit() with memory barriers. Rust’s zeroize crate uses core::ptr::write_volatile with atomic fences—guaranteed by language semantics not to be optimized away [24].

Practical Recommendations for 2025

For new systems protecting encryption keys in memory:

  1. Enable hardware memory encryption if available: Intel TME (via BIOS), AMD SME/TSME (mem_encrypt=on kernel parameter), or verify cloud VM type includes memory encryption

  2. Use memfd_secret() on Linux 5.14+ for highest-value secrets—kernel can’t access the memory even if compromised

  3. Deploy confidential computing for cloud workloads: Azure DCasv5 (SEV-SNP) or DCesv5 (TDX), Google Cloud N2D/C3, or AWS Nitro Enclaves

  4. Use library secure allocation functions: OPENSSL_secure_malloc(), sodium_malloc(), or Rust’s Zeroizing<T>. Never rely on standard free()

  5. Disable swap or use encrypted swap—memory locking has limits

  6. Prevent core dumps: setrlimit(RLIMIT_CORE, 0) + prctl(PR_SET_DUMPABLE, 0) on Linux

  7. Apply microcode updates immediately—speculative execution vulnerabilities continue emerging

  8. Monitor DRAM security research—Rowhammer variants and memory bus interposer attacks continue evolving

Looking Forward

Hardware memory encryption and confidential computing have dramatically improved the baseline for protecting secrets in memory. A determined attacker with physical access now faces encrypted DRAM rather than plaintext keys. Cloud operators can no longer read tenant memory.

Yet significant challenges remain. Speculative execution attacks continue emerging faster than mitigations can close them. Rowhammer defenses remain imperfect; the Phoenix attack on DDR5 in 2025 demonstrated that even the newest memory technology is vulnerable [3]. Physical interposer attacks costing under $100 can compromise memory encryption by exploiting the lack of authenticated encryption in current hardware [16].

The trajectory is positive: JEDEC PRAC will provide standardized Rowhammer mitigation, confidential computing continues maturing with integrity verification, and memory-safe languages reduce the attack surface for software vulnerabilities. But secure memory allocation in 2025 requires understanding a far more complex landscape than mlock() alone—hardware encryption, trusted execution environments, and continuous vigilance against new attack classes are now the baseline for serious cryptographic applications.

References

  1. Halderman, J.A. et al. “Lest We Remember: Cold Boot Attacks on Encryption Keys.” USENIX Security 2008. (http://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman.pdf)
  2. “Meltdown & Spectre in 2024: Fixes, Impact, and What’s Next.” StarWind Software. (http://www.starwindsoftware.com/blog/meltdown-spectre-2024-status-update/)
  3. “Phoenix RowHammer Attack Bypasses Advanced DDR5 Memory Protections.” The Hacker News, September 2025. (http://thehackernews.com/2025/09/phoenix-rowhammer-attack-bypasses.html)
  4. “Linux 5.14 Can Create Secret Memory Areas With memfd_secret.” Phoronix. (http://www.phoronix.com/news/Linux-5.14-memfd_secret)
  5. “mlock, mlock2, munlock, mlockall, munlockall - lock and unlock memory.” Ubuntu Manpage. (http://manpages.ubuntu.com/manpages/questing/en/man2/mlock2.2.html)
  6. “mlockall(2): lock/unlock memory - Linux man page.” (http://linux.die.net/man/2/mlockall)
  7. “memfd_secret(2) — Linux manual page.” man7.org. (http://www.man7.org/linux/man-pages//man2/memfd_secret.2.html)
  8. “PuTTY wish virtuallock.” (http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/virtuallock.html)
  9. “Address Windowing Extensions.” Microsoft Learn. (http://learn.microsoft.com/en-us/windows/win32/memory/address-windowing-extensions)
  10. “Secure Enclave.” Apple Platform Security. (http://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web)
  11. “AMD Secure Memory Encryption SME Performance With 4th Gen EPYC Genoa.” Phoronix. (http://www.phoronix.com/review/amd-sme-genoa)
  12. “Securing Memory at EPYC Scale.” Cloudflare Blog. (http://blog.cloudflare.com/securing-memory-at-epyc-scale/)
  13. “AMD SEV-SNP: Strengthening VM Isolation.” AMD. (http://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/solution-briefs/amd-secure-encrypted-virtualization-solution-brief.pdf)
  14. “Arm Introduces Its Confidential Compute Architecture.” WikiChip Fuse. (http://fuse.wikichip.org/news/5699/arm-introduces-its-confidential-compute-architecture/)
  15. “Cold Boot Attacks: The Persistent Memory Vulnerability That Won’t Die.” Agarhouse Dev. (http://agarhouse.com/blog/post.php?id=5)
  16. “TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition.” (http://tee.fail/)
  17. “TRESOR - Wikipedia.” (http://en.wikipedia.org/wiki/TRESOR)
  18. “Row hammer - Wikipedia.” (http://en.wikipedia.org/wiki/Row_hammer)
  19. “Google says Rowhammer attacks are gaining range as RAM is getting smaller.” The Record. (http://therecord.media/google-says-rowhammer-attacks-are-gaining-range-as-ram-is-getting-smaller)
  20. “New Research Reveals Spectre Vulnerability Persists in Latest AMD and Intel Processors.” The Hacker News, October 2024. (http://thehackernews.com/2024/10/new-research-reveals-spectre.html)
  21. “OPENSSL_secure_malloc.” OpenSSL Documentation. (http://www.openssl.org/docs/man1.1.1/man3/OPENSSL_secure_malloc.html)
  22. “Secure memory.” Libsodium Documentation. (http://libsodium.gitbook.io/doc/memory_management)
  23. “BoringSSL - mem.h.” (http://commondatastorage.googleapis.com/chromium-boringssl-docs/mem.h.html)
  24. “Zeroize — Rust crypto library.” Lib.rs. (http://lib.rs/crates/zeroize)
  25. “Crate secrecy.” docs.rs. (http://docs.rs/secrecy/latest/secrecy/index.html)
  26. “GrapheneOS hardened_malloc.” GitHub. (http://github.com/GrapheneOS/hardened_malloc)
  27. “explicit_bzero(3).” FreeBSD Manual Pages. (http://man.freebsd.org/cgi/man.cgi?query=explicit_bzero&sektion=3&format=html)