It started when I was trying to optimize the binary size of a program that used zeroize on drop, and while following the checklist to panic abort, it occurred to me that if panic abort is enabled, data implements zeroize on drop is not guaranteed to be zeroize before it is cleaned up. So I opened an issue to discuss the problem. And there's more than zeroize to the critical drop behavior, so I felt the need to move the topic to this and discuss it in more depth.
Should we warn more when mentioning panic abort, especially mentioning it when optimizing binary sizes?
Panic=abort doesn't introduce this possibility, it just makes it happen more. With panic=unwind, you can still stack overflow and never zeroize. I think std::process:exit can also do that? And getting terminated from the OS.
There's nothing in rust to guarantee destructors are run, even if everything goes smoothly.
10 Likes
Unfortunately, there will always be ways your process can be terminated without a chance to run destructors. You need to treat zeroize as a best-effort defense-in-depth, but not as a guarantee.
You could make zeroing a bit more robust by installing atexit handlers and signal handlers. It will be tricky to implement for arbitrary objects, but may be doable for something at a static address.
For the zeroize specifically I don't think it's critical in this case. When the process shutdown all its memory returned back to the OS and get zeroized before being reused by other processes.
1 Like
Yeah, there has to be a realistic threat model. One can't guard against every possible attack completely. What if someone cuts the CPU off from RAM while your process is running and reads its contents via JTAG or whatnot?
1 Like
I belive hardware RAM encryption is a thing because of this. As far as I know it is only for server CPUs at this point (AMD Epyc I belive has it, at least some models, not sure about Intel).
It does indeed depend on your threat model. I wouldn't personally worry told much about this.
The key issue for zeroize's case seems to be how well most operating systems guarantee that "memory pages are zeroized before they are allocated to other processes", and the lazy zeroizing issue mentioned by maintainer in the original issue.