←back to thread

1371 points yett | 1 comments | | HN request time: 3.252s | source
Show context
amenghra ◴[] No.43774928[source]
IMHO, if something isn’t part of the contract, it should be randomized. Eg if iteration order of maps isn’t guaranteed in your language, then your language should go out of its way to randomize it. Otherwise, you end up with brittle code: code that works fine until it doesn’t.
replies(11): >>43774993 #>>43775199 #>>43775210 #>>43775344 #>>43775361 #>>43775510 #>>43775759 #>>43776084 #>>43776311 #>>43776598 #>>43778608 #
bri3d ◴[] No.43775199[source]
There are various compiler options like -ftrivial-auto-var-init to initialize uninitialized variables to specific (or random) values in some situations, but overall, randomizing (or zeroing) the full content of the stack in each function call would be a horrendous performance regression and isn't done for this reason.
replies(3): >>43778515 #>>43779449 #>>43781342 #
neuroelectron ◴[] No.43778515[source]
There are fast instructions (e.g., REP STOSx, AVX zero stores, dc zva) and tricks (MTE, zero pages), but no magic CPU instruction exists that transparently and efficiently randomizes or zeros the stack on function calls. You think there would be one and I bet there are on some specialized high-security systems, but I'm not sure even where you would find such a product. Telecom certainly isn't it.
replies(3): >>43778720 #>>43779274 #>>43779896 #
mjevans ◴[] No.43778720[source]
You couldn't do random, but with a predictable performance hit to memory, cache and write-line use stack addresses COULD be isolated for a program, for a library, etc.

It'd be expensive though; every context switch would require it's own stack and pushing / restoring one more register. There's GOOD reason programs don't work that way and are supposed to not rely on values outside of properly initialized (and not later clobbered) memory.

replies(1): >>43779908 #
neuroelectron ◴[] No.43779908[source]
It should be efficient though, that's the point. Specialized hardware or instructions should be able to zero the stack in a single cycle, instead it's much more expensive. Of course the problem with this is it could be used to hide things just as easily, making it impossible to reverse engineer an unknown exploit.
replies(1): >>43783240 #
1. mjevans ◴[] No.43783240[source]
Why would a specialized instruction be necessary? 'the stack' is stored in memory just like everything else.

Expensive is the (very slow for modern CPUs) operation of _writing_ that change in value out to memory at it's distant and slow speed compared to that which the CPU operates at, as well as the overhead of synchronizing that write to any other caches of those memory locations.

Maybe you're thinking of the trick of a band new page of memory mapped memory that is 'zeroed' but is in reality just a special 'all zeros' page in the virtual to physical memory lookup table? Those still need to be zeroed by real writes at some point, if they're ever used.