Post #2279980

2026-04-15 06:06 UTC

@vathpela@infosec.exchange @karolherbst@chaos.social But in most cases it just happened "deterministic behavior" was due to stack being cleared or addresses being the same. Both changes in the kernel not the compiler. Or slightly different library writing to the stack gets that old behavior. E.g. reading after a free, in a secured system might read bad values. Also.

Replies (1)

@vathpela@infosec.exchange 2026-04-15 06:16

@pinskia@hachyderm.io @karolherbst@chaos.social yes. It was an accident that the compiler did something specific. People code to that and always have. That's exactly why this is an "unpopular opinion" thread. There are a lot of situations where it would be significantly useful to be able to tell a newer compiler "I know it isn't the current idea of correct but the old behavior is what's needed." To try to make this more concrete, I maintain the UEFI "shim" loader for linux. We regularly have to make binaries compile with a Debian style "reproducible" builds across many distros and many versions, and one of the largest problems is the compiler - both syntax / interpretation and optimizations. This is a forward compatibility problem and a significant backwards compatibility problem. In all cases, we'd rather have fewer signed objects than we do, but we can't rebuild something on a newer distro and get the same result on as an older distro, entirely because of compiler changes. The result is we have a lot more objects that need to be revoked in the end. We've done things to mitigate this, but having a compiler where you can ask for specific versions of behavior would significantly reduce the problem space. Like it said at the top, not a popular take.

Open ##2279981