Oct 7, 2026, 4:17 PMRE: https://chaos.social/@icing/117398069550473355
I’ve complained about this before, but this is not something you can usefully do from the front-end. If we really want things zeroed, we need compiler functionality that asks the back end to ensure that the data is gone as soon as possible after it’s no longer needed and no later than when the function returns, either by having the register or memory reused, or cleared if there’s no good reuse opportunity
Oct 7, 2026, 4:19 PM@fay59 better make sure there aren't any context switches dumping registers to thread state in between either
Oct 7, 2026, 4:35 PM@joe @fay59 I think CPUs should have string instructions from clearing, copying, comparing, and hashing memory (with a few different kinds of hash functions for the latter, e.g. checksum, hash table hash, and cryptographic hashes). CPU microarchitects generally don't like this for a number of reasons, but we must find a way.
Oct 7, 2026, 4:48 PM
@joe @fay59 Pretty much any attempt at wiping secrets fails unless it is part of task/process management (system/kernel), and even then it is still leaky (e.g swap, SRAM/DDR contents across reset, etc, etc), or can be snooped (spectre, SPA, DPA, etc).
If leaking secrets is ever a concern where you'd want to apply sanitizing at *compiler* level, you're likely in a threat model where that isn't sufficient.
Oct 7, 2026, 7:44 PMOct 7, 2026, 7:57 PM@joe @fay59 It is an unpopular opinion, but mine is these mitigations should _not_ be used. Not even if there is "compiler support". Keeping secrets from other parts of the same task, in the same program, is extremely fragile. People integrate these repos into platforms you didn't expect—with the expectation they get sanitizing—and it fails to do so. And worse, they go no further than this, because the expectation is data is gone, which it isn't, because it's a *systems* problem.
@joe @fay59 If you have a feature-rich platform (SoC) then perhaps you can use ISA or mapped-device features, so general-purpose parts of your core are never tainted. Otherwise, the only way to guarantee isolation of that function is context isolation, and the least leaky method is a separate task/process. Or if you're feature-rich, a dedicated "secure" core, or (worse but works better than nothing) a "secure state".
Otherwise, some day you find your sanitizing silently stopped working.
Oct 7, 2026, 9:26 PMOct 8, 2026, 1:06 AM
Oct 7, 2026, 4:32 PM@fay59 yeah - realistically it should probably be an attribute that gets to the backend for register and stack allocation, of course doing that in a cross compiler way is a misery pit (attribute can be ignored, magic builtin requires cross compiler support, etc)