Slashdot Mirror
Apple Crippled Its DTrace Port
Linnen writes in to note that one of developers of Sun's open source system tracing tool, DTrace, has discovered that Apple crippled its port of the tool so that software like iTunes could not be traced. From Adam Leventhal's blog: "I let it run for a while, made iTunes do some work, and the result when I stopped the script? Nothing. The expensive DTrace invocation clearly caused iTunes to do a lot more work, but DTrace was giving me no output. Which started me thinking... did they? Surely not. They wouldn't disable DTrace for certain applications. But that's exactly what Apple's done with their DTrace implementation. The notion of true systemic tracing was a bit too egalitarian for their classist sensibilities..."
As quickly as the issue is reported, a hack comes out to resolve it. Gotta love how quickly the community can respond to these things.
This will be a big help for me in my quest for a legion of Mac zombies
I don't care if it's 90,000 hectares. That lake was not my doing.
From the DTrace source (in an #IFDEF APPLE):
/*
* If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
* then this enabling is not permitted to observe it. Move along, nothing to see here.
*/
Luckily no malicious programmer will mark their malware's process with this flag!
You of all people should know that you give up your freedom to use your software and hardware as you wish when you use proprietary software. Apple's continuous attempt to stop people from changing software on their home computers is a good example of how they feel about freedom. They only side with freedom when it is immediately beneficial.
Fuck me, it's like a Student Union bar in here. What next, comrades, do we storm the Winter Palace or just go and sell some copies of Socialist Worker?
If you haven't made a developer cry, you've wasted a day.
Are you kidding?
This is Slashdot where "paper or plastic" is an epic struggle directly and immediately affecting the fates of billions!
BILLIONS, I tell you! BILLIONS!
The article says, "To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist..." So what is the Slashdot headline? "Apple Crippled Its DTrace Port"
Nice...
Basically profile and tick are useless since they will not fire if a thread with PT_DENY_ATTACH is on proc. Perfectly good DTrace scripts simply will not work correctly on OS X.
(Note: IANA DTrace user or developer.)
The real effects seem to be that while a process which sets this flag has control of the system, any DTrace events that fire off during this time will not be detected, as if they never occurred, regardless of whether what is being traced has anything to do with that process. It seems to break a few important(?) idioms used by DTrace users, so that the results returned are not what they should be.
The furor seems to be that this subtle breakage has gone undocumented; and although only iTunes currently uses it, that does not stop other software (including software that should not be there) from using it. That a DTrace developer discovered this, combined with that this is in all likelihood being done for no reason other than that of DRM, is what makes this notable. If I were working on DTrace, I'd probably be pissed too.
It's nice that Dtrace works again. But I'm betting a lot more people use After Effects or Premiere. The QT 7.4 update which enables movie rentals from iTunes breaks any render that takes longer than 10 minutes. Thank god DRM is here to protect me from the work I need to do. Wasn't apple supposed to me the machine for media professionals?
http://blogs.adobe.com/keyframes/2008/01/dont_update_to_quicktime_74.html
Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3 ;-). But this issue is about more than just that.
I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.
This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.
Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.
Most likely, Apple's intent is to deliver a 'credible effort' to prevent circumvention and/or reverse engineering.
Even though the labels have largely dropped DRM, they still don't like the idea of users having control over digital music. It's part of their DNA. Their whole business revolved around having control over the production and distribution systems, and they just can't contemplate existence without having control over something. The contracts between Apple and the labels reflect that fear, with Apple having the job of making it look like the horses are still in the barn even though the door is open.
Now technically, that's impossible. But my experience with corporate software development has shown me that you can balance 'customers who don't want to know what's impossible' with judicious use of handwavium. You don't have to build a solution that's bulletproof, you just need something that works most of the time. It doesn't matter if there are workarounds, or even if those workarounds are practically trivial for anyone with a technical background, as long as you can't discuss the workaround without using technical terms.
It's sort of an extension of the Sapir-Whorf hypothesis. It's not that your customers can't think about the problem if you lack the vocabulary, it's more that they won't want to think about the problem if they have to spend effort learning how to discuss it intelligently.
So from a contractual standpoint, providing a 'credible effort' is more about obfuscation than actually trying to do the impossible. Apple probably doesn't care if people can work around this issue, as long as the explanation boils down to 'blah blah blah' to aggressively uninformed label executives.
Friend, a corporation is a miniature society. It's an organization of people that divides labor for the purpose of maximizing the welfare of all, subject to an agreed-upon heirarchical distribution scheme. (That is, the wealth it creates is not usually distributed equally.) Society is merely the largest possible corporation, in which we are all, whether we like it nor not, employed.
What you are saying is that the smaller organization we may voluntarily join (e.g. the corporations that employ us) should be policed by and subject to the larger organizations that we are a member of whether we like it or not (e.g. the country in which we are born).
Yeah, well, not by me. I prefer to choose with whom I associate, and to whom I listen. I most definitely do not like the idea of the largest possible organization of which I'm a member, like it or not, enforcing the ultimate rules of my life. I'm much happier if the rules are defined by a smaller organization that I voluntarily join, and which I can voluntarily leave if I don't like the rules.
In a free society, where the largest powerful organizations are much smaller than the entire country, I can find the corner of it that plays by the rules I like. I have choices. I can be mostly who I want to be. In your "social" society, I have no more choices. I have to be what the majority thinks I should be, act accordingly to their morality and expectations.
No thanks! I know my average fellow man too well to think it would be fun to allow him to dictate the terms of my life.
Then, they came for gettytab, but I did not speak out, because I was happy with Apple's default terminal configuration.
Then, they came for snort, but I was not worried about intrusion detection so I did not speak up.
Next, they came for mkdep, but I did not speak out, because the maid does all my compiling.
Sadly, when it came time for them to use killall, there was nobody left to speak up for me!
We never ever criticize our heroes ever.
The difference you seem to be missing here is that Steve Jobs only occasionally does a boneheaded thing like this against his fan base. Bill Gates only occasionally doesn't.
Weaselmancer
rediculous.
I call BULLSHIT.
If they're selectively telling this app NOT to log "certain types of traffic", and give no notification of such, or allow the functionality to be restored, then it's CRIPPLED.
I'm so sick of apologists telling me that stuff that's broken is broken for a good reason and that I should be glad someone deigned to allow me to hack it back to some semblance of functionality without getting sued into oblivion!
Chas - The one, the only.
THANK GOD!!!
Actually, Leopard's DTrace is broken, and that was the point of the blog post. Here's the issue: DTrace programs that would normally work and collect valid data will fail if a process is running with Apple's trace-me-not bit set. Forget tracing iTunes or other applications that don't want to be traced. It's that probes that should fire don't as an unintended side-effect of Apple's hack to obscure certain applications.
A much smarter approach would have been for Apple to deny visibility into such a process, but still allow a user to monitor system-level events (e.g. timers and system calls). This would have allowed for the (questionably motivated, and highly circumventable) protection while not damaging DTrace and correctly phrased queries.
Maybe everyone knows what dtrace is. I didn't. Then I watched this: link and now I do.
http://ed.markovich.googlepages.com
"As I understand it, a DTrace user has experimented with the program, determined it to be specifically crippled, and given an educated guess about why it is crippled in that way"
No, the frickin' **author** of DTrace has found the specific code used by Apple to cripple it.
Back in 2000, if you installed MacsBug on a Mac you couldn't play DVDs. When you opened the DVD Player you got an error message telling you a debugger was installed. In these pre-memory protection days, MacsBug was the only debugger low-level enough to catch a whole mess of problems. Unfortunately, MacsBug was loaded when the system booted, so the only way to play a DVD was to remove MacsBug and restart your machine.
Long time Mac developer ally Bare Bones Software (they have a great text editor) created a patch that "fixed" this limitation. AFAIK, Apple never said anything about their patch and just quietly let it exist. http://www.macobserver.com/news/00/april/000418/dvdplayerhelper.shtml
This whole message mess came about because Macrovision didn't want people disabling their protection on video-output (there were Macs you could literally plug into VCRs then), and I suspect it was also to guard the CSS "encryption."
When Blu-ray movies finally show up in Macs, this kind of thing is probably going to get a lot worse than patches to D-Trace.