Hidden text in MacOS 11.3 beta suggests removal of Rosetta 2 compatibility layer in some countries

Researchers have discovered language buried in the forthcoming release of MacOS Big Sur 11.3 that suggests Apple may withdraw the Rosetta 2 binary compatibility layer in some regions. The text, discovered by writer and developer Steve Moser, says: “Rosetta will be removed upon installing this update.” Apple is removing …

[Anonymous Coward]

As a pure guess

This is TimApple preparing for a wave of sue balls heading their way from Intel who are very, very, very protective of their IP.

Could it be possible that Rosetta violates Intel's IP on their instruction set. After all, an instruction set is an API and the US Courts have ruled (Oracle vs Google) that API's are protectable by copyright.

It would be ironic if Rosetta is banned in just the USA. A wonderful advocate for MAGA (not).

[bazza]

Re: As a pure guess

X64 is not Intel's instruction set. It's AMD's, which Intel copied on a the back of an ancient IPR sharing settlement from the dark ages (well, last century). So I don't think it could be that exactly. I don't know enough about Macs to know if 32-bit X86 is relevant. That one is Intel's ISA. Then there's SSE / AVX, which are Intel's too. Again, AMD can freely snaffle these under the IPR sharing settlement.

Also there is QEMU, which I think implements the X64 and X86 instruction set on non-X64 hardware. That's not been sued to bits, but then again it's a project that hasn't got $billions to get nabbed by a court case.

It certainly would be ironic if Rosetta 2 got banned in the USA. It would do serious harm to Apple's ARM ambitions, and could indeed force a switch back to x64. If this originated with Intel, one could see Apple phoning up AMD and asking them about their fine range of processors...

[doublelayer]

Re: As a pure guess

"I don't know enough about Macs to know if 32-bit X86 is relevant. That one is Intel's ISA."

It's not really for two reasons. First, Apple made all apps 64-bit, refusing to run 32-bit ones in the penultimate release of Mac OS. Second, most of the X86 ISA has existed long enough that patents on it have expired. AMD64 is newer and may still have patents that can be infringed.

"Then there's SSE / AVX, which are Intel's too. Again, AMD can freely snaffle these under the IPR sharing settlement."

These are more likely targets if Intel were doing it, but I'm guessing that they already reviewed this stuff when Apple announced the ARM compatibility back in June if not months previously.

My guess is that it's not Intel angry about a loss of a large customer but instead some random company which has patented something related to emulation, which the U.S.'s broken patent system accepted. Now Apple's a juicy target and they can sue them. I would have guessed that Apple would defend that instead of destroying their emulation layer since they really need that to encourage their customers not to hold off adoption of the ARM kit, but Apple's lost patent fights before, sometimes with and sometimes without a good reason, so maybe not. Either that or they're going to pull it from somewhere to see how broken things get.

[Anonymous Coward]

Re: As a pure guess

"My guess is that it's not Intel angry about a loss of a large customer but instead some random company which has patented something related to emulation, which the U.S.'s broken patent system accepted. Now Apple's a juicy target and they can sue them."

Aren't Apple big and rich enough that they could just buy whatever patent troll is causing the problem, with pocket change? (And then turn the troll to stone and crumble it into dust for good, and entirely just, measure?)

[doublelayer]

Re: As a pure guess

Probably not since the troll concerned would know that Apple could buy them and then wreck their company. If they sue Apple and win, they get cash without any strings attached and can turn their attention to someone else. Apple's lost these patent battles before, often against very small companies, sometimes against companies who don't actually do anything. They have at least never chosen just to buy and destroy, and the operators likely wouldn't accept it either.

[Anonymous Coward]

Re: As a pure guess

That would be incredibly short sighted of Apple, and would encourage all kinds of frivulous nonsense lawsuits.

This is just another symptom of a bad patent system.

But this bad side is also very benefitial to large corporations patenting animations, so they need to accept the flies and bee stings with the honey.

[DS999]

Re: As a pure guess

As mentioned, Intel doesn't hold patents on x64 - though SSE 4.2 (which is the latest SIMD Rosetta 2 supports) would still be covered.

Though it seems unlikely that Intel would sue in countries other than the US, so it has to be something else. To my knowledge no one has ever commercialized static translation that Rosetta 2 does, but that doesn't mean someone didn't patent it. I'm not sure Intel even CAN sue Apple, given that they have a pretty broad patent cross license deal. I imagine that deal may exclude Apple from making a CPU that executes x86 directly but I highly doubt it stops them from offering Rosetta 2.

Given how lax patent standards are for obviousness, I wouldn't be shocked if someone patented "translating instruction set A to instruction set B prior to run-time and caching the result" and in some countries where the courts heavily favor their own companies (China? Russia?) Apple might figure they are likely to lose so better to drop the feature. Maybe they could seek a license to allow using it, but that's easier to do when they can show the patent owner they are willing to drop the feature if they don't get good terms.

[bazza]

Re: As a pure guess

I have a feeling that there's often restrictions in EULAs about "translation", and the forbidding of it. JIT gets away with it because there's no permanency to the translation, and fundamentally it's no different to what a modern CPU does with op code translation anyway. If Rosetta 2 is a static translation, then this might be what's causing the problem.

Take a look at Autodesk's EULA here, section 2.1.1:

"2.1.1 No License Granted; Unauthorized Activities. The parties acknowledge and agree that, notwithstanding anything to the contrary in this Agreement, no license is granted (whether expressly, by implication or otherwise) under this Agreement (and this Agreement expressly excludes any right) a) to Excluded Materials, (b)...... or (j) to translate, adapt, arrange, or create derivative works based on, or otherwise modify the Autodesk Materials for any purpose."

That clause j) is pretty solidly not compatible with a static translation. The question is, if one's OS is doing the translation for you, is it oneself who is breaking the EULA by using an OS that does this, or is it the OS developer? It would be pretty bad news for Apple if its customers started to get sued individually by software companies because of something that Apple had done and shipped without thoroughly explaining the risk the end user was taking.

[Anonymous Coward]

Re: As a pure guess

DEC had a system called FX!32 that worked pretty much like Rosetta 2 does, in order to run x86 NT apps on Alpha NT systems. It even was embedded in the Windows 2000 for Alpha beta releases before that product was canceled.

[bazza]

Re: As a pure guess

Aha, now that is interesting. If it is a patent thing, could that be prior art? I wonder if that ended up with HPE...

Let's us know if you get a call from Apple!

[DS999]

Re: As a pure guess

If it was abandoned before the release of Windows 2000 the patents will have all expired.

[bazza]

Re: As a pure guess

Still prior art though, in case someone else has got some sort of patent on the same basic idea. A later patent could be invalidated...

[bazza]

Seems Odd, and Big Question

Afterall, Rosetta 1 lasted for donkey's yonks without a murmour of trouble from what I recall. What's so significantly different about Roesetta 2? Or, is it that since the withdrawal of Rosetta 1 the legal landscape has changed, and what was once fine now no longer is?

Mysterious.

The question then is, if you're in a country where Rosetta won't get withdrawn but you travel to one where it will and you take the new iShiny with you, does that mean that MacOS will nuke that part of itself on realising that its in a different territory? Not that anyone is doing much travelling at the moment...

Ultimately I think that if there were some legal / patent issue, that could get over turned on a restraint of trade basis, though that might have to be done on a country by country basis. The "restraint" would be that the legal or patent situation is stiffling competition in the CPU market, by making it nearly impossible for vendors like Apple to switch. IANAL...

This could also have an impact on Windows on ARM, if that were to grow a similar translation layer.

[doublelayer]

Re: Seems Odd, and Big Question

Windows on ARM already has that. It was 32-bit only but has recently gained X64 compatibility. If that emulation is protected by patents, either Microsoft paid for them or they may face whatever Apple is theorized to be facing.

[bazza]

Re: Seems Odd, and Big Question

Well there we go. It's going to be very interesting to see what transpires. If both Apple and Microsoft get clobbered by this, well that's two very large and presumably annoyed corporations who might actually spend the money to overcome it. Nvidia too, if they acquire ARM.

[DS999]

Re: Seems Odd, and Big Question

The main difference with Rosetta 2 is that it does static translation - it converts an x86 binary into an ARM binary which is then directly executed. To my knowledge, this has never been done commercially before. Rosetta 1 did JIT (just in time) translation which is pretty much what everyone does for translating code, which is a lot slower but a lot easier. If there were patents on JIT they would have expired long ago.

[Doctor Syntax]

Re: Seems Odd, and Big Question

Could it be some software house that's decided it doesn't want its precious IP translated into a different instruction set? If so it' very short-sighted. Or is it? Opportunity to sell a new version...

[doublelayer]

Re: Seems Odd, and Big Question

I'm guessing not. If that happened, all Apple has to do is agree not to translate it and put in a precheck which rejects the binary, either running the JIT in volatile memory or refusing to run altogether. They don't need to turn it off for everybody if some companies want to be excluded. That's why I assume it's patent-related on something in the emulation process, and likely a laughably bad patent.

[katrinab]

Re: Seems Odd, and Big Question

Isn’t that basically a compiler, of which there are many?

It is compiling AMD assembly language rather than something like C, but from a legal point of view, is there any difference?

[J27]

Re: Seems Odd, and Big Question

It's recompiling AMD64 assembly language to ARM assembly. That's reverse-engineering, compiling is converting human-readable code to assembly.

I'm not qualified to answer the legal question, but from a technical perspective it's a different process.

[katrinab]

Re: Seems Odd, and Big Question

I don't think it is reverse engineering given that the AMD64 assembly was likely produced using XCode / clang.

clang is open source. XCode is produced by Apple; and Apple is one of the biggest contributors to clang.

Some of the technical challenges will be different, but legally, it is exactly the same as far as I can see.

[Anonymous Coward]

Re: Seems Odd, and Big Question

clang or gcc or free servers donated are irrelevant to an application binary. This is not friends helping out. :)

The license provision of the compiler used is completely irrelevant to the license provisions of the final application, (unless I suppose enforced by the compiler license, but then no one would use it for a paid application).

Also how much you contribute to the source base also does not give any extra “wiggle room” in the eyes of the law, unless that is written in the license agreement of clang (and it isn’t). “I contribute 1 million lines to the free compiler you used, so I get to do what I want with your app" does not fly in court, without a prior *accepted* agreement.

Reverse engineering is reverse engineering, the compiler used or the mac model used or the time of the day for compliing does not change this. so clang or gcc or cl is absolutely irrelevant, none of them link their license to the final output application. You could use visual studio to compile and make a GPL application, and you can use gcc to release a closed source paid application.

For all practical purposes, an application is already in machine code, unlike assembly code, which is still character text.

Rosetta 2 is translation of machine code itself, not a representation of it. So it is very different from the normal use of the word “compiling".

(If they have an intermediate step that dissassembles to text and then passes through a compile/assemble stage the term “compile” might apply, but that is their choice of implementation.)

The input to the system was binary machine code, and this no matter what the intermediate choices, the system is translating between binary machine code.

Legally it would be resonable expectation for an application license to only permit use of the application machine code as provided. Not to translate said machine code.

For example they could be free to charge different prices for different architectures. A translation layer like rosetta would circument this, and can be a breach of the license agreement of the application. Perhaps the developer wants to price the M1 version higher to support the development costs, instead of keeping people using rosetta and the cheaper x64 version.

So Rosetta is most certainly not the same thing as compiling legally. No source license or machine code licence is being provided, and how you fiddle the binary is certainly a legal question different to compiling.

[katrinab]

Re: Seems Odd, and Big Question

It is not reverse engineering because people know what AMD64 assembly language does and how it works, as evidenced by the fact that these compilers are available. A human could read a page of AMD64 assembly language, and by following the manual, execute it manually. It would be a slow and tedious process, but not a difficult one.

If you know what AMD64 instructions are required to execute a particular c command, and you know what AArch64 instructions are required to execute the same command, then you can figure out what AArch64 instructions are required to emulate an AMD64 instruction.

[doublelayer]

Re: Seems Odd, and Big Question

"It's recompiling AMD64 assembly language to ARM assembly. That's reverse-engineering, compiling is converting human-readable code to assembly."

I disagree. A compiler takes code of some type and converts it into code of a more usable type. That code could be human readable, such as C, or it could be automatically generated and difficult to read. Either way, it's in one language and is being translated. That doesn't require reverse-engineering because nobody is learning how it's doing what it's doing. Nor is it really new. It would count as creating a derivative work if a company is litigious enough, but other than that, I can't see it as really any different.

[Anonymous Coward]

Re: Seems Odd, and Big Question

But machine code isn’t a language, it is instructional. It is not about readability, it is about the semantics conveyed.

There is no compiler error ever in this translation process as the semantics were already ingested by the x64 compiler.

To translate to arm64, you need to look across multiple binary x64 values, *look at the specific architecture of x64*, and for that operation(s) or set of operations, split or combine them for another binary set (ARM64)

For eg say where you increment by 4 on x64, you decrement and bit shift by 3 on ARM64. It is reverse engineering to understand why it is 4 and that 3 is the right value for ARM64 (optimisation/register model/programmer/memory model/etc).

It is the referring back to the x64 architecture that makes it reverse engineering. The x64 machine itself is not representative as it has already assumed a single architecture.

(there is intermediate representation for eg in LLVM but that is specifically a format that accomodate multiple architectures. Or javabyte code + the VM) But rosetta is not in this territory - it’s x64 machine code input is purely instructional.

[doublelayer]

Re: Seems Odd, and Big Question

I disagree again. Two problems. First, it's still translation. I read a set of instructions and translate them into a different set of instructions. That's no different if it's a simplified language that only has a few thousand things it can do.

More importantly though, this distinction doesn't really matter to the question of whether it's reverse-engineering. You say "It is reverse engineering to understand why it is 4 and that 3 is the right value for ARM64". No, it's not doing that. It does not care why it is 4. It is 4 because the code says so and it doesn't care whatsoever other than making the ARM64 processor also use 4 and in an efficient way. Nor is it fair to call it reverse-engineering because "referring back to the x64 architecture". The writers of software don't own that architecture, and therefore they have no right to deny Apple the ability to read it. AMD could theoretically do so, but if they did, they'd have to do the same to all the emulators of X64 and they have not.

[mark l 2]

Surely emulating another CPU/System has been around for so long that any patents would now have expired and lots of prior art would exist for newly granted patents to make them invalid? I remember having emulators on my Amiga 500 in the late 80s which were emulating other CPUs such the Z80 used the Speccy but i suspect emulators go back well before even then.

[doublelayer]

You'd think so and you'd be correct. If only patent law was about correctness. In practice, if someone wrote up a patent which used enough jargon and filed it, it would get accepted by a lot of countries' patent offices until court proceedings. Some countries, notably the U.S., don't bother checking the validity of patents even once they're in court. Bring a technical looking person to the witness stand and have them jabber on about multilevel caches long enough to confuse the jury and they'll assume Apple is big so they must be stomping on this small startup. Profit.

[Anonymous Coward]

yes and no - emulation can be achieved by very many different techniques - each with their own story of good and bad.

Some of those techniques have now become practical as cpu power has boomed. these newer techniques can be subject to fresh and current patents.

rosetta needs to meet very high emulation performance, native speed of the les than 2 year old emulated architecture. it is a rather different story to emulating a 20 year old cpu.

[DJV]

"We’ve asked Apple for comment."

https://www.youtube.com/watch?v=nkUOACGtGfA

[Irony Deficient]

Rosetta is no longer available in your region.

Given that it used the word “region”, my first thought was that rather than being based upon a possible patent dispute, it might be based upon Apple complying with US export controls if Rosetta 2 uses cryptography of some kind to sign the Rosetta-translated binaries.

[Charlie Clark]

Re: Rosetta is no longer available in your region.

You win today's Occams Razor award.

[Anonymous Coward]

Re: Rosetta is no longer available in your region.

That’s unlikley as there has been no recent change to restrictions in applicable export controlled regions. Rosetta would *never* have been available, not no longer available.

Better suggestions are (1) apple’s regional licenses expiring (2) patent disputes as discussed (3) rosetta is cannibalising m1 app conversion so forced sunset

[Charlie Clark]

Re: Rosetta is no longer available in your region.

If you think about the export restrictions placed on sales to some Chinese companies? Both ARM and Intel are affected. It's not inconceivable that transpiling x86_64 to ARM could fall foul of such rules and it's not as if affected parties would be allowed to talk about it.

[Irony Deficient]

Re: Rosetta is no longer available in your region.

That’s [unlikely] as there has been no recent change to restrictions in applicable export controlled regions. Rosetta would *never* have been available, not no longer available.

The export-controlled regions might not have had recent changes, but the “information security” portion of the Commerce Control List * (which includes cryptography, both hardware and software) was last updated on 2020-12-04. It’s not the availability of Rosetta 2 that would be significant, but whether or not it uses export-controlled cryptography to sign translated binaries. If it doesn’t use export-controlled cryptography, then this theory would be moot.

* — The link is to a PDF document.

[theAltoid]

Urning

What in the good name of Jesus is "urn", as it quite clearly states

"Applications requiring Rosetta will no longer urn”

[AndrewB57]

Re: Urning

That's the notorious Grecian translation

I'll get my coat

[Irony Deficient]

Re: Urning

Presumably “urn” is an anagram of “run”, produced by mistakenly pressing “u” before “r”.

[Dave559]

Re: Urning

It's what you get when you type a little too quickly on a Muphrysoft keyboard (real or on-screen, either has this particular 'feature')…

[45RPM]

11.0.3, surely? On Apple’s past momentum, point releases are annual - and 11.3 would be two and a half years away. So if we’re talking two and a half years before Rosetta 2 gets deep sixed then I’m reasonably confident that the software developers of all current software (not just critical current software) will have caught up.

[Totally not a Cylon]

My MacBook Pro is currently running 11.2.2

so not that long away.....

[Smirnov]

On Apple’s past momentum, point releases are annual

That was the case with Mac OS X (with 'X' as in 'ten').

We're now at macos 11 and less than 6 months after release we're already at 11.2, so it looks like the old scheme no longer applies.

It will be interesting to see what this year's macos announcement will be, i.e., if we'll get a new version or if we'll from now on just Windows 10 just see continuous updates of Big Sur.

[Charlie Clark]

Re: On Apple’s past momentum, point releases are annual

As primarily a hardware company, Apple uses versions to deprecate old hardware to encourage users to buy new stuff. I expect that to be around for a while, even though I appreicate that it does have a reasonable record at supporting older hardware, at least when compared with other consumer products.

[45RPM]

Thanks for the clarification all - guess who’s stuck, unable to upgrade to 11?

[Charlie Clark]

Who says it's an upgrade? I still miss some of the stuff that worked properly in Snow Leopard…

[Charlie Clark]

Major apps…

Discord, LastPass, AWS Client VPN, Microsoft To Do, and Microsoft Teams

At least a couple of those are wrapped web views and one is just a configuration tool, hardly major headaches to port, compared say with Adobe Photoshop or OpenOffice, or anything that uses some of the kernel extensions that Apple has decided to outlaw.

While Apple has been trailing the APIs for the change for a while, it's going to be more than a simple recompile for many developers and Apple knows it, which is why the committed to 5 years support for Intel Mac. In the meatime there are a whole heap of bugs as a result of the change to the new architecture. This, along with waiting to see how much of a walled garden MacOS an ARM is, is what is stopping me from switching to MacOS 11.

[coconuthead]

Re: Major apps…

Photoshop 22 beta runs natively on M1 Macs:

https://helpx.adobe.com/au/photoshop/kb/photoshop-and-macos-big-sur.html#native-known-issues

Apple have been purging the APIs of nonportable stuff for several years now. For example, the provided calls for atomic increment and decrement were deprecated in 10.12, five years ago, with developers advised to use C++ std::atomic<> instead. Any use of a deprecated function results in a compilation warning.

The kernel extensions are going away for Intel as well.

The commitment to 5 years' support for Intel Macs is so that owners of existing machines have software to run.