3 ms·
It'd be wonderful if they kept the ability to define that a certain destructor does zero memory. Sometimes, you need that.
by AlyssaRowan 12y ago
It'd be wonderful if they kept the ability to define that a certain destructor does zero memory.
Sometimes, you need that.
- gpm 12y agoZeroing out memory isn't sufficient, as discussed here: http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-i... That said, this was discussed on reddit[0], it sounds like there is a way to guarantee that you did zero out memory (but not necessarily copies of that memory, as discussed in the link above), and because Rust is intended to be memory safe, it's not as much of an issue if you don't/can't. http://www.reddit.com/r/rust/comments/2fnb82/zeroing_buffers_is_insufficient_why_c_is_insecure/ http://www.reddit.com/r/rust/comments/2fnb82/zeroing_buffers...
- AlyssaRowan 12y agoNot in C. Rust is, as you say, intended to be memory safe. That means it has the hope of getting it right.
- someone13 12y agoFWIW, you can implement the 'Drop' trait to provide a custom destructor, and then use, e.g. 'volatile_set_memory'[0] to zero out the memory of the object. This isn't subject to the same problems as C, AFAIK. [0] http://doc.rust-lang.org/std/intrinsics/fn.volatile_set_memory.html http://doc.rust-lang.org/std/intrinsics/fn.volatile_set_memo...
- strcat 12y agoYou would have to force the sensitive content to be dynamically allocated. All types in Rust can be moved via a shallow memcpy and that will leave around dead shallow copies. For example, `Vec<T>` will leave around dead versions of the values when it needs to do a reallocation that's not in-place.