[Meta] Zeroing memory and general secure memory management #122
Description
Context
In order to reduce the chance of an attacker reading sensitive memory or injecting data into memory that is either malicious code or could trigger code to run in a malicious way, we want to ensure that enclave memory is appropriately wiped.
As further context, improperly managed memory can expose attack vectors. This is particularly an issue in languages like C/C++ where it is always up to the author to implement memory managements. In the case of Rust, the compiler should handle memory management as long as unsafe Rust is not used. In other words the Rust compiler handles the details of memory allocation/deallocation and pointer management, which otherwise commonly cause bugs in languages like C/C++. (For reading on a real life example of memory abuse vectors check out https://blog.inhq.net/posts/u2fhid_init_resp-information-leak/).
Even though the Rust compiler implements memory management, we are not guaranteed that memory will be deallocating and wiped to zero. The compiler may choose not to deallocate and wipe memory for a variety reasons, likely the number 1 being performance: in some situations it may prefer to leave pages of memory if it speeds up execution does not change intended logic. For highly sensitive data, we will want to ensure zeroing does not get optimized away.
Strategy
To practically support this we want to look into building out QOS to support different types of memory wiping, but also expose libraries that enclave application developers can use to zero memory within the applications own logic.
Note that this issue tracks Rust specific approaches and may not be relevant for enclave apps written in other languages