6 ms·
Viable ROP-free roadmap for i386/armv8/riscv64/alpha/sparc64
- ComputerGuru 3y agoOT: I wonder whether Apple or Firefox’s “reading mode” algorithms (both broken for this link) will gain the ability to handle these plaintext, fixed-width, hard line ended, htmlified email archives before the owners of any of these sites like marc.info adapt to use more user friendly formatting that can reflow in a narrower-width browser window…
- deleted 3y ago[deleted]
- prmoustache 3y agomy firefox do not propose reading mode because ... the page itself is pretty much in reading mode already with the line breaks to limit line length. Nothing is broken as I see it.
- recursive 3y agoI see margin-left: $small. Reader mode would help with that.
- ComputerGuru 3y agoIt’s not very user friendly on mobile.
- rzzzt 3y agoYou can force reader view by entering "about:reader?url=<page URL>" into the address bar, but it can not decide what should be displayed for this page. IIUC this check runs on all visited pages and the button is only shown when it succeeds.
- jerrysievert 3y agoI'm on safari 16.6 and reader mode seems to work just fine on this site.
- deleted 3y ago[deleted]
- titzer 3y agoAll of this complexity is one of the key reasons that Wasm does not have an addressable stack (it is fully virtualized in the execution semantics). That moves the management of stack-allocated data structures up a level, but guarantees that the machine has control flow integrity (CFI) built in.
- H8crilA 3y agoWait, it's not about addressability, but essentially about type confusion - typically data that is not actually a code pointer suddenly gets used as such by `ret`. If you are running on a machine that can push an integer but pop it as something else you're still in trouble. BTW, signed pointers are essentially a type check mechanism, where forging types is hard.
- Joker_vD 3y agoThe activation records don't have to be stored in one piece: it's entirely possible to have a call stack that stores only return addresses and a data stack that stores frames of local variables (that's how you'd normally program e.g. on 6502). Which is a scenario that x64 arguably supports too, having separate RSP and RBP registers, with RBP-addressing being nice and easy and RSP-relative addressing encoded very cumbersomely.
- Vogtinator 3y agoThere's AMD shadow stack and Intel CET which do that as well. For compatibility, the return address is also on the data stack, but verified with the address stack.
- titzer 3y agoCET complicates software virtual machines in several ways, e.g. deoptimization and exception handling. It's the wrong solution to a software problem that should never have arisen and just makes software even more complicated. An unfortunate metastasis of running unsafe code without checks for too long.
- MobiusHorizons 3y agoThe use of an illegal instruction to cause the crash is interesting, especially given the speculative execution angle. I naively would have expected branch prediction to do a good job given that the branch is never taken in typical operation, but I guess that only applies to frequently run code
- fweimer 3y agoIt's unclear whether this matters, though. Some CPUs speculate through unconditional control flow as if it is never going to happen.
- stefan_ 3y agoI wouldn't expect a CPU to speculatively execute something like "int 3" either, given compilers will frequently place it in between real functions (for alignment).
- phire 3y agoIt makes sense now that I think about it. We usually base our intuition on the older and simpler branch predictors of 10-20 years ago, where the location of the branch and it's taken/not-taken history are tightly coupled. In those, a never-taken branch is either unknown (which counts as a non-taken prediction) or the branch is known and correctly predicted. But modern branch predictors decoupled the branch location and branch history. They hash the sequence of the last few branches and use that hash to index into the branch history table, allowing the a single branch to have multiple different histories depending on the control flow leading up to it. That significantly improves branch prediction for hot code, the predictor can now track things like a branch that will always be taken during the first iteration of a loop, or a branch will always be taken if the function was called from one location but not another. They can even track the relationships between indirect branches in vtables. But Hash collisions are expected, especially outside of hot code. So it should be quite common for never-taken branches in warmish code to be known, but predicted as taken due to a collision.
- pizzalife 3y agoRemoving RET instructions won't make your program unexploitable. Especially on architectures like x86_64 where you can get so many possible gadgets from a standard library. Trying to make software mechanisms like this that span multiple architectures feels like a relic of the past. These days you need to use processor-specific features like ARM pointer authentication.
- H8crilA 3y agoIt's not meant to be 100% reliable. Also they clearly state that variable length instruction architectures (like x86) are harder to protect. And if you can use something better then great, use it. You can then disable this mechanism.
- saagarjha 3y agoThis misses the point of how ROP works, and is in fact why previous attempts at ROP gadget reduction were flawed: it only takes a handful of gadgets to make a chain. Trying to protect control flow requires more sound approaches than this.
- Joker_vD 3y agoSay, if hardware checked that RET transfers control to a place that's immediately preceded by a CALL instruction, would that help?
- deadbeeves 3y agoThat would disable certain mechanisms that are occasionally useful. For example, to implement user-mode context switches and function hooking.
- saagarjha 3y agoIt would help but it wouldn’t solve ROP. I think it would probably be less useful than gadget reduction, honestly, since there are a lot of useful sequences after a call instruction.
- miki123211 3y agoWhy do Open BSD developers in 2023 care about architectures like alpha and sparc64? What are their use cases? Why would anybody pick those over Intel / ARM? What do those architectures provide that makes people care? Is it just existing hardware that people already have and don't want to throw away, or is there an actual reason one would buy such a processor over the more popular competition? I get the arguments for Riscv for example, but the rest are a mystery for me. I'm not criticizing here, but actually seeking to understand.
- deleted 3y ago[deleted]
- Findecanor 3y agoTheo De Raadt has expressed that compiling and testing on CPUs that are "not boring" helps them to find bugs earlier.
- chasil 3y agoBig-endian CPUs were once the dominant clients in TCP/IP networking, and these machines define the hton and ntoh C macros as no-ops. This means that the network itself is big-endian. Here is an old HP-UX machine running on PA-RISC: # grep ntoh /usr/include/netinet/in.h #ifndef ntohl #define ntohl(x) (x) #define ntohs(x) (x) On x86_64, this is a byte-swap: $ grep bswap /usr/include/netinet/*.h /usr/include/netinet/in.h:# define ntohl(x) __bswap_32 (x) /usr/include/netinet/in.h:# define ntohs(x) __bswap_16 (x) /usr/include/netinet/in.h:# define htonl(x) __bswap_32 (x) /usr/include/netinet/in.h:# define htons(x) __bswap_16 (x) SPARC is big-endian, and the memory is not in the same order as it is on x86. This can coax bugs out of software that are otherwise not seen on little-endian systems. Alpha is litte-endian, but it has its own exotic problems.
- KMag 3y ago> Alpha is litte-endian, but it has its own exotic problems. At least some models of the Alpha were bi-endian, selectable via a pin on the package, IIRC. I believe the Cray T3E ran the chips big-endian.
- musha68k 3y agoSomewhat related: did Power arch really reach it’s “EOL” by now? IIRC IBM was still doing something with it at least? Anyone in the know? > So amd64 isn't as good as arm64, riscv64, mips64, powerpc, or powerpc64.
- kjs3 3y agohttps://www.ibm.com/power https://www.ibm.com/power? Too obscure? On the embedded side, NXP (former Freescale former Motorola) makes them, as does 'Macom' (former AMCC via some hedge fund gymnastics...never heard of them either). Others like Xilinx probably still have licenses to produce. And you can still get the rad-hard RAD750 from BEA systems, for your outer space or post-apocalypse needs.