4 ms·
Some cool ideas here. The problem that jumps out for me is the overhead that something like this would incur. The landing pad idea would add 3 extra instruction
by colemannugent 10y ago
Some cool ideas here. The problem that jumps out for me is the overhead that something like this would incur. The landing pad idea would add 3 extra instructions to every jmp, that has to be substantial. The shadow stack would effectively double the time spent maintaining the stack and double the stack space required across the board.
Would CPU manufacturers be able to overcome this in hardware with optimization tricks?
Also, if anyone has the time to benckmark this in QEMU so we could get an idea of the overhead that would be very interesting?
- johncolanduoni 10y agoIt doesn't look like they store data on the shadow stack, just return addresses, so it wouldn't take double the time. It does look like it would take double the stack space (and depending on how small your function stacks are, double the cache), but the flip one bit implementation definitely isn't the only way to do this. This is actually pretty reminiscent of how WebAssembly handles stacks. The "real" WebAssembly stack for both local variables and return addresses isn't even within the sandboxed memory addressable in WebAssembly. For values on the stack that require something more sophisticated (e.g. ones accessed via pointers) compilers put them on a shadow stack within WebAssembly's addressable memory. Since WebAssembly doesn't even have an address for the other stack, it's inaccessible baring a sandbox escape, preventing it from getting corrupted and allowing an arbitrary return address.