Slashdot Mirror

Not really. Apple uses Mach as a HAL. All process management is done by the monolithic BSD kernel which runs atop Mach

The runnable entity in the Mac OS X kernel is a Mach thread, which is further separated into a shuttle and an activation. Threads are contained in Mach tasks. BSD-style process abstraction is retrofitted by associating a process structure with each Mach task, among other things.

Be fair, the grandparent said "MacOS has a micro kernel", and technically that is correct.

Sorry, that's not correct.

XNU's Mach component is based on Mach 3.0, although it's not used as a microkernel.

Also the Darwin kernel, i.e. BSD on Mach, is already open source. Even though BSD is BSD not GPL licensed and they'd be legally allowed to keep their very extensive changes secret, Apple still release their changes

https://opensource.apple.com/s...

The don't release all the kernel mode code though - e.g. they don't release the source code to "Dont Steal Mac OS X.kext"

http://www.osxbook.com/book/bo...

They also don't release the source code for the user mode stuff, but then they don't have to.

And it seems like they already get the benefit of any 'many eyes make all bugs shallow' effect from opening up the kernel.

'Many eyes make all bugs shallow' is bogus anyway. It's not like many people are going to sit, read the source to something and find a vulnerability. And even if they did there's nothing to stop them selling it to someone other than the vendor - e.g. Russian/Chinese mafia, NSA, GCHQ etc probably all pay better.

You didn't have to post, but you did. You reign supreme. Thank you for this post... made the last 30 minutes of boredom totally worth it. Its not that the post is all that great, literarily speaking, But the GP is not just a moron, but a moron that goes around spreading bullshit... shit they just made up... preaching it, teaching it, and misleading others, possibly. So your post is exemplary in that it shuts down the bullshit quite well.

I'm now quoting your post in all its glory. Thanks again, I wish more were like you.

it's part of the OS

When was the last time YOU wrote a fuckin' bootloader? Last time I did that was oh, about... a week ago. It most certainly IS a separate piece of code--maybe bundled with other bits of the OS, but it isn't the same binary. A bootloader needs to be SMALL. A kernel can be quite LARGE (and that is the OS *proper*).

Citation, because I fully expect you to be a dumb shit and claim I'm wrong:

BootX (/System/Library/CoreServices/BootX) is the default bootloader on Mac OS X.

BootX is also the name of an open source bootloader (different from Apple's BootX) that allows dual-booting Mac OS and Linux on "Old World" machines.

At this point, BootX draws the Apple logo splash screen, and starts the spinning cursor. If booting from a network device, a spinning globe is drawn instead.

        Depending on various conditions, BootX tries to retrieve and load the kernel cache file.

        The next step is to "decode" the kernel. If the kernel header indicates a compressed kernel, BootX tries to decompress it (typical LZSS compression is used, as you compress this kind of data once but expand it many times). Since the kernel binary can potentially be a "fat" binary (code for multiple architectures residing in the same binary), BootX checks if it indeed is (fat), and if so, "thins" it (figures out the PowerPC code).

        BootX attempts to decode the file (possibly "thinned") as a Mach-O binary. If this fails, BootX also tries to decode it as ELF.

        If the above fails, BootX gives up, draws the failed boot picture, and goes into an infinite loop.

        If BootX is successful so far, it saves filesystem cache hits, misses and evicts, sets up various boot arguments and values (such as whether this is a graphical or verbose boot, whether there are some flags to be passed to the kernel, the size of installed RAM), and also calls a recursive function to flatten the device tree.

        Finally, BootX "calls" the kernel, immediately before which it "quiesces" Open Firmware, an operation as a result of which any asynchronous tasks in the firmware, timers, or DMA get stopped, etc.

If you mean bundled the same way OS X is, then GRUB is part of the OS too, since distros package it up with the kernel.

You fail. Please do not ever write system software because it would be worse than The Poettering. This comment is on par with you claiming that iOS is part of the "Linux theme". FFS, you keep showcasing how ignorant you are about system dev, so please do us all a favor and SHUT THE FUCK UP.

The worst part is that you make some pretty intelligent comments--until you get into talking shit out of your ass about things you clearly don't know diddly about. So again, SHUT THE FUCK UP.

it's part of the OS

When was the last time YOU wrote a fuckin' bootloader? Last time I did that was oh, about... a week ago. It most certainly IS a separate piece of code--maybe bundled with other bits of the OS, but it isn't the same binary. A bootloader needs to be SMALL. A kernel can be quite LARGE (and that is the OS *proper*).

Citation, because I fully expect you to be a dumb shit and claim I'm wrong:

BootX (/System/Library/CoreServices/BootX) is the default bootloader on Mac OS X.

BootX is also the name of an open source bootloader (different from Apple's BootX) that allows dual-booting Mac OS and Linux on "Old World" machines.

At this point, BootX draws the Apple logo splash screen, and starts the spinning cursor. If booting from a network device, a spinning globe is drawn instead.
        Depending on various conditions, BootX tries to retrieve and load the kernel cache file.
        The next step is to "decode" the kernel. If the kernel header indicates a compressed kernel, BootX tries to decompress it (typical LZSS compression is used, as you compress this kind of data once but expand it many times). Since the kernel binary can potentially be a "fat" binary (code for multiple architectures residing in the same binary), BootX checks if it indeed is (fat), and if so, "thins" it (figures out the PowerPC code).
        BootX attempts to decode the file (possibly "thinned") as a Mach-O binary. If this fails, BootX also tries to decode it as ELF.
        If the above fails, BootX gives up, draws the failed boot picture, and goes into an infinite loop.
        If BootX is successful so far, it saves filesystem cache hits, misses and evicts, sets up various boot arguments and values (such as whether this is a graphical or verbose boot, whether there are some flags to be passed to the kernel, the size of installed RAM), and also calls a recursive function to flatten the device tree.
        Finally, BootX "calls" the kernel, immediately before which it "quiesces" Open Firmware, an operation as a result of which any asynchronous tasks in the firmware, timers, or DMA get stopped, etc.

If you mean bundled the same way OS X is, then GRUB is part of the OS too, since distros package it up with the kernel.

You fail. Please do not ever write system software because it would be worse than The Poettering. This comment is on par with you claiming that iOS is part of the "Linux theme". FFS, you keep showcasing how ignorant you are about system dev, so please do us all a favor and SHUT THE FUCK UP.

The worst part is that you make some pretty intelligent comments--until you get into talking shit out of your ass about things you clearly don't know diddly about. So again, SHUT THE FUCK UP.

Here's an example of Windows 3.1 for those who are wondering. Similar to Win 8/9/10, notice how it's visually awkward to distinguish between windows: http://osxbook.com/book/bonus/...

As another example, their "right thing" in terms of the core functionality of their products, the OS, was not so much "built" as outright stolen (in every sense but the technical legal one) from tens of thousands of contributed man-years of altruistic BSD developers with actual talent, both being attributes which Apple utterly lacks, as proven by who needed to steal what from whom.

Apple (and NeXT before them) owe a lot to BSD, but this is just disingenuous. You can't "steal" something that is freely given, and in terms of what Apple used from BSD, they "stole" less than FreeBSD/OpenBSD/NetBSD did. Not to mention that when NeXT started out, Unix was not free and they paid AT&T for a license.

Compare the functionality of any BSD variant to Mac OSX and you'll see just how much Apple/NeXT built. To save you time: IOKit, Core Foundation, AppKit, Carbon, Cocoa and Cocoa Touch, Quartz, Quicktime, etc.
http://osxbook.com/book/toc/toc.html

get a mac: http://www.osxbook.com/book/bonus/chapter10/tpm/

At the time of this writing (October 2006), the newest Apple computer models, such as the MacPro and possibly the revised MacBook Pro and the revised iMac, do not contain an onboard Infineon TPM. Apple could bring the TPM back, perhaps, if there were enough interest (after all, it is increasingly common to find TPMs in current notebook computers), but that's another story.

Exactly. See for example:
http://en.wikipedia.org/wiki/History_of_Mac_OS
http://osxbook.com/book/bonus/ancient/whatismacosx/history.html
http://applemuseum.bott.org/sections/codenames.html

So the versioning becomes slightly obvious, as do the names.

Microsoft is a bit less so -- they keep a consistend internal versioning system, but the "product" names are pure marketing.

Linux distros tend to waffle between pure versioning and attempting to be like Apple or Microsoft -- which makes sense, as there's no one vision driving them all.

Apple did go to some lengths to make it hard running OS X on vanilla x86 systems. Like, AES-encrypting various system kexts and making it impossible to dump the memory of DSMOS driver to get the decryption keys.

If you really believe that Apple Protected Binaries should be a problem for the typical Slashdot reader, then this is your lucky day. And if you don't really believe what you are saying (which is what I suspect is the case), then quit spreading your FUD.

I wonder where the term Reality Distortion Field comes from.

Why, from the Apple Haters, of course.

Next foot-in-mouth question?

shipped the very first Intel macs with Bootcamp

While trying hard to make it impossible to run Mac OS X on any non-Apple device...

You really DO need to come out of your Mom's basement once in awhile and update your Apple Hater rhetoric.

If you are referring to the long-dead DRM rumor regarding the dormant TPM chips in the original Intel-designed reference designs that Apple "leased" to Developers right after the Intel-switch was announced, you do realize, of course, that there was never any software (including OS X itself) that used that TPM chip, and that hardware was quickly rev-ed out of the mobo designs.

Instead, we have a robust Hackintosh community, that Apple has, by and large, utterly ignored.

Do you really think that, with their ability to have custom-silicon designed and fabricated, Apple couldn't make it utterly impossible to put OS X on non-Apple hardware? Get real!

I thought it was a Mach kernel and a BSD userland. How exactly that's quintessentially different from me installed Cygwin on my Windows machine and calling it a Unix machine is beyond me.

http://en.wikipedia.org/wiki/XNU

http://osxbook.com/book/bonus/ancient/whatismacosx//arch.html

Apple doesn't actively prohibit "rooting" of their devices.

http://gizmodo.com/303171/apple-says-unlocked-iphones-will-brick-after-software-update-+-what-does-it-mean

From the linked article:

"But first, the bricking. Was this done on purpose? Lam doesn't think so. Jacqui at Ars believes that the firmware was completed weeks ago, and the bricking is unintentional."

Apple doesn't pursue the iOS "hacker" community with legal threats, DMCA takedown notices, etc.

http://news.cnet.com/apple-iphone-jailbreaking-violates-our-copyright/

Partially true. Apple did say this, and a Federal Court disagreed. Apple however, didn't appeal the decision, and unlike many Android device manufacturers, has not done an end-run around that decision by putting "fuses" in their microcontrollers, signed bootloaders, etc.

So, it seems that Apple had one opinion, and the Feds had another, but in the end, Apple respected the process. It sure seems like those other manufacturers are simply taking a disingenuous advantage of the fact that the lawsuit didn't name them, specifically, and that Android users (and curiously, the EFF) seem to be disinterested in pursuing the issue. Wonder why? Could it be that the EFF has an Anti-Apple bias? Nah, couldn't be!

Apple doesn't infest its products with an OS (Windows 7) that has DRM from the driver-level up.

http://tech.slashdot.org/story/05/08/01/0421248/Mac-OS-X-Intel-Kernel-Uses-DRM

Wow! Old story much?!? How long did you have to search for that one!?!

If you look at the article, you will see that that referred to the DEVELOPER PREVIEW PLATFORMS when Apple did the Intel Switch. The TPR protection did NOT make it into the actual RELEASE CODE. Obviously, Apple had a pretty strong interest in keeping their very-restricted Beta release OS protected. Let's see what that actually ended up being in the RELEASE code. A simple deleteable file and deletable kernel extension that says "Please Don't Steal OS X". Wow. Some DRM! This article refers to TPR on OS X as "The Myth That Won't Die." And of course, the very existence of Hackintoshes kinda belies strong TPM protection, doesn't it?

As I said: DISinformative. But his post is modded +5 Informative, and mine will be punish-downmodded, of course.

Like Everest, because it was there.

There was a GIF out several years back, which I haven't been able to find any time recently (and would love a pointer to) of some guy who had something like *19* hardware emulators running on one monitor simultaneously, in 4 or 5 separate stacks.

TRS-80, C-64, T/S-1000; everything you've ever seen an emulator for, he had running on Linux all at the same time; some hosting others.

Dunno about that one, but here's Amit "Mac OS X Internals and MacFUSE" Singh running a large pile of x86 OSes on top of Virtual PC on a PowerBook.

It would be nice if your story was true.
http://www.osxbook.com/software/hfsdebug/fragmentation.html
Take a look at the table1, the G5 fs is nearly full, resulting in "lots" of fragmentation. AFAIK no FS is immune to fragmentation when it is being filled to capacity, but it seems HFS is better at avoiding it than most.

Understanding Apple's Binary Protection in Mac OS X

With the advent of Intel-based Macintosh computers, Apple was faced with a new requirement: to make it non-trivial to run Mac OS X on non-Apple hardware. The "solution" to this "problem" is multifaceted. One important aspect of the solution involves the use of encrypted executables for a few key applications like the Finder and the Dock. Apple calls such executables apple-protected binaries.

OS X also forced me to modify the boot loader for 64-bit support on a Mac Mini (which I needed to test on)
I can't really see any reason for the blacklisting

Could you perhaps link to the OS X bootloader source? AFAIK Apple does not make the source for boot.efi available

That is startling!

:-)

Having read through the original article, all of its comments, the linked article on TRIM and performance degradation and the score-over-3 comments herein, I'm surprised that nobody has pointed to this:

http://www.osxbook.com/software/hfsdebug/fragmentation.html

The description of the mechanisms HFS+ uses to avoid fragmentation are reminiscent of TRIM's operation from the drive's perspective and the garbage collection scheme used in Samsung's ARM controller, assuming bit-tech.net's description of these is accurate. It therefore comes as little surprise to read anecdotes from numerous users with both factory and third party ("fast" / "non-Apple firmware") SSDs where little performance drop is seen in OS X, along with a series of tests showing similar results and importantly, so far, no anecdotes or test results showing the opposite.

The absence of claims of degrading SSDs under OS X is a surprise and suggests that there really is a performance advantage with SSDs and HFS+ where TRIM is not in use. Adopting TRIM support might improve matters further, of course.

The bit-tech.net tests did still have numerous annoying omissions; this doesn't invalidate them but it does leave questions hanging. It would have been worthwhile partitioning most of the factory drive for NTFS and re-testing under Boot Camp. It would have been even more worthwhile getting one of the SSDs which showed the worst non-TRIM "dirty" performance under Windows and testing that under Mac OS X; if this wasn't possible on the Air hardware for some reason, they could've done it on the Macbook Pro they used as an HDD baseline in the first series of tests.

BTW, Singh's OS X Internals is a great book if you want to learn more about the innermost parts of the OS.

Mac hardware is outright out because it has a TPM. I loathe the idea itself of it, and refuse to buy any hardware that has it.

Apple hardware hasn't included TPM since 2006. (Trusted Computing for Mac OS X)

That's widely known, but wrong: http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/

Apple has been using EFI in its intel based Macs since 2006. The EFI firmware allows the use of emulation modules so that, as an example, Mac EFI has a BIOS emulator allowing Macs to boot into Windows. On Macs the BIOS emulator is not perfect as there is no way you can actually edit or modify it without running the risk of bricking your machine after damaging the firmware, but there is an open source EFI interface for Macs called rEFIt that allows you to boot to a boot menu from where you can boot into Mac, Windows or Linux for example.

Amit Singh has written a book on prgramming the EFI interface on Macs which, for anyone considering getting into EFI programming is a good point to start with. Armed with a second hand Intel Mac Mini from ebay, you could get a head start by the time MSI release their motherboards.

I came across a possible explanation. Andrew Fish (the man credited with inventing EFI) is quoted saying:

...Open Firmware was not without its own technical challenges. The PC had started down a path of using the Advanced Configuration and Power Interface (ACPI) as its runtime namespace to describe the platform to the operating system. As I liked to say at the time, the only thing worse than one namespace is keeping two namespaces in sync. The other problem was the lack of third party support for Open Firmware. We invited the FirmWorks guys to come visit us at Dupont (WA), and we had a great talk. Given we had just gone through an exercise of inventing a firmware base from scratch, I think we were uniquely qualified to appreciate what Open Firmware had been able to achieve. Unfortunately, it became clear that the infrastructure to support a transition to Open Firmware did not exist. Given the namespace issue with Open Firmware and the lack of industry enabling infrastructure, we decided to go on and make EFI a reality.

The Macintosh hardware contains one chip containing a key, and MacOS X checks for the existence of the key. Now with virtualisation, the virtualisation level _must_ pass access to this chip down to the real hardware, otherwise MacOS X won't install. Passing the access through to the real chip is legal, because it only allows the end user what the license allowed him or her to do anyway.

Macs do not use a TPM chip to control whether or not you can use OS X on them. Newer Macs don't even have a TPM chip on board.

The Macintosh hardware contains one chip containing a key, and MacOS X checks for the existence of the key.

No it doesn't

OS X checks for an EFI firmware (not a functioning one either, just an EFI firmware that responds to a few calls) and boots on that.

It can also boot on a machine with a regular BIOS - in fact VMware Fusion 1 and 2 used a fairly generic BIOS image in the darwin.iso that it boots from, it wasn't until VMware Fusion 3 that the darwin.iso contained a full EFI implementation.

As far as I know, Apple dropped "trusted" computing support in 2006. They dropped DRM for iTunes in 2009. And of course MacOS X is based on FreeBSD and major portions of the OS are open source.

So the fact that they make a few completely closed products doesn't fully characterize their entire culture of openness vs. closedness. The truth is more complicated. I am no Apple fanboi (I'm a Ubuntu fanboi) but I consider MacOS to be a lot more "open" than Windows, in some ways at least. For instance, MacOS ships with development tools.

The Xnu kernel:

http://osxbook.com/book/bonus/ancient/whatismacosx//arch_xnu.html

WTF are you talking about? There are no encrypted binaries involved.

Mac OS X has them; I assumed that Windows might have started to do the same. I just assumed that Microsoft was doing something alongside Protected Video Path and Protected User Mode Audio in Windows Vista and Windows 7 to satisfy nine major publishers of non-software works. And even if Microsoft doesn't currently use encrypted binaries or encrypted installers, once this workaround for 17 USC 117 becomes more widely known, it will.

Googling for these mysterious keys turned up nothing.

Is Apple lying to the court?

You're just looking in the wrong places. There are two 128-bit constants stored in the System Management Controller chip (alongside fan speeds and temperature info) in the keys "OSK0" and "OSK1"; the first time someone accidentally dumped these seems to have been in this forum post. The scheme is documented a bit further in a couple of artictles: "TPM DRM" In Mac OS X: A Myth That Won't Die and Darwin/x86: Mac OS X Binary Protection. I'll leave it to you to manually decode the keys into ASCII, but will point out that they are normally retrieved from the hardware by a kext called "Dont Steal Mac OS X.kext". The reason your "special bootloader" works on vanilla hardware is that it replaces that kext with a version that contains the keys hardcoded into it; it will never install on any machine without replacing or patching that kext, EFI or not. (All of the bootloaders that can use unmodified installation media patch or inject this kext before passing control to the loaded XNU kernel.)

If you've gotten to the point where you're patching that kext, there's not much else that can be done to stop you, which is why they gave the kext its name and included the following plain-text string in the binary:

Your karma check for today:
There once was was a user that whined
his existing OS was so blind,
he'd do better to pirate
an OS that ran great
but found his hardware declined.
Please don't steal Mac OS!
Really, that's way uncool.
(C) Apple Computer, Inc.

Is [some part of Mac OS X] actually encrypted? I'm not seeing any hits on Google about that.

Try "Don't Steal Mac OS X" as your keyword to get an article about AES encryption of the Finder and Dock binaries.

Yea but the kernel is based on Mach, not BSD. It just uses all of the BSD goodness to make the kernel useful for something.
http://osxbook.com/book/bonus/ancient/whatismacosx/arch_xnu.html

Saying the OS is BSD is incorrect. _Most_ of of the OS is BSD, but the kernel is Mach ;)

Perhaps a history lesson is in order.

"The core of Apple's Mac OS X (and its predecessor NextStep) is Darwin, which contains a lot of BSD code, especially FreeBSD 5 code."

"XNU's BSD component uses FreeBSD as the primary reference codebase (although some code might be traced to other BSDs). Darwin 7.x (Mac OS X 10.3.x) uses FreeBSD 5.x. As mentioned before, BSD runs not as an external (or user-level) server, but is part of the kernel itself."

"Darwin integrates a number of technologies, most importantly Mach 3.0, operating-system services based on 4.4BSD (Berkeley Software Distribution), high-performance networking facilities, and support for multiple integrated file systems."

Lather, rinse, & repeat....

Or Apple could take advantage of the TPM chip that's been present in Macs since almost immediately after they moved to the x86 platform.

As I understand it they stopped including a TPM chip after a short time citing cost and lack of interest from developers. A quick Google search finds this: Tom's Hardware Article provide a source for such a claim (end of the first paragraph). Another response to your post claims Apple uses TPM to lock down OS X, but I've never heard any knowledgeable source make such a claim. Here's a detailed article explaining about Apple's use of TPM as a tool for cryptography and how it has never been used as DRM on OS X.

Lies. They've never used the TPM chip. They've always relied on modern computers having EFI disabled. (Most computers ship with the Framework, which is EFI based, but EFI support is complete disabled and only the BIOS compatibility mode is used. Source: http://osxbook.com/book/bonus/chapter10/tpm/

But the misconception that free/open source operating systems are "Hacker Operating Systems" seems to be a common misconception among collegiate IT departments. Woodbury University's IT department would absolutely NOT let me bring my Linux ThinkPad to campus and connect to the WiFi, even though I was more than happy to give them the MAC address of my Orinoco card. "Come back with Windows and we'll talk" was their attitude. Luckily my aunt had an original clamshell iBook that was just sitting on a shelf, so I brought that there. Macs were also acceptable to WU IT so that solved my problem. Eventually I wound up with a Core 2 Duo (Merom) MacBook. Of course, I have the evil, daemonic TERMINAL WINDOW available to me on Mac OS X too...bwahahahahahaha! And my MacBook is Daemon Possessed! Ahahahahahahahah!!!!

OK, let's go do some crimes. Like, go get sushi and not pay...^_^

Only the very earliest Macs had TPM chips, and they were never used.

The binary protection in Mac OS X comes from the SCM hardware, not TPM.

http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/

And Macs already use encrypted binaries against TPM but the key for that is known so that's why regular PCs can install a decrypted version.

You are officially not informed and possibly stupid. Apple does not use TPM in their intel systems. It's done through dsmos.
Read up before making claims.

As for removing the check from the code, that won't help much when it comes to updates and changes. This is why it's taken care of via a kernel extension. The same thing with cpuids when it comes to software and AMD systems. Currently it is manually checked and modified, but there is a new kernel extension almost ready to release that will alter installed files so that the cpuids in its opcodes will work for amd. There's also a kernel extension that makes sure that certain kernel extensions that are installed by default in updates (for intel macs) are immediately removed (since after rebooting it will make the OS unbootable).

There's a lot more going on than most people think. The amount of people working on running OS X on the PC has shot up since 2005/2006.

Why would it need a TPM chip? Apple doesn't use the TPM and modern Macintoshes don't have them.

http://www.osxbook.com/book/bonus/chapter10/tpm/

Apple creates a good products -- some time. None the less most of their products are expensive -- way more expensive then they should be.

I paid for my Mini-Mac over $1000 Canadian dollar, that just is not right. Why? Because values of Canadian dollar is higher therefore Mac - Mini should've cost me no more then $400. This has been pointed out many times by many people in media -- even by mac-heads freaks.

No one can deny that OS-X is a wonderful operating system -- compare to Vista. And it's Unix core gives it a very strong security. Non-the-less we are paying very too much for the hardware. And TPM chip software consumes way too much resource. TPM is design to prevent OSX running on a typical x86 hardware. Their behavior is not only illegal but unethical.

Those of you who are not aware of TPM. Think of TPM like old South African government -- White didn't want non-white to have same right or live in a same community. The same way Mac doesn't want non-mac x86 to have OSX. So they created a software which will make sure osx only runs of x86 with TPM chip. TPM is an Apple version of apartheid.

Apple is an evil twin of Microsoft.

Sorry to interject some reality into a perfectly good rant, but your bit about TPM is rather off base. But I can't say it any better than this guy:
http://www.osxbook.com/book/bonus/chapter7/tpmdrmmyth/

Macs don't use TPM. They don't even ship with a TPM chip these days. Yes, the early Intel ones did. No, it was not used.

because it exposes the fact that today's Mac desktops are just commodity hardware with an extra $1,000 charge for an OS X dongle (TPM).

No, you're quite wrong about TPM. You may want to read up on it:
http://www.osxbook.com/book/bonus/chapter10/tpm/

The executive summary (which I hope it's okay to quote here, but as a sample it indicates that the longer text is worth reading) notes:

• Regardless of what the media has been harping on for a long time, and regardless of what system attackers have been saying about the "evil TPM protection" Apple uses, Apple is doing no TPM-related evil thing. In fact, Apple is doing no TPM-related cryptographic thing at all in Mac OS X. Yes, I know, there has been much talk of "TPM keys" and such, but there are no TPM keys that Apple is hiding somewhere.
• More specifically, Apple simply does not use the TPM hardware. In Apple computer models that do contain a TPM, the hardware is available for use by the machine's owner. Of course, to use it you need a device driver, which Apple indeed doesn't provide.
• I am releasing an open source TPM driver for Mac OS X, along with Mac OS X versions of popular open source trusted computing software from the Linux world. No reverse engineering was required to write this driver.
• The driver and the software stack together make (a form of) trusted computing possible on Mac OS X, assuming you have a machine with a TPM. This page shows you how to "take ownership" of the TPM and begin using it.
• For crying out loud, Intel's Trusted Execution Technology (a.k.a. LaGrande) does not mean you start putting TPMs "inside the CPU". Apple isn't shipping CPUs with "built-in TPMs."

I hope that helps kill some incorrect information out there in the wild. My understanding is that it's been a few years since we saw a TPM in any Mac, but I may be wrong about that.

because it exposes the fact that today's Mac desktops are just commodity hardware with an extra $1,000 charge for an OS X dongle (TPM).

Are you sure about that?

You have a link on that? Amit Singh's has dtraced all of Apple's system software and says this is wrong, and the latest Mac Pro's don't even have a TPM.
Typed on a TPM-free Mac Pro, confirmed in ioreg(8).

The real copy protection, such as it is, is EFI and some obfuscation.

http://osxbook.com/book/bonus/chapter7/tpmdrmmyth/

Certain key OS X application binaries are encrypted using AES. Among these applications are the SystemUIServer, the loginwindow, the Finder, the Dock, and translated (Rosetta). If you can't decrypt these applications, you can't run OS X. OS X has a kernel extension, which is amusingly named "Don't Steal Mac OS X.kext", that determines if OS X is running on Apple hardware and, if it is, allows the system to decrypt the binaries. (source: http://www.osxbook.com/book/bonus/chapter7/binaryprotection/)

The key here is that "Don't Steal Mac OS X.kext" is not using the TPM chip to determine if it's running on Apple hardware. At least, that's not the only thing it checks. It can't be because not all Intel Macs have the TPM chip:

At the time of this writing (October 2006), the newest Apple computer models, such as the MacPro and possibly the revised MacBook Pro and the revised iMac, do not contain an onboard Infineon TPM. Apple could bring the TPM back, perhaps, if there were enough interest (after all, it is increasingly common to find TPMs in current notebook computers), but that's another story.

None of this means that I disagree with the rest of your post. I hate that Apple promotes DRM from one side of its mouth while condemning it with the other. Would Apple be dominating the MP3 player and online music markets without DRM? It's possible, but the locked-in ecosystem they've created clearly benefits from the presence of DRM (and, incidentally, is the reason I'm an eMusic subscriber).

Certain key OS X application binaries are encrypted using AES. Among these applications are the SystemUIServer, the loginwindow, the Finder, the Dock, and translated (Rosetta). If you can't decrypt these applications, you can't run OS X. OS X has a kernel extension, which is amusingly named "Don't Steal Mac OS X.kext", that determines if OS X is running on Apple hardware and, if it is, allows the system to decrypt the binaries. (source: http://www.osxbook.com/book/bonus/chapter7/binaryprotection/)

The key here is that "Don't Steal Mac OS X.kext" is not using the TPM chip to determine if it's running on Apple hardware. At least, that's not the only thing it checks. It can't be because not all Intel Macs have the TPM chip:

At the time of this writing (October 2006), the newest Apple computer models, such as the MacPro and possibly the revised MacBook Pro and the revised iMac, do not contain an onboard Infineon TPM. Apple could bring the TPM back, perhaps, if there were enough interest (after all, it is increasingly common to find TPMs in current notebook computers), but that's another story.

None of this means that I disagree with the rest of your post. I hate that Apple promotes DRM from one side of its mouth while condemning it with the other. Would Apple be dominating the MP3 player and online music markets without DRM? It's possible, but the locked-in ecosystem they've created clearly benefits from the presence of DRM (and, incidentally, is the reason I'm an eMusic subscriber).

• Regardless of what the media has been harping on for a long time, and regardless of what system attackers have been saying about the "evil TPM protection" Apple uses, Apple is doing no TPM-related evil thing. In fact, Apple is doing no TPM-related cryptographic thing at all in Mac OS X. Yes, I know, there has been much talk of "TPM keys" and such, but there are no TPM keys that Apple is hiding somewhere.
• More specifically, Apple simply does not use the TPM hardware. In Apple computer models that do contain a TPM, the hardware is available for use by the machine's owner. Of course, to use it you need a device driver, which Apple indeed doesn't provide.
• I am releasing an open source TPM driver for Mac OS X, along with Mac OS X versions of popular open source trusted computing software from the Linux world. No reverse engineering was required to write this driver.
• The driver and the software stack together make (a form of) trusted computing possible on Mac OS X, assuming you have a machine with a TPM. This page shows you how to "take ownership" of the TPM and begin using it.
• For crying out loud, Intel's Trusted Execution Technology (a.k.a. LaGrande) does not mean you start putting TPMs "inside the CPU". Apple isn't shipping CPUs with "built-in TPMs."

"The "Trusted Platform Module," or TPM, is a computer chip embedded inside Intel-based Macs to prevent the Intel-based version of Mac OS X from running on non-Apple hardware. (during installation of Mac OS X, Mac OS X interfaces with the TPM. If Mac OS X finds that the TPM doesn't exist, Mac OS X refuses to install or run.)"

That is what their site says, but I'm able to install Tiger with store box DVDs onto computers that don't have a TPM. I'd love to see the backtrace that they used to deduce the installer was checking for the TPM, considering you have to install your own TPM driver in order to even make use of an installed one.

Sure. What are the stakes?

From Singh:

More specifically, Apple simply does not use the TPM hardware. In Apple computer models that do contain a TPM, the hardware is available for use by the machine's owner. Of course, to use it you need a device driver, which Apple indeed doesn't provide.

Apple does not use TPM in any way on Mac OS X (either at present, or at any time in the past):

http://osxbook.com/book/bonus/chapter10/tpm/#EXECU TIVE_SUMMARY

That was based on the developer hardware that Apple shipped prior to the Intel transition (look at the date of the DF article - the first Intel Mac shipped on Jan 2006). Production MacIntels never shipped with TPM support. Apple uses encrypted binaries to prevent Mac OS X from running on non-Apple Intel hardware.

I know it doesn't matter in the context of the iPhone, but I'm just trying to correct the misperception that Apple uses/used TPM on their shipping Macs - they don't

From the Singh linked in the Boing Boing segment:

The media has been discussing "Apple's use of TPM" for a long time now. There have been numerous reports of system attackers bypassing "Apple's TPM protection" and finding "Apple's TPM keys." Nevertheless, it is important to note that Apple does not use the TPM. If you have a TPM-equipped Macintosh computer, you can use the TPM for its intended purpose, with no side effect on the normal working of Mac OS X.