Rosetta Kernel uses TCPA

[Brickster]

We found out that the Rosetta kernel uses TCPA/TPM DRM.

Currently their are no ways known to get the GUI working on non-Apple hardware, with this protected kernel.

Even with a SSE3 enabled cpu you will never get the GUI.

Read more about TCPA here: http://www.againsttcpa.com/tcpa-faq-en.html

[q_x]

Yuck, that's sad :-(. How did you find out?

[Brickster]

It's on the wiki and they confirmed it in the IRC channel.

[DeathChill]

Post edited due to implied violation of the DMCA.

 

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

 

See Forum Rules for more information.

[trongod05]

So what you are saying is that original Apple commercial in 1984 is about the customer trying to overcome Big Brother Apple in the future?

[paulpaul]

I truly have mixed emotions about this... A bad emotion because you guys can't run Mac OS X on a normal X86 computer (so I would like because Mac hardware is quite too expensive for me) but maybe also a good emotion that Apple's future will be safe and sound.

 

Notice that people buy Macs just because of the OS. The computers are well durable, but they do not compare to the average people who go and grab a Dell for a few hundred.

 

But TCPA truly is deceiving. The future doens't seem open. And with quirky laws such as "The Patriot Act", maybe we are becomming like communists.

[trongod05]

I would say the community are communist and Apple is now fascists. The exact opposite of what they seemed to want in 1984.

[Malus]

Was just going to point out that it was more like Fascism than Communism...

[paulpaul]

Was just going to point out that it was more like Fascism than Communism...

 

Pardon me. I didin't study all these classes.

[ardosdev]

Post edited due to implied violation of the DMCA.

 

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

 

See Forum Rules for more information.

[Ekylypse]

Post edited due to implied violation of the DMCA.

 

Posting that in anyway implies a violation of the DCMA will not be permitted in this forum.

 

See Forum Rules for more information.

[rexhite]

What's this about the "Rosetta" kernel using TPM? What's the "Rosetta" kernel?

 

Isn't Rosetta Apple's binary translation solution to allow PPC OSX apps to run on OSX x86?

 

What does Rosetta have to do with OSX x86 as far as booting up and running with the GUI?

 

Is Rosetta now some integral part of OSX x86?

 

Or has the original poster confused OSX x86 with Rosetta?

 

Or is Rosetta functionality the only thing locked out through some sort of TPM?

[blex0r]

What's this about the "Rosetta" kernel using TPM?  What's the "Rosetta" kernel?

 

The mach kernel in the Developer Kits automatically launches Rosetta when trying to run PPC-only binaries instead of showing that "Can't execute binary file" error message. The latest open source versions of Darwin (8.1, 8.2) don't have such a functionality, it seems like you can still launch Rosetta manually (./oah750 binaryfile) but we can't be sure about that as Rosetta isn't currently running because of the TPM issue.

 

Isn't Rosetta Apple's binary translation solution to allow PPC OSX apps to run on OSX x86?

 

Yes, it is.

 

What does Rosetta have to do with OSX x86 as far as booting up and running with the GUI?

 

An essential service for running the GUI like ATSServer is not ported to the x86 architecture, so it runs emulated by Rosetta in the Developer Kits. No Rosetta, no text rendering, no GUI.

 

Is Rosetta now some integral part of OSX x86?

 

Or has the original poster confused OSX x86 with Rosetta?

 

At the moment, it is. Perhaps Apple will port ATSServer in the future, but we can't currently run the GUI without Rosetta.

 

Or is Rosetta functionality the only thing locked out through some sort of TPM?

 

I don't know, i haven't found more binaries asking for the TPM, only oah750d, but maybe there are or there will be more ones. Another thing that seems related to the TPM chip is that a lot of binaries are signed in some way probably during the installation procedure as they don't match the checksums in the bom files and they're different between kits. And the different bytes between two copies of the same signed binary from different kits are the same in each case for every signed file, so if the signature corresponding to a devkit is 0xAABBCC, it will be the same for every signed file in that devkit. We're trying to identify a pattern in the signature's location as it is not at the same offset in every files. It seems to be found in the LINKEDIT section (only Mach-O executables and libraries are signed).

 

Regards, blex0r

[rexhite]

Thanks for the answer.

 

Does that mean that on the development machines, the OSX GUI is not running natively, and presumably has compromised performance?

 

If so, that implies (to me) that the OSX GUI will eventually be native to the x86. But, if that's the case, how might this current limitation impact developers currently using the Mac Dev kit as it runs now? Or are all applications developed for OSX (PPC or x86) totally independent of the GUI's acceleration, and the fact that the OSX x86 GUI is running through Rosetta is of no consequence, either for performance or application development? And if that's the case, is there no benefit to be had from removing the Rosetta pathway for the GUI?

 

In other words, is Rosetta going to be one of the the keys to Apple's attempts at locking out generic hardware, or is there too much of a penalty running the GUI through Rosetta for production Macs?

[cl63pbx]

Thanks for the answer.

 

Does that mean that on the development machines, the OSX GUI is not running natively, and presumably has compromised performance?  

 

If so, that implies (to me) that the OSX GUI will eventually be native to the x86. But, if that's the case, how might this current limitation impact developers currently using the Mac Dev kit as it runs now?  Or are all applications developed for OSX (PPC or x86) totally independent of the GUI's acceleration, and the fact that the OSX x86 GUI is running through Rosetta is of no consequence, either for performance or application development? And if that's the case, is there no benefit to be had from removing the Rosetta pathway for the GUI?

 

In other words, is Rosetta going to be one of the the keys to Apple's attempts at locking out generic hardware, or is there too much of a penalty running the GUI through Rosetta for production Macs?

I think that currrently, in these dev machines, Apple implemented TC in Rosetta to make sure that people won't succeed in what we are doing right now, trying to run the GUI on non-Apple hardware.

And of course there would be performance penalty in the GUI so the performance of the current Tiger intel is still a bit far from the real Mactels we will see next year(if the first releases are projected next year). The performance of the dev machines are not so important since they are for developers to develop mactel enabled programs beforehand, and Apple strictly announced that no performance report should be done using these machines. I believe that real mactels will have native implementations of the GUI, and maybe a more strict TCPA lock on some other crucial programs to prevent the retail version of Mac OS X for mactel to be run on non-Apple hardware.

 

These are my own opinions of course.

[bofors]

What does Rosetta have to do with OSX x86 as far as booting up and running with the GUI?

 

An essential service for running the GUI like ATSServer is not ported to the x86 architecture, so it runs emulated by Rosetta in the Developer Kits. No Rosetta, no text rendering, no GUI.

 

Is Rosetta now some integral part of OSX x86?

 

Or has the original poster confused OSX x86 with Rosetta?

 

At the moment, it is. Perhaps Apple will port ATSServer in the future, but we can't currently run the GUI without Rosetta.

 

This seems like a very odd scenario considering the historical development of OS X for x86. I mean, Apple should have already had ATSServer "ported" in my mind. In fact, I do not think that porting per se would even be necessary at this point as we know that OS X has been co-developed to run on x86 from the beginning.

 

Has anyone else independently verified that the OS X86 is actually running PPC ATSServer? It be nice if someone with access to an Apple Transition Kit system could actually verify that Rosetta is indeed running the GUI.

[Ekylypse]

Or maybe they're never going to convert it and this is how they've managed to stop us from running it on any straight off the market Dell Computer. Good way to do it but if we manage to get a hold of a Dev Kit then we should be able to emulate it....

[bofors]

Personally, I believe that the more people running OS X the better and that projects like this (or PearPC) actually help Apple gain market share. At this point, it seems unclear how serious Apple will be about preventing OS X86 from being run on generic hardware. This is the first word of anything being done to specifically prevent it, other than the expected technical barriers with drivers and hardware requirements.

 

If Apple does actually want to use some sophisticated TC to tie OS X86 to it's own hardware, why not do it directly? The idea of tying it down via Rosetta seems overcomplicated and besides, the entire GUI should be native for speed and over all system performance that is expected to be burdened by running non-native apps.

 

As far as an ATSServer "port" goes, on a cursory web search, I can not tell for sure if ATSServer was orginally part of NextStep, OpenStep or Rhapsody. But there is some evidence which suggests that is was and which would mean that it existed for x86. So, with the exception of the report being made in this thread, we have many good reasons to expect that ATTServer for x86 already exists.

 

However, it certainly is possilbe that Apple is running PPC ATSServer in the Transition Kit OS X86 for some unknown reason. Perhaps the current x86 ATSServer has some bugs that are still be worked out or even that Rosseta works better with PPC ATSServer. I mean, I think we know that Rosseta only works with code that is entirely PPC and not PPC-x86 hybrids. So, if the PPC code is linked to x86 ATSServer, maybe Rosetta would consider that hybrid code thus necessitating a PPC version of the ATSServer. But that should not preclude an x86 ATSServer for use with native applications and OS X86 itself.

 

Edit: Spelling of "Rosetta"

[rexhite]

I guess it means that the leaked hard drive image, plus the necessary OSX GUI files from OSX Tiger PPC version, plus a working Rosetta ought to be a theoretically complete developer system.

 

Is Rosetta built upon an open source project? If it were, then I suppose the best pathway to running OSX x86 on generic hardware would be substituting Rosetta with a non proprietary version.

[blex0r]

Does that mean that on the development machines, the OSX GUI is not running natively, and presumably has compromised performance?

 

ATSServer is a lightweight part of the OS X GUI and although it's run emulated I don't think it to be compromising the performance at all. Remember that it has been reported that some programs like Firefox run faster emulated on the Developer Kits than native on a Powermac G5 (I'm talking about the ppc version of Firefox, not about the universal binary that came out later).

 

If so, that implies (to me) that the OSX GUI will eventually be native to the x86. But, if that's the case, how might this current limitation impact developers currently using the Mac Dev kit as it runs now?

 

It should not have any impact in the development as applications are not aware of ATSServer being run emulated or native.

 

And of course there would be performance penalty in the GUI so the performance of the current Tiger intel is still a bit far from the real Mactels we will see next year(if the first releases are projected next year).

 

We're not talking about the entire GUI but the Type Server. WindowServer is native, Quartz is native, key GUI apps like loginwindow or the Finder are native. ATSServer is the only component of the GUI that we have found being not native.

 

I mean, Apple should have already had ATSServer "ported" in my mind.

 

They aren't likely to need nothing more than clicking a checkbox in Xcode to generate an ATSServer universal binary. They're talking about much larger and complicated apps being ported to x86 by changing no more than 20 or 30 lines of code. I don't think porting ATSServer to be a problem at all.

 

So, if the PPC code is linked to x86 ATSServer, maybe Rosseta would consider that hybrid code thus necessitating a PPC version of the ATSServer.

 

ATSServer is not a library but a daemon. Processes communicate with it via IPC mechanisms. Rosetta emulated processes shouldn't have problems to communicate with native ones at all.

 

Is Rosetta built upon an open source project? If it were, then I suppose the best pathway to running OSX x86 on generic hardware would be substituting Rosetta with a non proprietary version.

 

It is not. There's an open source project called SoftPear that aims to create a ppc to x86 recompiler and a compatibility layer between OS X/ppc and Linux, FreeBSD and Darwin x86, in a similar way to wine's. However it's still in its very early stages of development and it can't run many more ppc executables than gzip, ls... I don't think it to be capable of running ATSServer and doing it well enough. I couldn't even compile it in Darwin/x86.

 

Regards, blex0r

[Swad]

We've now tested the "signature" on files from 3 different machines, and they are all different.

[sblr]

I think we know that Rosseta only works with code that is entirely PPC and not PPC-x86 hybrids.

Incorrect.

As stated in the x86 programming guidelines PDF, you can force a Universal binary to use Rosetta. IIRC, this can be set from the Get Info box in the finder.

[Pentad]

We've now tested the "signature" on files from 3 different machines, and they are all different.

 

Mashugly,

 

Thanks for keeping us informed! Could you clarify your last statement? I'm not sure I'm following you. Do you mean the "signature" is a watermark from Apple or that the "signature" is used with the DRM Intel chip?

 

Thanks,

P

[bofors]

We're not talking about the entire GUI but the Type Server. WindowServer is native, Quartz is native, key GUI apps like loginwindow or the Finder are native. ATSServer is the only component of the GUI that we have found being not native.

 

I mean, Apple should have already had ATSServer "ported" in my mind.

 

They aren't likely to need nothing more than clicking a checkbox in Xcode to generate an ATSServer universal binary. They're talking about much larger and complicated apps being ported to x86 by changing no more than 20 or 30 lines of code. I don't think porting ATSServer to be a problem at all.

 

So, if the PPC code is linked to x86 ATSServer, maybe Rosseta would consider that hybrid code thus necessitating a PPC version of the ATSServer.

 

ATSServer is not a library but a daemon. Processes communicate with it via IPC mechanisms. Rosetta emulated processes shouldn't have problems to communicate with native ones at all.

 

Great information! But then why would Apple be screwing with PPC ATSServer on OS X86?

 

As far as we know, is the ATSServer server the ONLY thing missing to get the GUI running?

 

To the extent that you are suggesting that ATSServer is relatively simple, is it possible for a replacement to be created? I mean do we know enough about its interface and function to even consider such an approach? Is there something comparable in Linux?

 

Alternatively, would it be possible to run PPC ATSServer as a PearPC process (instead of Rosetta) inside of OS X86?

[bofors]

I think we know that Rosetta only works with code that is entirely PPC and not PPC-x86 hybrids.

Incorrect.

As stated in the x86 programming guidelines PDF, you can force a Universal binary to use Rosetta. IIRC, this can be set from the Get Info box in the finder.

 

I did not mean switching between the PPC and x86 codebases of a Universal binary for an application as a whole, but rather a composite application that has unique x86 and PPC parts. I believe that Rosetta will not work to emulate (or translate) a block of PPC code in a native x86 process.