5 ms·

Return oriented programming on RISC-V – Part 1 (2022)

• sylware 3y ago
  Those arm and x86 licences are so much toxic, I would support anything risc-v, even if it is bad.
  • garganzol 3y ago
    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.
    • bmacho 3y ago
      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.
    • sylware 3y ago
      "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).
      • ElectricalUnion 3y ago
        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.
    • snvzz 3y ago
      >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.
• hayley-patton 3y ago
  > What can we do to prevent ROP attacks? No mention of bounds checks?
  • Someone 3y ago
    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.
    • hayley-patton 3y ago
      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.
      • mafribe 3y ago
        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.
        • przemub 3y ago
          Though you can have memory pages which are non-executable so I'd say that the processor in fact has this concept.
          • mafribe 3y ago
            Yes, if you see memory as a page-size-grained array, you can see that they are similar concepts.
          • UncleMeat 3y ago
            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.
• rwmj 3y ago
  There was a paper on this topic last year (different authors AFAICT): https://arxiv.org/abs/2211.16212 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 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.
  • wahern 3y ago
    > 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.
    • brucehoult 3y ago
      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 https://github.com/riscv/riscv-cfi/raw/main/riscv-cfi.pdf
• deleted 3y ago
  [deleted]
• erichocean 3y ago
  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.