This issue tracks designing and investigating a better way to test that the prime functionality of this crate, memory zeroization, actually does what it should without introducing undefined behavior or complicated wrapper applications.
In theory, it should be possible to create a test-only GlobalAllocator that bypasses the platform's memory allocation APIs (such as libc) which come from std::alloc::System in favor of a statically allocated arena where each access region can be tracked precisely. With this, the test can inspect the arena after running a series of various alloc/dealloc operations to confirm the final result was a fully zeroed page. We might want to consider black boxing the read checks as well to hinder the compiler from changing the generated dealloc routine based on the fact an observable read happens at the end.
We should also consider using cargo show-asm to verify the expected assembly is not missing our zeroization routine in some easy cases. I don't think this would be perfect, but several cryptography libraries and others with codegen-sensitive requirements do similar in an attempt to make incorrect compiler-introduced behavior obvious at least.
This issue tracks designing and investigating a better way to test that the prime functionality of this crate, memory zeroization, actually does what it should without introducing undefined behavior or complicated wrapper applications.
In theory, it should be possible to create a test-only
GlobalAllocatorthat bypasses the platform's memory allocation APIs (such aslibc) which come fromstd::alloc::Systemin favor of a statically allocated arena where each access region can be tracked precisely. With this, the test can inspect the arena after running a series of various alloc/dealloc operations to confirm the final result was a fully zeroed page. We might want to consider black boxing the read checks as well to hinder the compiler from changing the generateddeallocroutine based on the fact an observable read happens at the end.We should also consider using cargo show-asm to verify the expected assembly is not missing our zeroization routine in some easy cases. I don't think this would be perfect, but several cryptography libraries and others with codegen-sensitive requirements do similar in an attempt to make incorrect compiler-introduced behavior obvious at least.