8 ms·
The paper was laborious to read. The short of it seems to be that Linux used to perform floating point emulation on MIPS by writing instructions to run to the
by jstarks 8y ago
The paper was laborious to read.
The short of it seems to be that Linux used to perform floating point emulation on MIPS by writing instructions to run to the usermode stack. The stack therefore had to be executable. This is known to be a bad idea.
A couple of years ago, this code was moved from the stack to a new segment, but this segment is still writable and executable, and the address is fixed. This is known to be a bad idea.
And of course the stacks are still executable because the commonly-used compilers haven’t been updated to request non-executable stacks.
The paper does not propose a solution.
- amluto 8y agoThe “obvious” solution is to map that page RX and have the kernel write to it anyway because the kernel has magic kernel powers.
- blattimwind 8y agoOr map it twice. Once RX for usermode, once W at a random address for the kernel to write to. Some JITs use the same tactic.
- amluto 8y agoSome of the more extreme SELinux and similar policies don't like this either.
- tinus_hn 8y agoThe permissions are managed by the processor or the mmu. The kernel has magical powers to modify the permissions but can’t just ignore them.
- monocasa 8y agoHow about changing the ABI to something like the ARM soft float ABI. Yeah, it's got a few problems, but it's way better than all this crap.
- simias 8y agoI think that ship has sailed long ago, softfloat MIPS targets are almost certainly legacy hardware these days.
- monocasa 8y agoNope, 1004k/1074k is still the default vs the 1004kf/1074kf that includes the FPU. MIPS never really got out of their gate count niche that'd make an FPU a drop in the ocean.
- simias 8y agoInteresting, I'll admit that I haven't worked on a MIPS-based platform in a while. I suppose that with ARM becoming the de-facto standard for powerful embedded chips MIPS can only stay relevant in specific niches.
- Fnoord 8y agoIt is more widespread than you may assume. A lot of Ubiquity gear uses MIPS. Chips on hardware which are not the processor might be ARM or MIPS.
- wtallis 8y agoI think the only reason that MIPS is still found in WiFi gear is because 802.11ac was a 5GHz-only standard. Current WiFi routers and APs can get by with an old MIPS-based SoC with 802.11n 2.4GHz, plus a separate 802.11ac 5GHz NIC connected by PCIe. With 802.11ax, the MIPS-based WiFi SoCs will finally be obsolete, and all the newer WiFi SoCs are ARM-based. Ubiquiti and a few others are still using older Cavium Octeon network processors that are MIPS-based and don't have built-in WiFi driving their obsolescence. However, I think 2.5Gb/5Gb Ethernet will eventually push those products to adopt the newer ARM-based Octeon processors, leaving MIPS very dead in the networking world.
- saagarjha 8y ago> The short of it seems to be that Linux used to perform floating point emulation on MIPS by writing instructions to run to the usermode stack. The stack therefore had to be executable. Why is this necessary? I see no reason why you can’t emulate floating point arithmetic in software with no writable and executable segments at all.
- simias 8y agoI'm guessing that they want to avoid the overhead of handling the fault, context switching to the kernel, emulate the instruction (which may be tricky if it involves a memory access), context switch back to the application. Instead they can just emit the code into the address space of the process and patch the instruction with a jump to it. Maybe they can also "JIT" the instruction to emit optimized code for a particular invocation. That's just a guess though, I read sideways through the paper and I don't think they really explain that. They link to this page but it doesn't really give any details: https://www.linux-mips.org/wiki/Floating_point#The_Linux_kernel_and_floating_point https://www.linux-mips.org/wiki/Floating_point#The_Linux_ker... In particular I'm not sure why you'd want to put it in the stack instead of some allocated page dedicated to that endeavor (besides "it was already there so we used it").
- ajross 8y agoIt wasn't ever "necessary". There are perfectly working IEEE emulation libraries written in portable C that the compiler could have hooked instead. But they're likely several times slower than what was picked. NX stacks are a comparatively new idea, from an era when even embedded CPUs have lots of spare cycles. It hasn't always been that way. The lesson I took away from this isn't about architecture, it's that Linux on MIPS has a pretty severe shortfall in maintainer bandwidth for this to have gone unnoticed and unfixed. I mean, the first question in review of this patch should have been "OK, who's going to fix the stack permissions now?"
- caf 8y agoIt's not emulating the FP code itself that used this technique. The issue is that the emulated FP code can include FP branch instructions, and those FP branch instructions have branch delay slots, and the instruction in the branch delay slot can be an ordinary integer instruction like a load or store - that has to be done with user permissions - and it can even be an instruction from some weird extension to the ISA that the kernel might not have heard of. It's executing those branch delay slot instructions, in the branch-taken case, that uses this W|X page.