Discussion Over Apple's Modification Of Sun's DTrace

[MacRumors]

One of the most anticipated features of Mac OS X Leopard amongst the technical community was the port of Sun's DTrace utility for application and system profiling. DTrace is a powerful, low-level dynamic tracing framework that allows system administrators and developers to trace applications for tuning or troubleshooting purposes.

Recently, Adam Leventhal, one of DTrace's initial developers, discovered that Apple's implementation creates a way for a program to exclude itself from being traced. Namely, he was unsuccessful at tracing iTunes, and found that Apple had added a method of disabling probing on certain applications defined with the directive P_LNOATTACH.

Wow. So Apple is explicitly preventing DTrace from examining or recording data for processes which don't permit tracing. This is antithetical to the notion of systemic tracing, antithetical to the goals of DTrace, and antithetical to the spirit of open source. I'm sure this was inserted under pressure from ISVs, but that makes the pill no easier to swallow.

Since the initial publication of the blog entry last week, the story has begun to pop up around the mac web.

The practice is not entirely new to Apple. A commenter on Adam Leventhal's blog noted that Apple used the same directive to prevent GDB tracing on iTunes. Additionally, the implementation of this directive appears to be limited to iTunes (for the moment?), so many are speculating that the move is to protect Apple's FairPlay DRM.

To present an alternate view, Apple has extended Java, Ruby, Python, and Perl to include DTrace support, and Apple has built a GUI front-end called Instruments. Also the issue may eventually become moot with Apple's stated desire to move towards DRM-free music.

Article Link

 

[longofest]

For those interested, from Adam's blog... the code that was added.

#if defined(__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.
         */
        if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
            continue;
        }
#endif /* __APPLE__ */

 

[parapup]

I don't understand...

...the point Apple was trying to make here. Preventing iTunes from being traced when there exist things like QTFairUse which rid the DRM in Apple sold music and continue to support latest iTunes versions.

On top of that, noted developer Landon Fuller posted a fairly quick and tiny Kext with source that will disallow applications from doing the NOATTACH trick so iTunes can be traced anyways.

 

[daveschroeder]

And the reason it's so easy to see what's going on?

Because the source code for things like dtrace is readily available on Apple's site.

And since the source is available, it's easy to fix for things like gdb and dtrace.

Making good-faith attempts to protect things like iTunes is a necessary evil for Apple to play in things like the video rental realm. Some people might not like it, but for the current iTunes ecosystem to exist, it's simply necessary to take steps to make the DRM environment more difficult to defeat.

But since Jobs himself has stated in no uncertain terms that DRM will always be broken - both literally and figuratively - this simply represents a necessary intermediate step to a world where digital content isn't encumbered with DRM. And it's only Apple who is going to be able to move the industry in that direction the fastest, because they have the most influence. In the meantime, Apple needs to do what needs to be done.

If FairPlay was trivial (anymore trivial than it already has been, anyway) to break, do you think Apple would have been able to get ALL the studios on board for movie rentals?

That means Apple takes actions which can be construed to ISVs as good-faith attempts to protect FairPlay.

 

[messedkid]

As a mac user for the past year and a half, all I have to say is...


....Wha?

 

[em500]

Also the issue may eventually become moot with Apple's stated desire to move towards DRM-free music.

They may be moving towards DRM-free music, but DRM-free movies are nowhere near the horizons yet.

 

[irmongoose]

Music might be on its way to no-DRM, but FairPlay is also used for movies, so I don't see how the issue will be obviated - especially with the new movie rentals which need DRM by nature.


irmongoose

 

[madrag]

that's why I don't use iTunes.
Sad.

 

[JoeG4]

Apple only brought out their desire to sell DRM-free music after the music studios decided that was the way to go.

Steve Jobs happily changes his mind however it benefits him.

 

[tk421]

Why should an average user even care about this?

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

 

[daveschroeder]

Apple only brought out their desire to sell DRM-free music after the music studios decided that was the way to go.

Steve Jobs happily changes his mind however it benefits him.

You are completely wrong, and that is revisionist history.

No one is staying Steve Jobs is God, but the DRM statement was the single biggest shot across the bow with respect to DRM that the music industry has EVER had from anyone close to that stature, and it was only AFTER that statement that the vast, vast, overwhelming majority of no-DRM music sales activity has gone on.

Was it due exclusively and only to Jobs? No.

Did it have a lot to do with that? Absolutely. Both from the standpoint of the statement, and from the standpoint of content owners trying to figure out how to still make content available to the widest range of customers without being beholden to iTunes.

 

[parapup]

But since Jobs himself has stated in no uncertain terms that DRM will always be broken - both literally and figuratively

Properly implemented DRM, like Encryption, cannot be broken. But I agree with your point that they have to take some steps to convince the music and video companies and this poorly implemented DRM is a good faith attempt. The "poorly implemented" part may have its roots in practical limitations - they don't have the Vista style hardware and OS assisted DRM yet in OSX to be able to thwart breaking attempts.

 

[Iroganai]

that's why I don't use iTunes.
Sad.

No, it's not just the fault of iTunes, it's the combination of iTunes and the
OS X kernel. So, if this is why you don't use iTunes, you shouldn't use OS X itself

Anyways, it shows the good thing about the open-sourced Darwin project,
in that people can easily find what's `crippled' in the DTrace implementation on Leopard by looking at the code. You can't do that for a truly closed-source kernel. You can also re-compile the kernel with the offending code removed if you'd like, although it's not particularly easy.

 

[notjustjay]

Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

I agree with this statement.

 

[QuarterSwede]

Properly implemented DRM, like Encryption, cannot be broken.

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

 

[madmax_2069]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

well can 3rd party's use it to point out a bug that Apple didn't see

 

[diamond.g]

That's not true either. Any encryption can be broken. It's just that hardware assisted encryption, be it an RSA key or other schema, just takes a really long time to break. Long enough to make it almost impossible.

Personally I agree with daveschroeder. I believe he's right in saying that they're doing it to protect their current interests. What do developers care about it anyway? I don't see how this really affects 3rd parties.

The problem, reading slashdots comments on the issue, is that if iTunes is open it screws up the trace log. So you could have iTunes (or any program that uses the flag) open and your trace log would basically be empty or corrupted. I am guessing that Apple didn't tell anyone that they were doing that, it took someone doing some snooping to figure out what was going on. It isn't that big of a deal as you can just compile that flag right out of the program, but it is annoying if one doesn't realize that is happening.

 

[kainjow]

As a mac user for the past year and a half, all I have to say is...


....Wha?

Basically, Apple is preventing open-sourced debugging tools (software that helps a developer troubleshoot their programs) from working on iTunes

 

[milo]

that's why I don't use iTunes.
Sad.

What's why? Because you can't run dtrace on it? Um...what?

 

[QuarterSwede]

The problem, reading slashdots comments on the issue, is that if iTunes is open it screws up the trace log. So you could have iTunes (or any program that uses the flag) open and your trace log would basically be empty or corrupted. I am guessing that Apple didn't tell anyone that they were doing that, it took someone doing some snooping to figure out what was going on. It isn't that big of a deal as you can just compile that flag right out of the program, but it is annoying if one doesn't realize that is happening.

Ahhh I see. Thanks for clarifying. Yeah, that would've pissed me off too.

 

[milo]

Basically, Apple is preventing open-sourced debugging tools (software that helps a developer troubleshoot their programs) from working on iTunes

And why does a developer really need to use the debugging tool on itunes? Or while iTunes is running?

Quit iTunes. Debug your program.

 

[iSee]

Why should an average user even care about this?

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

You're not a jerk: this doesn't really even affect software developers.

Well, actually it is a positive thing for software developers because we can use the same mechanism to make our apps opaque to DTrace, too, if we choose to.

It's kind of a negative for hackers (who else wants to debug someone else's apps?). But not really, because they can work around it. Actually, hackers enjoy working around things like this, so it's actually a positive for them, too.

In practical terms, this doesn't really mean anything to anyone. If you are the type of person who wants everything to be "open," the idea of this will annoy you. I assume that's why such an esoteric thing is posted on as a main story.

 

[kainjow]

And why does a developer really need to use the debugging tool on itunes? Or while iTunes is running?

Quit iTunes. Debug your program.

What if your program is in iTunes? Visualizers?

 

[gnasher729]

I'm not trying to be a jerk, I'm seriously wondering. If you're not a software developer, does this affect you? Why shouldn't Apple be able to protect a designated part of their code? They don't seem to have a problem opening up things besides iTunes.

If you are not a software developer, it doesn't affect you at all.

There are two things worth discussing here: The first thing is that Apple tries (moderately successful) to keep people from looking at what iTunes is doing, which I think is their right to do. It's trivial (well, for a developer with a bit of hacker blood in him) to get around this. It is actually trivial to change DTrace so that it will _only_ work with applications that don't want it to look.

The second thing, which is not nice, is that DTrace doesn't work properly when iTunes is running. The problem isn't that DTrace cannot look what iTunes does, the problem is that DTrace cannot look what _my own code_ does while iTunes is running. That is a problem. The whole purpose why DTrace is there (and it has been proudly announced by Apple, is a major feature of Leopard as far as developers are concerned, and was reportedly very valuable for developers working at Apple) is to look at _my_ code, and it doesn't work properly. So whoever added those few lines of code should have done a better job and changed DTrace so that it doesn't look at iTunes, but continues working when iTunes is running.

The real problem is that DTrace can give completely wrong results without any warning. So a developer who listens to iTunes while he works might spend hours and hours looking for problems that don't exist - because DTrace gives the wrong results. Or he might not be able to find the cause of a real problem because DTrace gives the wrong results.

 

[diamond.g]

And why does a developer really need to use the debugging tool on itunes? Or while iTunes is running?

Quit iTunes. Debug your program.

It may not be only iTunes using that flag. It could be any program. Apple not telling anyone was the issue.