As has been thoroughly recorded, Apple has included DTrace in Mac OS X. I’ve been using it as often as I have the opportunity, and it’s a joy to be able to use the fruits of our labor on another operating system. But I hit a rather surprising case recently which led me to discover a serious problem with Apple’s implementation.
A common trick with DTrace is to use a tick probe to report data periodically. For example, the following script reports the ten most frequently accessed files every 10 seconds:
io:::start
{
@[args[2]->fi_pathname] = count();
}
tick-10s
{
trunc(@, 10);
printa(@);
trunc(@, 0);
}
This was running fine, but it seemed as though sometimes (particularly with certain apps in the background) it would occasionally skip one of the ten second iterations. Odd. So I wrote the following script to see what was going on:
profile-1000
{
@ = count();
}
tick-1s
{
printa(@);
clear(@);
}
What this will do is fire a probe at 1000hz on all (logical) CPUs. Running this on a dual-core machine we’d expect to see it print out 2000 each time. Instead I saw this:
0 22369 :tick-1s 1803 0 22369 :tick-1s 1736 0 22369 :tick-1s 1641 0 22369 :tick-1s 3323 0 22369 :tick-1s 1704 0 22369 :tick-1s 1732 0 22369 :tick-1s 1697 0 22369 :tick-1s 5154
Kind of bizarre. The missing tick-1s probes explain the values over 2000, but weirder were the values so far under 2000. To explore a bit more I performed another DTrace experiment to see what applications were running when the profile probe fired:
# dtrace -n profile-997'{ @[execname] = count(); }'
dtrace: description 'profile-997' matched 1 probe
^C
Finder 1
configd 1
DirectoryServic 2
GrowlHelperApp 2
llipd 2
launchd 3
mDNSResponder 3
fseventsd 4
mds 4
lsd 5
ntpd 6
kdcmond 7
SystemUIServer 8
dtrace 8
loginwindow 9
pvsnatd 21
Dock 41
Activity Monito 45
pmTool 52
Google Notifier 60
Terminal 153
WindowServer 238
Safari 1361
kernel_task 4247
While there’s nothing suspicious about the output in itself, it was strange because I was listening to music at the time. With iTunes. Where was iTunes?
I ran the first experiment again and caused iTunes to do more work which yielded these results:
0 22369 :tick-1s 3856 0 22369 :tick-1s 1281 0 22369 :tick-1s 4770 0 22369 :tick-1s 2271
So what was iTunes doing? To answer that I again turned to DTrace and used the following enabling to see what functions were being called most frequently by iTunes (whose process ID was 332):
# dtrace -n 'pid332:::entry{ @[probefunc] = count(); }'
dtrace: description 'pid332:::entry' matched 264630 probes
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 so they added this glob of lard into dtrace_probe() — the heart of DTrace:
#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__ */
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. To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist, but they’ve certainly undermined its efficacy and, in doing do, unintentionally damaged some of its most basic functionality. To users of Mac OS X and of DTrace: Apple has done a service by porting DTrace, but let’s convince them to go one step further and port it properly.
77 Responses
I think you’ll find you can yell and scream at apple all you please, they’re not a company that listens to the demands of their users, particularly those in a minority.
Now we just need a port of mdb so that the proc flags can be changed :-).
Wtf?! Can Apple do ANYTHING without being evil? They are like the anti-Google. At least Microsoft doesn’t pretend to like it’s customers. And I’ve been so happy about using dtrace on my Macbook Pro. A sad day.
I can understand them not wanting people probing too deeply into iTunes’ guts. The record companies are on their case already.
@Erik : ‘evil’? Take my advice mate and go for a walk outside.
@Dick: Yeah, sure. Maybe you’re right and I’m overreacting a bit, but I’m just so tired of copyright politics (which I suspect this is all about…) making our tech lives miserable.
Is this so bad? While this makes system wide tracing unreliable using dtrace on your own programs sounds like it is at the heart of dtrace right? Plus, something is better than nothing…
Any chance you can post a quick comment giving examples of useful program level things this will break?
PL_NOATTACH’s main purpose is to prevent gdb from attaching to certain processes, which I think is done to hinder a few attack vectors trying to obtain an unencrypted version of DRM’d media by attaching to the iTunes process.
No other Apple-shipped application seems to make use of this flag.
@Erik: you aren’t overreacting. I’ve worked with apple as a partner in the past, and quite literally gotten a call from one of their execs for telling a customer that their issue was a result of a bug in OSX. "WE DO NOT HAVE BUGS, DON’T YOU EVER TELL A CUSTOMER THAT AGAIN!!!".
They’re more concerned with their image than doing the right thing. That is the essence of evil.
They also blocked gdb on itunes : http://steike.com/code/debugging-itunes-with-gdb/.
Of course, that’s not very effective to do it when you can recompile the source code 🙂
Surely this code is trivial to circumvent, either through a destructive DTrace script (akin to the hostid "daemon") or even an old fashoned shim library to prevent P_LNOATTACH from ever being set.
If this is the case, the argument to Apple becomes much simpler: "You are crippling DTrace for absolutely zero benefit, real or imagined."
Hmm, did you realise that maybe this is due to the fact that they will be supporting BluRay soon, and allowing Dtrace to probe might allow someone to hack easier at the video? Until Sun has the same level of penetration on the consumer desktop, quite frankly Sun has no place giving lectures on the virtues of how someone implements Dtrace.
I still wonder why tick-X didn’t work properly…
Robert,
My semi informed guess is that iTunes was on the CPU when the tick (or profile) probes would have wished to fire, and were prevented from doing same by the above.
(ie, that their "Don’t trace itunes" logic actually means "don’t trace anything when itunes is on this cpu", which would include unrelated probes in unrelated places)
I’m sure Adam will correct me if (or more likely when) he notices I’m entirely wrong.
The DTrace limit on iTunes is probably to protect DRMed music data from being grabbed in an unencrypted state from memory. There is an existing Fairplay crack that plays exactly this trick on iTunes for Windows, where the memory is not protected from user inspection.
In Tiger, I discovered that you cannot attach a debugger to the DVD Player process, also presumably to prevent me from intercepting the raw, unencrypted DVD data. I assume the Leopard version has the same restriction.
Thanks for all the comments and interest folks — sorry I’ve fallen a bit behind. Here are some replies:
@JohnS: I completely agree. On issues like this, Apple certainly will listen more to their ISVs than to their customers. But developers probably have more sway than you might imagine.
@Darren: I’m sure Apple would have yet another mechanism to protect access with mdb. But you’re right that they do need it…
@81.96.206.228: This _is_ so bad, and I don’t think I put a fine enough point on it. What this means is that D programs that use the tick provider to emit output are flat broken on Mac OS X. This was an unintended result of how they decided to restrict visibility for certain applications.
@millenomi: Yes, and PL_NOATTACH is set via a call to ptrace(2) with the PT_DENY_ATTACH flag. I understand that this is to protect what litigious
parties deem to be private code paths, but it’s kind of a nonsense argument since we do, afterall, have the bits. Fortunately it’s easy to circumvent; more on that later.
@Tom Shaw: Agreed. And they’re not just crippling DTrace in the way they intended, but also in ways that are, in some ways, more pervasive.
@Robert: I should have explained in more detail why the tick-1s probe didn’t work: if we get unlucky and the timer expires while iTunes or some other sneaky app is running the probe simply won’t fire as the thread that gets interrupted belongs, in essence, to that process. (And @richlowe, you’re absolutely right).
Much like our invention of the worlds first portable cellular phone, our invention of the GUI, our class leading RAM pricing, and our 100% hardware reliability DTrace shows exactly what Apple is capable of!
I am saddened that Sun would try to imply that they had anything to do with the invention of DTrace! Such thinking goes against the FACT that apple is the inventor of EVERY technological innovation in the past 80 years!
P
[Trackback] Apple, al parecer por presiones de los ISV (desarrolladores de software independientes), ha limitado su implementación de DTrace en Mac OS X, de forma que los programas pueden hacerse invisibles para DTrace.
You want freedom, don’t buy a Mac or a WinTel machine! Run Linux, develop for Linux, advocate Linux, and all your freedom will be returned to you. If Sun decides to fully Open Source and provide an ISO for the community, then by all means run Solaris. Otherwise, these corporations will make you their bitch. Apple, just like M$, is just another greedy company with its own objectives that do not coincide with the objectives of the people… The word user is appropriate because what they produce is crack.
@Flame Bait: Sure, run Linux _or_ you could run an open source operating system that actually has the technology under discussion.
@Adam@Flame Bait: Have you heard of System Tap? Or you want to conveniently ignore the fact?
@Alok when it comes to systemtap nothing is convenient
Did you consider that maybe Apple has a legal obligation to not allow debugging tools to attach to apps like iTunes or DVD Player?
Or, even if not a formal legal obligation, then an implied legal obligation?
By putting in such blocks, one must do an act of circumvention to screw with the process in question. DMCA anyone?
Apple seems to have a history of being the only company that has gotten anything resembling reasonable terms out of the MPAA and RIAA. That has to have a cost.
@foo bar
If that’s the case, they should say "sorry, we can’t port dtrace because of legal obligations with third-party providers" rather than providing a crippled version and claiming that dtrace has been ported in its entirety. At the very least, the fact that it is crippled should be mentioned, rather than hidden.
I’m not in he least bit surprised about Apple’s behavior. They’re the ‘most’ propreitary company on the planet, far(?) worse than Microsoft. For whatever reason the media worships at their altar and gives them a free ride. Can you imagine the media blitz if Microsoft were to port DTrace to Win2008 and have this type of a ‘block’? There would be calls for DoJ investigation.
@Andy: You’re right. Apple’s always sneaky in this regard.
@Anantha: Microsoft gets the flak it does because, rather than porting dtrace, they’d spend years baking their own solution, or two, adding nothing and putting it under a uberrestrictive license. Apple’s slightly better from this point of view. Sneaky, but slightly better.
@Andy: It’s hardly "hidden" if the source code is available to the public.
Congrats Adam, for topping Jonathan’s blog in hits. And you haven’t been slashdotted either!
The fix is to either not run that particular kind of trace (which, honestly, is not as common as you pretend), or only run it when you aren’t using iTunes (can you really not spare the music?) or recompile with the source that you obviously have right in front of you.
This is impolite on Apple’s part, but hardly as scandal-worthy as some are acting.
This has nothing to do with Apple being an evil large corporation.
Like it or not, content creators and patent owners *do* have certain legal rights, which they can and do enforce against Apple, or anyone else who wants to use their intellectual property. In order for Apple to legally license and use patented DVD playback technology they’re contractually obliged to do all they possibly can to prevent direct access to the decoded images (eg. via a debugger). Likewise, in order to be allowed to distribute copyright-protected via iTunes they’re contractually obliged to prevent access to the decoded audio.
Yes, you may be able to circumvent this, but in doing all they can to try and stop you (which includes disabling dtrace and gdb in iTunes) Apple have done their part, and if you persist and circumvent such mechanism to access copyrighted data you’re not entitled to then you’re committing a criminal offence (DMCA and similar).
Just because it’s easy and fun for us as developers to pry into other people’s code and data which happens to be resident as a temporary guest on our hard disk doesn’t mean it’s morally right or legal to do so. Just because it happens to be a lot easier to rip a CD than photocopy and bind an entire book doesn’t actually alter the equation in any way.
I should add that I think it’s great that Apple have embraced open source and opened up OS X as much as they have. As a developer it’s just fantastic that gdb and dtrace, perl and gcc, ssh and ant etc. are all just there when I need them. Apple could just have easily turned around and said "we don’t see the value of those tools for our core customers, why should we bother to include them?" Minor gripes like dtrace not working on some processes are a very small price to pay for this convenience.
@Much Ado: You’re missing the point. This doesn’t just impede my ability to examine certain apps (as Apple intended), it actually will cause a user to get invalid results from correctly phrased DTrace queries.
It’s annoying that Apple decided to disallow tracing for applications that choose to opt out, and it’s a fairly serious issue, but the bigger issue is that in doing so they’ve broken DTrace.
I’d argue that the right and noble way to fix this is to allow DTrace to examine all apps, but Apple could also fix DTrace’s profile and tick probes without exposing what they deem to be sensitive information.
@Rolf: Did you know why the Darwin project failed?
Why Darwin Failed
http://www.synack.net/~bbraun/writing/osfail.html
Apple and ‘getting’ Open Source
http://www.synack.net/~bbraun/writing/gettingos.txt
"Apple’s Open Source efforts with the Darwin project have been a failure. Apple failed to build a community around Darwin in the 7 years since its original release because it was not a corporate direction, but rather a marketing stunt. Culturally, Apple did not and does not understand what it means to be open source or to build a working community." — Rob Braun
What sucks more than them having this mechanism, is the inability to build DTrace from source. Sure, they provide you with *most* of what you need, but it’s missing key components.
First you need to get libiberty on there (make sure to build a universal binary!). This was a PITA for me, but perhaps I did it wrong.
Then it relies on the private framework Symbolication, which ships with no headers. You can get the headers for this by using class-dump on the Symbolication binary (/System/Library/PrivateFrameworks/Symbolication.framework).
It also relies on "Scanalyzer", which seems to deal with determining if a PPC function is safe to be probed. Of course, this library also doesn’t have headers – in fact, it doesn’t even have a binary file for it! It was compiled into libdtrace as a static library. Not sure how safe it is to comment out the Scanalyzer stuff.
At this point, I was able to compile, but it didn’t link because I apparently screwed up libiberty:
ld: warning in /usr/local/lib/libiberty.a, file is not of required architecture
That’s where I gave up.
Also, you need more spacing (or some sort of separation) between each comment on this blog. It’s hard to read!
Hmm, seems that dtrace on OS X doesn’t give precisely the right results even with iTunes not running. On my single-CPU system, I get numbers slightly above and below 1000:
0 18616 :tick-1s
1000
0 18616 :tick-1s
999
0 18616 :tick-1s
1002
0 18616 :tick-1s
997
0 18616 :tick-1s
999
Does Landon Fuller’s kernel extension which fixes ptrace() help here? Googling for "landon fuller ptrace" will find the page…
Thanks
How does this flag become set? Presumably there is some syscall which turns it on, which might be locatable in the itunes binary, which can be removed?
Adam, this is fantastic information. As a fellow Sun employee this just underscores what we keep saying: the OS matters. Now we know another reason about why the COMPANY matters as well. Lots of people complain that if Sun would just GPL everything then somehow we’d achieve world peace. It’s not necessarily so. Any piece of code can be altered to suit a need, be it political or technical. If you don’t have a bona fide development force behind it, it’s not much good.
As you said, Solaris is out there, it’s open sourced and has a company behind it that has an undeniable decades-long track record of contributing to the open source community.
It doesn’t matter if Apple sets the P_LNOATTACH flag for certain applications. That action does *nothing* to impede a serious hacker.
IMHO doing stuff like this just makes Apple look silly. If they *have* to implement ridiculous "hurdles" to make the record companies happy… fine, but then just document it and move on.
This definitely isn’t something someone should have stumbled across.
@Peter Clay
It’s certainly doable to patch the iTunes library, but it shouldn’t need to be done. Btw, the call is:
ptrace(PT_DENY_ATTACH, 0, 0, 0);
PT_DENY_ATTACH is actually documented in the ptrace(2) manpage if you’re interested for a more detailed explanation.
@Chris
Landon’s kernel extension doesn’t work on Leopard. Apple removed the functions he was using to hook ptrace — just like they said they were going to. Here’s part of the comment from the Tiger kernel source:
WARNING – these are temporary KPI that allow binary compatibility with shipping product that must patch ptrace. These KPI will be removed in the next system release that follows Tiger. radar – 3928003
I’m amazed and ashamed that anyone is even trying to defend Apple’s behavior. There’s simply no excuse.
Well, now you know. GPL v3
It’s the Bozo Bit all over again.
http://zhurnal.net/ww/zw?BozoBit
Regarding my pt_deny_attach.kext, I’ve implemented a new version for Leopard: http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html
From http://en.wikipedia.org/wiki/DTrace
"Unlike other platforms that DTrace is supported on, Mac OS X has a flag (P_LNOATTACH) that a program may set that disallows tracing of that process by debugging utilities such as DTrace and gdb."
Problem is not with the DTrace port. It has to do with the fact that iTunes sets P_LNOATTACH.
@Agnel: This is the magic of wikipedia: that text was added *as a result* of this post. And if you read all of this post, you’ll see how there’s a problem with Apple’s implementation of DTrace in and of itself.
If we haven’t all learned our lesson about trusting wikipedia, read the cautionary tale of Wikipedia Brown: http://adamcadre.ac/content/brown/
Considering how heavily Apple profits depend on iPods and other gadgets which use DRM, makes you wonder why they would port dtrace in the first place. Crippling dtrace was just .. stupid.
Why don’t you recognise Apple may have legitimate concerns and reasons for doing this and instead of whining instead offer to assist them in improving how their implementation works?
The people excusing this by saying that Apple have legitimate and/or contractual obligations to protect DRM’d content seem to be ignoring two important points:
a) They could have implemented the opt-out in a way which doesn’t break everything else. They deserve criticism for their poor implementation regardless of the reasons behind it.
b) Since it is so trivial to bypass their opt-out and add traces to iTunes with patches people have already made, they have not fulfilled their obligations to protect DRM’d content at all, unless the obligation was to make it take five minutes longer for someone to break the DRM.
Fail.
@Leo DTracing iTunes != breaking DRM. It just makes it easier.
I don’t see the surprise here. Apple produce a proprietary operating system, it’s hardly surprising that they’d try and extend those sensibilities into their implementations of a technology, regardless of whether that technology is itself open source or not. If Sun really wanted DTrace and its ilk to be used in the ‘spirit of open source’, it wouldn’t have chosen a license that prevented it being used by GPLed software (such as Linux) but allows it to be freely used by proprietary vendors such as Apple and Microsoft (who would have added similar modifications to their own implementation).
I downloaded the latest DTrace source from http://www.opensource.apple.com/darwinsource/10.5/ and don’t see any mention of P_LNOATTACH. Is the modification limited to the commercial release of OS X 10.5? Or am I looking in the wrong place?
I take that previous comment back 🙂
I realize that the offending code lives in the Mac OS X kernel’s implementation of DTrace hooks, and not the DTrace client software.
I’m not defending Apple in this post, but merely making an observation that others have made above. Namely that this probably has more to do with DRM and their relationships with big media than the overblown "evil" theories mentioned here. I don’t like it either, but if using dtrace can potentially lead to circumventing the DRM on iTunes media then Apple has to take reasonable steps to stop this in order to protect their relationship with their partners. Yes, DRM sucks, I hate it too. Yes, wouldn’t it be nice if they only listened to their customers instead of big media. But the reality is they are trying to create an ecosystem for digital media and right now they have to protect and nurture their relationships with big media until the media companies pull their collective head out and realize that DRM is not the answer.
It’s called balancing priorities and it’s an unfortunate tightrope walk that many companies have to do. They aren’t any more "evil" than any other company in this day and age. ALL companies have to cover their ass and do what is best for stockholders these days or they risk a lawsuit from someone. I don’t think there is any company that can avoid these types of comprimises when then get as large as Apple. The dtrace issue is unfortunate, but let’s not throw out the baby with the bathwater here.
Are you kidding me?!! My comment that I wrote was just rejected. Why? . . .
Your comment was marked as spam and will not be displayed.
* Comment contains blacklisted/ignored words
Considering my post just discussed Apple’s relationship with big media and how this might affect the dtrace issue I’m at a loss to see why it was blocked. Maybe you could fix your own censorship on your site before you start throwing stones at anyone else. This seems a bit hypocritical.
@Dick Davies: Yes, yes, that’s been mentioned…
@Andrew Hughes: First, wrong; also, off topic. Go ahead and read some of my previous posts.
@Cromartie: Right; check the xnu source. The DTrace code that’s in the kernel is really more than should be considered "hooks."
@Brian: Calm down, calm down. I have no idea why your comment was rejected, and it will surprise you to hear that I don’t actually run blogs.sun.com myself. But I’ve approved your comment "making an observation that others have made above"; it should now be displayed.
Thanks Adam. Maybe it was the use of the word "a$$"? I just noticed that. Maybe I should calm down. . . I thought I was drinking decaf!
Anyway, thanks for posting it.
As a software developer that has never used DTrace, I can’t speak for DTrace or the severity of the missing ticks or how easy it would have been for Apple to code it correctly – meaning with unintended consequences. But I can speak for how easy it is for even an expert coder to make what you think is a clever enhancement to someone else’s complicated system (I assume the DTrace software is complex) and have it produce undesirable consequences.
I’m sure Apple (the company) was afraid of traceability of DRM. I’m sure Apple (the company) told Apple (the coder) to see what could be done. I’m sure the coder found this clever enhancement to satisfy the company’s requirements with minimal intrusiveness to the code. I’m sure the coder didn’t intend, expect or notice the other consequences. I’m sure that the DTrace experts at Sun might have a suggestion at how to implement a better trace op-out that the coder could make that would still keep the company satisfied.
Apple is evil? Maybe – maybe not. But certainly not for the lone coder at Apple making a simple mistake, the kind we all make all the time.
Let’s celebrate the fact that we actually have access to the source and can find their bug and contribute to solution.
I wonder how many Oracle technicians would complain if Oracle prevented DTrace efficacy?
Surely, Oracle has considered the possibility. Their revenues shadow Apple’s, but they don’t have any fear.
What’s Apple afraid of? They clearly have a better product in many ways to their real competitors. I predict they WILL listen and react soon to the empowerment of a uniform diagnostic method.
This is what you get when using CDDL.
It’ too late to complain now.
If dtrace was GPL code, you could just recompiled the
(then GPL’ed) Mac OS X kernel with dtrace enabled all over and be happy.
Something to consider for your next great project…
@Thomas – this is hard to say, but the GPL is not the solution to all the worlds ills.
Releasing DTrace under GPL wouldn’t magically make OS X GPLed. They just wouldn’t use it. Nor would the BSDs, or anyone else who wants to be free to choose what license to release code *they* write under .
The license is irrelevant – it can’t make AAPL write good code, and having to rebuild your system with custom code just to monitor an app isn’t really in the spirit of DTrace.
(Off topic)
@Dick – It doesn’t matter if the DTrace source is CDDL’d or GPL’d for the BSDs. The fact that it is not BSD licensed just means that the interface needs to be shimmed so that no kernel code requires a CDDL/GPL file to compile.
From the work I’ve done on FreeBSD, I believe it is possible to port DTrace to Linux in the same manner. The trick is to make the shim headers BSD licensed.
@Adam: Maybe you could justify why you think my comment is wrong and off-topic, given it answers directly a comment made in the main story.
I wasn’t the one who brought up the topic of licensing, you mention it yourself with your comments on Apple’s behaviour being ‘antithetical to the spirit of open source’ and my reading of this has this as the central topic of this blog. What would you expect from a proprietary software company who promote themselves as open source players (http://www.apple.com/opensource/) but don’t contribute back to the community (just look at the OpenDarwin fiasco).
@John, yes there’s nothing stopping DTrace technically being implemented in Linux AFAIK. But it can’t be done legally as the CDDL and GPL are incompatible. This is why ZFS is ported as a FUSE module and not as part of the filesystem (http://zfs-on-fuse.blogspot.com/2006/05/announcing-zfs-on-fuselinux.html).
To include them at present would mean not using the Sun code but rewriting from scratch under the GPL.
@John: I don’t want to revisit this specific issue, but it’s worth noting that Sun’s lawyers disagree with John on the specific mechanism of what’s required to construct a legal port. So do others. I deliberately don’t have a law degree so can’t elucidate.
@Brian: Agreed! There are several other bits of "cleverness" in the Apple port, though the worst of them is only minimally damaging.
@Andrew:
1) Saying "the spirit of open source" is not an incantation which summons the demon of licensing pedantry.
2) Apple has or intends to contribute all the changes they’ve made to DTrace back to OpenSolaris (I don’t think we’ll be buying back P_LNOATTACH though…).
3) I suppose if you interpreted my phrase "the spirit of open source" to mean some RMS-ian utopia where source code is made open at knife-point I can see why your comment would be construed as on-topic. What I meant by that phrase was something far less radical: just that modifying open source software to disable certain features runs counter to what I deem to be a culture of leaving the software better than you found it.
4) Like I said before, read some of my other recent blog posts; then tell me why you couldn’t port DTrace to Linux.
5) I happen to agree with the choice of the CDDL because of its ability to mix closed-source code with open-source code — there’s no such thing as a tainted OpenSolaris-derived kernel. That compiling CDDL code together with GPL v2 code would violate the GPL (not the CDDL however) is unfortunate for the reasons you described, but I’m sure the legal issues aren’t insurmountable.
http://dtrace.org/blogs/ahl/what_if_machine_dtrace_port
You say that Apple’s modifications to DTrace are "antithetical to the spirit of open source." iTunes is not an open-source application.
@Bobbert: Welcome Slashdot reader. I believe the expression is ‘RTFA’.
it’s an interesting problem for apple – particularly since through iTunes apple is trying to appease both the MPAA (Movie sales and Rentals) and RIAA .. i mean i can understand why they might want to limit what can be seen and modified to protect some of the keys .. but the roll up the drawbridge and prevent kernel snooping sort of approach seems a little dysfunctional and inelegant .. perhaps they should have grabbed more of the crypto kit to get at a deeper understanding of how these sorts of things can both be openly snooped and quite well protected at the same time .. it just reveals some of the inexperience of their implementors
@Adam: Thanks very much for the explanation, it’s very much appreciated. I think we are actually on the same wavelength, although it may not have seemed so. If there is some vehemence in my initial post, then it’s because I’m sick and tired of licensing compatibility issues within the FOSS community stopping what is technically possible, having had to deal with them in various forms for the last four years or so.
My open source stuff wasn’t an RMS-inspired rant, although now you’ve brought it up my feelings do swing that way. I think a lot of the issue there though is that people tend to take the issue out of all proportions. I just feel that if I’m going to share my code, then those who use it should also share. And what you’ve highlighted here is the main reason for that.
You’re exactly right in that such a hack goes against the grain of improving the source. If that patch was submitted in an open source community, it wouldn’t be committed. I guess it would be laughed at, much the same as a patch to ‘phone home’ would be (another ‘feature’ of some proprietary applications). Why? Because such a patch has no technical advantage, it’s purely a code hiding tactic — legal responsibilities again, and I think they are the bane of developers everywhere and more so by the day.
Thanks for pointing me at your other blog. I came here via Simon Phipps’ blog so hadn’t seen it. I agree with what you say there, it is possible. I suppose I should have been clearer in saying it’s not possible to do a direct port. Again, legal issues create greater technical problems. The ideal solution would be to port largely wholesale (as much as possible) and have no legal worries.
I have no allegiance to Linux in particular. I’d much rather be running some GNU/Solaris combo to be honest as I feel Solaris is the much more mature, developed and developing kernel. The problem? The driver support just isn’t at the same level as on x86 yet but it’s getting there. That’s not just hyperbole; I tried Indiana recently on an x86 box and it couldn’t pick up my NIC (I need to download the Via Rhine drivers separately). Not a problem for me, but a problem for some of the users we’d hope to eventually attract.
So if you look in the OpenSolaris dtrace source (http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/dtrace/dtrace.c ), what do you find:
5390 /*
5391 * Kick out immediately if this CPU is still being born (in which case
5392 * curthread will be set to -1) or the current thread can’t allow
5393 * probes in its current context.
5394 */
5395 if (((uintptr_t)curthread & 1) || (curthread->t_flag & T_DONTDTRACE))
5396 return;
A flag that disallows dtrace probes??? I am outraged! How can Sun violate the spirit of dtrace in this way?
@Anon: Another day, another Slashdot reader…
"If there is one thing I learned from Slashdot, it is that people are dumb." — Rob Braun
I once made a web database of movies. Some movies were copyright, some were public domain. I had to do everything I could to make it impossible for unapproved people to download the copyright movies cause I had a bit of a legal obligation to do so. If, in the process, I screwed something up, that would be a bug and I would then go fix it.
Someone can file this as a bug at bugreporter.apple.com. If Apple closes the bug saying that it works as intended, then you can say Apple has done Dtrace a disservice. Or you could just find the lone programmer who wrote that code and tell them it busted Dtrace and he will probably say "DOH!" and go back and fix it.
As a side note, no wonder I couldn’t find the iPod tracks playing in iTunes with 10.5. I had to put it on a 10.4 box and run fs_usage…
@Kris Kelvin
Nice guess, but I’m not a slashdot reader.
How about commenting on my post, that Solaris itself has an equivalent dtrace feature to the one being complained about in Apple’s dtrace port?
@Anon: Kevin and I made the same assumption (i.e. that you were just an obnoxious spammer) because your comment was fairly inflammatory and obviously wrong. For people trying to understand why DTrace in the OpenSolaris code base contains code to ignore a thread, it’s not because we’re preventing users from viewing content that shouldn’t be seen, rather there are some contexts in which it would be invalid to perform the sort of activities we do during tracing (i.e. arbitrary loads from memory) due to hardware reconfiguration. In other words, this is necessary for DTrace to work _properly_.
If you take a look at the _one_ place in the source base where we set this flag, it should be fairly obvious what’s going on:
http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/sfmmu/vm/hat_sfmmu.c#6598
[Trackback] I feel like I
Do you have any further information on what other Apple applications might enable the P_LNOATTACH flag? I suspect iDVD, or DVD Studio Pro, might also be guilty…
@Juan I haven’t done that myself, but it seems like you can use nm(1) to see if an application or shared library contains a reference to the ptrace(2) system call:
$ nm /Applications/iTunes.app/Contents/MacOS/iTunes | grep ptrace
U _ptrace
$ nm /Applications/iCal.app/Contents/MacOS/iCal | grep ptrace
$