The 'jlp' landing instruction in particular sounds like a sensible addition to the x86 instruction set. While it doesn't solve code injections... limiting the scope to places where control flow changes intentionally - existing functions on the stack instead of totally arbitrary sections of the stack, will raise an immense barrier to code-reuse attacks. The concept is ridiculously simple - require all jmp instructions 'land' on sanctioned 'jlp' landing pads, and yet this would significantly raise the barrier to building an attack. I love it, and hope it's adopted.
There is historical precedent - BASIC originally required line numbers for all lines, and GOTO could jump to any of them. Later versions made line numbers optional, so it became a common idiom to only put a line number on a line you needed to jump to. In TI-BASIC this went further - line numbers were dropped entirely and you jumped to "labels", which could be named as well as numbered.
That's not really the same thing since a big part of the reason BASIC had numbers on every line was to facilitate interactive, line-based editing, not to make them all targets for GOTO. FORTRAN had numerical labels for flow control by that point.
Intel last year released a preview of their Control-flow Enforcement Technology instructions, which appear to implement these proposed extensions (shadow stack + indirect branch tracking): https://software.intel.com/sites/default/files/managed/4d/2a...
"The earliest known description of the COME FROM statement in the computing literature is in R. L. Clark, "A Linguistic contribution to GOTO-less programming," Commun. ACM 27 (1984), pp. 349-350, part of the famous April Fools issue of CACM. The subsequent rush by language designers to include the statement in their languages was underwhelming, one might even say nonexistent."
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?
It 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.
Did you not know one of the NSA mandates is to improve security? It's a dual personality organization to say the least.
They suggested a change to a crypto algorithm to protect it from differential cryptanalysis before that was a public attack. This resulted in a weird dilemma of decided which arm of the NSA was 'helping' because the purpose wasn't public. It wasn't until much later that it turned out to be good.
So what? The IAD part of NSA helped invent INFOSEC, did some of best stuff in COMSEC for long time, did TEMPEST sheilding, evaluated early high-assurance systems (some never broken), made guides for securing many COTS tech, funded work like Galois Inc’s that regularly gets FOSS’d, and some other stuff Im probably forgetting.
They’ve done far more good in IAD than bad with the one subversion that was probably NOBUS in practice. They also published methods to build stuff they can’t beat most of the time under TCSEC B3/A1 and Common Criteria EAL6/7 High Robustness. If we’re being honest, the FOSS and commercial developers ignoring such advice from NSA and others in high-assurance security for decades did more for NSA SIGINT division than TAO subversions ever did. NSA just finds the avoidable problems people leave in there.
So, this meme of “Oh, it’s NSA!” needs to stop unless they’re supplying a closed-source solution or asking for backdoors/escrow. Anything else should simply be rigorously analyzed by 3rd parties like every other source. Funny enough, that’s one of NSA’s certification requirements.
Yeah, a lot of what Galois does is funded by government grants of one sort or another. While my general opinion of the NSA is not favorable, I think that funding basic research in computer security is a legitimate part of their mission. Since Galois is blogging about it, I presume that the NSA isn't hoarding the technology for themselves. So, I see no immediate issue with them accepting money from the NSA.
Strange. Software encoded processors techniques have been used for decades to enforce control flow correctness. It's mathematically correct and much stronger than this weak landing pad / shadow stack concept. It also does not rely on CPU correctness or mechanisms. I guess it's not mainstream enough and people need to reinvent the wheel.
