The memory model itself isn't patentable; the TSO memory model already existed on x86, as well as many other architectures before that. Having an option to enable/disable TSO might be patentable, but it'd be a stretch; there's plenty of precedent for allowing a CPU to select between operating modes at runtime. (For example, many PowerPC parts could be switched between little-endian and big-endian modes at runtime, and some developers even used this to assist in emulating x86!)
What's more likely is simply that other ARM SoC vendors aren't implementing their own cores (e.g. they're using a standard Cortex-Ax design from ARM), so they can't add deeply integrated features like TSO themselves.
I mean, selectable, cheap, memory model changes are novel and I pretty much guarantee they have patents on some aspects of it. Depending on the patent there might be some cute ways to work around it, but it's going to take some work on your part. They might even have patents on other attempts to get to the same effect that they might have tried out.
PowerPC's biendianness would be patentable too if it had been an absolutely ancient technique about as old as computers themselves.
And there's people other than ARM and Apple making ARM cores. Samsung's Exynos M5 should be coming out before too long for instance.
TSO is just one part of Rosetta. Another significant performance win is that it’s sloppy with keeping the runtime out of the emulated address space to save on a (slow) software MMU, which may not be feasible for other implementations.
This is less a security thing and more an emulation fidelity thing. A “true” emulator will make itself invisible from the running program so that it runs as if it was on the real system, but a Rosetta program can do things like modify the emulator or control flow in ways that are not possible on a real system because the runtime is mapped into the same address space without protection. For most Mac software this is not a problem because they will not try to access wild memory or enforce mappings, but on other platforms I can see this being infeasible (on Linux I can imagine programs that get upset if they can’t control the full address space outside of what the kernel reserves, for example).
It's extremely standard for user space only emulators to not attempt to hide themselves from the emulated code. Every implementation I can think of that derives from HP Dynamo ideas doesn't attempt to since fundamentally you need to have the translated code cache mapped anyway to be able to execute it. You're never going to be able to hide yourself completely wiht any useful perf without transmeta like special mmu hardware that has completely separate translations for I and D fetches.
You can see how the build directories for qemu are {architecture}-softmmu for the full system emulators, and {architecture}-linux-user for the user mode emulators for another example of this but with Linux binary emulation.
They don't. A few other ARM CPUs implement TSO already (by default, due to their design), it's just not an architectural/standard feature that software can rely on.
Right, other cores implement TSO by (because a stupid simple core will be TSO sort of by default), but it's a pretty unique thing to have a runtime TSO switch.
And it'd be incredibly stupid of them not to have a patent on it unless there's some clear prior art for exactly their implementation since we're in a first to file system in the US. Otherwise they're asking for someone else to patent it and troll them for an easy cash grab.
My whole point as been around _selectable_ consistency, which is a rarity. Yes, there are many cores with stricter than necessary consistency, but very very very few allow you to switch consistency models at runtime.
Hence my original statement about the "cute _optional_ TSO memory model".
