zeroize: stack zeroization support

[tarcieri]

It would be nice to be able to zeroize the stack, particularly being able to track how deep the stack grew while executing a particular section of code, and then zeroing out that whole portion of the stack.

This crate might provide the functionality needed to implement such functionality: https://crates.io/crates/psm

Additionally some proc macro annotation might be needed like #[sensitive] which could inject code to instrument the stack and track its depth.

[nstilt1]

I chatted with a few AI models about this again, particularly stack bleaching and clearing registers. I specifically brought up the topics of stack spilling and how the compiler is capable of making copies of data on the stack at will.

• Qwen3 claimed that it would be unnecessary to bleach the stack, and potentially dangerous, maybe even crash the program. Also claimed that stack frames immediately get reused on several specific/common architectures. I do not know if it is correct
• Chat GPT 5 also claimed it would be unnecessary, that impl Drop and ZeroizeOnDrop would be all that is needed
• Gemini also refused to provide code, stating that it could be used maliciously

And finally, we arrive at Claude's output. Claude was much more helpful, stating that stack bleaching is sometimes required for effective zeroization, providing the following functions that have inline asm for both x86_64 and aarch64:

• #[inline(never)] unsafe fn get_stack_pointer() -> *mut u8
• #[inline(never)] unsafe fn clear_stack_range(start_sp: *mut u8, end_sp: *mut u8) // or alternatively:
• #[inline(never)] unsafe fn clear_stack_range_asm(start_sp: *mut u8, end_sp: *mut u8)
• #[inline(never)] pub unsafe fn secure_crypto_call<F, R>(crypto_fn: F) -> R where F: FnOnce() -> R,
• #[inline(never)] unsafe fn clear_registers()

Looking at psm, we likely don't need to define our own fn get_stack_pointer(). We would likely need to define one of the two clear_stack_range fns, unless psm is capable of this this. The non-asm option is probably the go to choice so that we don't have to manually implement asm for each platform/arch, but we'd still need arch-specific register clearing code. We might need to use psm to determine which direction the stack is growing, but could probably just zero out the space between the two pointers, maybe determine the smaller pointer and work towards the larger one.

Where should the code go? This might need compiler fences from zeroize, but claude's code just uses ptr::write_volatile() which could work, but claude uses nothing to make sure that the inline asm doesn't get optimized away... if inline asm can be optimized away. If I recall correctly, zeroize has some handy functions that could probably take care of the stack erasure.

[tarcieri]

The most important thing is for the implementation to be sound, which is a property I don't think an LLM is going to be able to inform you about.

The core desirable security property here is forward secrecy, i.e. if an attacker that compromises the machine at some point after the cryptographic operation has been performed, they won't be able to learn any cryptographic secrets from scraping RAM. While one can hope that additional future stack usage will eventually overwrite those residual secrets left in RAM, cryptographic algorithms can often use large amounts of stack space, and spill secrets onto the stack in the process.

psm looks like it might be able to provide the fundamental building blocks in a portable manner but is also notably very much unsafe, as is any code performing the zeroization.

An efficient implementation will be able to wipe the stack up to a sort of "high watermark" of maximum possible stack usage when executing a particular function. Determining that is the tricky part.

The alternative is to zeroize the entire stack below (or above, depending on the stack implementation) the current frame but stacks can be large and that can be needlessly slow.

[nstilt1]

I tried getting a pointer from before and after a function call and zeroizing the space in between, but on x86_64 it resulted in a segmentation fault. Then I essentially switched to what that other crate was doing: using an area on the heap as the stack for a closure's execution by using psm's on_stack(). With this method, there was no segmentation fault on this arch, and it only requires asm from psm, no asm in zeroize for this implementation.

[newpavlov]

In one of my projects I successfully used pthread_attr_getstack to bleach stack. But it's a Linux-only solution and zeroizes full stack (in the project we were spawning cryptographic worker threads with a small stack, so it was fine).

I believe we should use asm! for stack bleaching by default. It may be even fine to start only with x86/ARM/RISC-V support. I also thought about implementing bleaching which would erase stack up to the first empty page, it still can overshoot (e.g. after cryptographic routine is executed after a stack hungry function) but until we get a way to calculate the maximum stack usage bound for functions in the language it's probably the most practical solution.

[nstilt1]

I appreciate the suggestion—you're absolutely right that asm! is the most direct path to reliable stack bleaching. I’ll be upfront: I’m not an expert in any architecture-specific assembly, so any asm! I include will likely be adapted from existing crates or generated with the help of "tooling" which may not be perfect by any means...

[nagisa]

Coming from the linked PR, without admittedly reading into the change much more than skimming the discussion.

First and foremost, you don't need to allocate a new stack/switch to it if you want to zero-out a region of stack. The code can be made reliable/sound for the "current" stack and doing so is orthogonal of which stack is used. As for determining the stack use for a function call, LLVM can compute/output this information. Integrating that information back into a binary that has already been compiled requires some imaginative solutions (link-time shenanigans can be used to achieve this.)

However, there are some good reasons to just mmap a page or a couple for this purpose: one is to lock the pages into memory, so that they aren't swapped out into disk (in a reliable cross-platform manner) and also to limit the amount of bleaching needed statically (if you allocate a 16KiB stack, you will have 100% confidence you don't need to bleach past that threshold.) This mmap approach could be accompanied with some on-the-fly growing of the pages (requiring one to write their own SIGSEGV/SIGBUS signal handlers) to track things more precisely and to reduce bleaching overhead – not dissimilar to what happens to the main thread stack on linux.

I'm not comfortable claiming that psm's stack pointer calculation is going to be 100% reliable for bleaching the stack. While it does attempt to return the most accurate estimation of current stack pointer, the way how compilers allocate stack and inlining make it quite difficult to do so reliably. That's another good reason to roll a custom mmap stack.

When implementing bleaching itself you will want to make sure to set-up the code such that bleaching only occurs starting at a frame pointer of some non-inlined callee, after it returns. Otherwise you're risking writing over stack regions that are still used. A kinda general pattern for this could look like this:

#[inline(never)]
fn work_with_frame_pointer(callback: fn(...) -> ()) -> *mut u8 {
    let stack_ptr = psm::stack_pointer(); // or an equivalent asm
    callback(); // also needs inline(never) in order to make `psm::stack_pointer` accurate enough
    stack_ptr
}

fn zero_that_stack() {
    let base = work_with_frame_pointer(my_work);
    bleach_stack_starting_at(base);
}

This holds true regardless of whether you use psm, raw assembly or something else to determine where to start.

[newpavlov]

LLVM can compute/output this information

Unfortunately, you either have to ensure that you have a leaf function (i.e. a function which does not call anything else) or you would need to explore the whole possible call tree. And after you did all that... a single call to memcpy/memset will break everything since they are linked dynamically by default and you can not know how much stack they use.

[nagisa]

There are solutions to that as well in the embedded world, but as is a common theme to this sort of problem statement they're involved.