Having experimented with putting secrets in memory that isn't part of a core dump, it's exceptionally hard. C/C++ fights you the entire way making temporary copies in other, unrelated places. People are saying "why don't they just" and I suspect they did, but they were defeated.
@isomer I wonder if this is the sort of thing Rust can make a lot easier, with its ownership system.
A problem that occurs is that you sometimes need to operate on those secrets, so they end up in registers or on stack. Then they stay there until the next time that register/stack area is used. Vector registers aren't used that often, so secrets end up staying there longer.
You could try to have a compiler that cares about where data stays behind, but that would make performance worse, so you'll need to mark data for which this is important. That has to be "contagious": you must never be able to silently cast that property away (and should _never_ cast it away). So, you need alternate versions of e.g. libc functions that will operate on "data not to be left afterwards", which implies that it's more of an all-ecosystem evolution than msan support (where you "just" need everything to be compiled with msan, not everything to be duplicated).
@robryk @samwho if you take plaintext and encrypt it with a key, the now encrypted data should somehow become untainted despite having interacted with secret data.