@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 PM
Oct 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