So, ROP itself is a (frequently very effective) workaround for W^X memory protection features, where executable code itself should be unmodifiable at runtime. I wonder if there's a "next" CFI attack that calls existing functions that are actually defined as such, but in a weird order, or with weird arguments.
The ability to do that effectively would depend on lots of stuff, including the calling convention (as the stack or heap are easier to corrupt than registers).
Maybe someone is already writing an advanced ROP gadget-search that looks for "real functions that can be combined to make ROP gadgets by calling them in a bizarre way". (This is already much less likely to occur in a real program ... I think ...! But maybe the return-to-libc phenomenon is still a rich source of vulnerability?)
Interestingly, RISC-V's Zicfilp proposal includes an optional, 20-bit label operand so that call sites and targets can be paired more strictly.
I'm not sure how or if it addresses trampolines and similar thunks that interpose callee and caller, but which don't necessarily touch arguments. Such thunks are quite common in dynamically linked code as ELF and Mach-O do lazy loading by default--dynamic function symbols are initially small thunks that load the dependency and then forward the call, restoring registers and the stack without having to know the call signature.
So, ROP itself is a (frequently very effective) workaround for W^X memory protection features, where executable code itself should be unmodifiable at runtime. I wonder if there's a "next" CFI attack that calls existing functions that are actually defined as such, but in a weird order, or with weird arguments.
The ability to do that effectively would depend on lots of stuff, including the calling convention (as the stack or heap are easier to corrupt than registers).
Maybe someone is already writing an advanced ROP gadget-search that looks for "real functions that can be combined to make ROP gadgets by calling them in a bizarre way". (This is already much less likely to occur in a real program ... I think ...! But maybe the return-to-libc phenomenon is still a rich source of vulnerability?)