There was a paper on this topic last year (different authors AFAICT): https://arxiv.org/abs/2211.16212 Also an earlier attempt to fix it with a custom RISC-V extension: https://ieeexplore.ieee.org/document/8714980 which was implemented in an FPGA.

It seems like the consensus is this problem (on all architectures) is going to be solved in software, not hardware. Clang has a pretty comprehensive software-only approach already, although it needs porting to each architecture.

> It seems like the consensus is this problem (on all architectures) is going to be solved in software, not hardware.

Hardware-based shadow stacks and return address signing are already shipping and running on x86-64 and arm64 systems, respectively. Rolling these out required upgrades to compilation and runtime software environments, and there are other software-based CFI techniques that augment these facilities, but it's already clear that hardware primitives are an integral part of the solution.

And it couldn't be otherwise. Between JIT, dynamically loadable modules, and a host of other complexities on real systems, software-only solutions that depend on exhaustive static analysis for robust CFI have little chance of comprehensively closing all the loopholes, especially in the environments that matter most.

Quite a lot of detailed design work has already been done on this for RISC-V. It is currently expected to be ratified in Q3 this year.

https://github.com/riscv/riscv-cfi/raw/main/riscv-cfi.pdf

It seems like you could create an MLIR "ROP" dialect for these "gadgets" and actually make it nearly trivial to write exploits, by compiling your ROP dialect to the appropriate exploit "data" to be placed in the buffer overflow on the stack.

Then you just need to find the buffer overflow opportunity to launch your exploit, using (for example) something like KLEE-style symbolic execution after doing an x86 to LLVM IR conversion on an opaque binary, or by getting access to the original (open source) code and running KLEE the normal way.

Then deploy your exploit.

Profit?

Pretty scary stuff.

> What can we do to prevent ROP attacks?

No mention of bounds checks?

FTA:

> A successful ROP attack needs the following ingredients:

> buffer overflow vulnerable application

Also, this article is about constructing the program to run using ROP, not about calling it. It’s only the latter that requires an exploit, typically from a buffer overflow.

Right, but the ROP program is of no use if it can't be called, as stated in that quote. Hence bounds checks also avoid that class of exploits.

Bounds checks are a high-level language construct. A processor executes machine code which has no concept of bounds check. A processor needs to execute every sequence of machine instructions, including those from languages without bounds checks.

Then the other software mitigations listed in the article are not so useful either, because the implementation (and OS, in the case of ASLR) could choose not to use them, and the processor should execute such code too.

Defense works in layers: bounds checking is a programming language technique (although you can typically switch it off in (some) compilers). ASLR is an OS technique, which works even if bonds checks are switched off. IIRC at some point one OS (Debian?) had a bug in the randomness generation for ASLR, and it was easy to circumvent ASLR because of that.

All you need to defeat ASLR is a data exfil so you can dump the process code. A great paper (https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...) from about a decade ago created fully automated ROP against ASLRed processes (though it did rely on the fact that fork() didn't rerandomize on linux at the time).

Though you can have memory pages which are non-executable so I'd say that the processor in fact has this concept.

The whole point of ROP is to get around this. Rather than executing code that you've sprayed on the heap, you jump to gadgets that are already in the binary to construct your program.

Yes, if you see memory as a page-size-grained array, you can see that they are similar concepts.

There are processors with support for bounds checking and hardware memory tagging.

ARM being one of them.

Those arm and x86 licences are so much toxic, I would support anything risc-v, even if it is bad.

They are not toxic. You are free to use everything you want. But for someone it is easier to rely on an existing established ISA instead of trying to roll their own. Using a niche ISA also may have its downsides: compiler support may be not as good, missing peripherals, inability to reach the desired energy/performance balance etc. So, it totally depends on what you want and what you need. There is no space for toxicity, it's just an emotional illusion. You just choose whatever works for you.

"You are free to use everything" ?

It seems you don't know that, in some countries, it is plain illegal to design a CPU using x86/arm ISAs unless you actually pay some licence fees to intel(x86)/amd(x86_64)/arm.

You have similar toxicity with, mpeg which requires to pay for a license for any decoder/encoder (but not av1), same for hdmi (but not displayport). Limited to some countries (USA at least).

It's even worse with Intel and x86, they basically don't accept your money so you can't even try to license x86.

The companies that currently have licenses (AMD and Via) are probably the only ones that will ever get them.

>Using a niche ISA also may have its downsides

RISC-V is no niche ISA. 10b cores shipped in just 2022, according to CEO's speech in latest RISC-V Summit.

RISC-V is inevitable.

x86 is indeed toxic, the harm that wintel caused and still causes is measured in trillions of dollars. They just gatekeep every program ever and get free money from everyone on the world, for no reasons except that they can do it, and we let them.

I agree GP, everything against intel-amd should be supported.