stack zeroization

[nstilt1]

Uses psm to run a function/closure on a stack that is allocated on the heap, then zeroizes that separate stack when the execution finishes.

I attempted to zeroize the space between two pointers: one captured before the closure's call and one after, but upon zeroing the stack, there was a segmentation fault. I will have to remove that code, but it's there in the first commit if anyone thinks they can get it to run without a segmentation fault.

Closes #810 if this is up to standards.

[tarcieri]

I think it might be better if something like this started out as its own experimental crate, especially as zeroize is post-v1.0

[nstilt1]

What should the crate be called? stack_sanitizer? And should this crate require alloc given that using the main function sort of requires the stack input to be on the heap? Should the call to create_aligned_vec() be included in secure_crypto_call_heap()? And secure_crypto_call isn't necessarily secure. Maybe it should be called sanitize_crypto_call_stack?

[tarcieri]

What should the crate be called?

zeroize-stack perhaps? Or zeroize_stack to match zeroize_derive.

Regarding the rest, spike it out however you'd like, but the difficult part will be the rationale for why it's sound.

[nstilt1]

I can go with zeroize_stack. It fits. As for the rationale, the premise is exactly the same as another Rust crate, but it was only implemented for x86_64: https://github.com/dsprenkels/eraser.

With psm, we do not have to write the stack switching function in assemblies because it's already implemented for a number of architectures.

[tarcieri]

Yeah, I've seen eraser in the past, it was mentioned in this paper: https://eprint.iacr.org/2023/1713.pdf

Interesting prototype of the idea.

[newpavlov]

Does it pass Miri?

I left some ideas in the original issue.

[nstilt1]

Darn. Miri wants me to use the following syntax due to how the psm crate is set up:

psm::psm_stack_manipulation! {
    yes {
        /// define fn with psm::on_stack
        pub unsafe fn blah(...) {...}
    }
    no {
        /// define fn without psm::on_stack, likely panic
        pub unsafe fn blah(...) { panic!("Stack manipulation not available on this platform")}
    }
}

After defining it like this, miri fails with the message "Stack manipulation not available on this platform". Likely because miri doesn't have a stack pointer or something... given that this crate was tied to the rust-lang account, I'd say their code is probably legit, and I'm not sure if Miri would be able to analyze all of the assembly without manually using different targets

[nstilt1]

You can confirm that the test passes normally using cargo test but fails with cargo miri test due to the panic. Therefore this code is impossible to analyze with miri, and likely impossible to analyze with rudra given that it's edition 2024. But idek if rudra can analyze assembly files

[nstilt1]

Further evidence for miri not working can be found in psm's build.rs:

https://github.com/rust-lang/stacker/blob/7a3ff32d72bcd0a12a938abb21deddf9f1449cdc/psm/build.rs#L66