Compiler Can Undo Your Security Checks
birdculture
28 points
61 comments
September 12, 2026
Related Discussions
Found 5 related stories in 65.2ms across 6,361 title embeddings via pgvector HNSW
- Fuzzing the Gleam Compiler crowdhailer · 60 pts · August 25, 2026 · 52% similar
- ProgramBench Vetted: Reverse Engineering from a Runnable Binary rigelbm · 13 pts · August 20, 2026 · 50% similar
- Claude Is Not a Compiler bryanmikaelian · 148 pts · July 21, 2026 · 49% similar
- Your Open Source Model Could Have a Hidden Time-Release Backdoor llmbababoom · 62 pts · August 24, 2026 · 48% similar
- SeL4 security proofs now complete on AArch64 snvzz · 178 pts · August 24, 2026 · 48% similar
Discussion Highlights (6 comments)
Hizonner
The compiler is allowed to transform your code if it can prove that the result would interact with the outside world in exactly the same way as your original code would, right? You can optimize on "I already checked the value of X" if you can prove that nothing could have changed X. Well, it sounds like a lot of compilers are making unjustified assumptions about what the outside world is allowed to affect or observe. Maybe with the encouragement of specs, maybe not.
fithisux
Compiler does what I tell it. Not the other way around.
Narishma
Title should be "Your C compiler can undo your security checks".
johnbender
A key problem is that compilation operates on an implicit (compiler writers have this in the back of their heads) notion of correctness which is very roughly “preservation of observable behaviors” where “observable” is sequences of system calls and then return value. That is, the final output of a compiler should never add new sequences of observable behaviors. Security properties on the other hand are very often about the relationship between these sequences. For example we like to say that an external observer/attacker can’t distinguish internal state by the external observations (confidentiality) which requires that two observable traces given different hidden values don’t have different observations from the same starting observable state. If you’re an LTS nerd you know this difference as trace properties vs hyper properties. Compilers try to preserve the former but not the latter. Separately there is the problem of “what is observable?” For example, if you include timing in your observable behaviors suddenly the kinds of compiler passes that are able to preserve observations tends to zero rather quickly.
bmandale
weird f*ing site. apparently doesn't like hn visitors and doesn't want me opening the console. i know when im not wanted
omoikane
Regarding compiler deleting memset, there are multiple memory-zeroing functions that are guaranteed not to be optimized away: https://cppreference.com/c/string/byte/memset (memset_s) https://cppreference.com/cpp/string/byte/memset (memset_explicit) Also see notes section for various other functions that people were using before memset_s became standard.