Follow

MIPS, unlike its simplicity of being a RISC design, its implementation is in a state of massive chaos. The classic MIPS has 5 revisions, MIPS III gave us the miracle of 64-bit personal computing in 1995. But then SGI failed and MIPS decided to market for embedded systems, so they went backward to create the modern MIPS32/64, based on MIPS II, incompatible with classic MIPS, and it has 6 revisions. Don't even mention MIPS16 and microMIPS...

And MIPS has 6 ABIs. O32/O64/N32/N64/EABI/NUBI. O32 is the original MIPS I ABI. N32/N64 is SGI's ABIs for 64-bit CPUs and generally recommended. Unfortunately, because they were only usable on 64-bit CPUs, after the MIPS32/64 split, 32-bit MIPS devices are still using the ancient O32 ABI which has major performance issues. There's limited support for N32 and virtually no support for N64. And most ASM optimized programs, like JITs, only has O32 support, renders the benefits of 64-bit MIPS kind of useless.

Practically, it means MIPS means four different architectures, and some has three sub-architectures of its own, programs needed to be ported independently. And despite an awful number of ABIs, none is optimal. None of the O/N ABIs support efficient position-independent code, which means it's bad for pretty much 100% of the programs we run, and they all lack a per-thread pointer for efficient threading. Lack of enough callee-saved registers limited the compiler's ability to generate optimized code.

There was an initiative among the developers in the FOSS world to create NUBI, which intended to create a grand unified ABI that solves all the problems, but dead quickly at the draft-stage due to lack of support and backings. After all, no one has MIPS workstations anymore.

The only positive thing about this mess: Linux was smart enough to decouple MIPS and MIPS ABIs in the beginning, so O32/N32/N64 can coexist on a single 64-bit kernel.

And because of all the mentioned problems in this thread, in 2017, complete implementation of exploitation mitigation techniques don't exist on MIPS. Due to lack of maintenance and the chaotic implementations, RWX memory is still allowed due to a bug, despite MIPS has NX a decade ahead of x86. And ASLR was only implemented in Linux in 2017!

From 2000-2017, smashing the stack on MIPS is as easy as it was in the 1990s. Even they can be fixed, don't forget ASLR is never going to be effective. 70% of MIPS uses O32 ABI, 30% of 64-bit variants uses N32, which only has 32-bit pointers and at most 16-bit of randomness.

MIPS is how a good architecture can be ruined due to a flood of historical and artificial problems which is not inherent on MIPS. The ABI chaos were primarily created due to pioneering 64-bit personal computing in 1995, at a time when the infrastructure and application support didn't exist, so it turned the entire support of this architecture into an ugly hack. I don't think they can be solved, ever.

The conclusion of this thread is: I don't know what to say. May RISC-V save us all!

Sign in to participate in the conversation
Cybrespace

cybrespace: the social hub of the information superhighway

jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal