March 2006 - Darwin-kernel - lists.apple.com

Re: Hello Debugger/Goodbye Machine
by Eric Long 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 FWIW, I got kernel debugging working perfectly using my Intel iMac as the target. It has built-in Airport, which I just turned off via the system menu. No problems at all. Just had to go grab the Intel Kernel SDK. No more sudden death and no loud fans problems. I'm happy. Thanks to everyone who gave feedback. Of course, if I didn't have another machine as an option, this would be a pretty nasty roadblock. Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Andrew Gallatin 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Terry Lambert writes: > > It's not a bug, and I'm unwilling to discuss the security implications > further. I'm sorry to bring it up.. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Terry Lambert 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Mar 10, 2006, at 10:37 AM, Andrew Gallatin wrote: load: mydriver.kext sudo chown -R root:wheel mydriver.kext (sudo kextload -s . -r . mydriver.kext; sudo chown -R $ (USER):wheel mydriver.kext) That's a feature, not a bug. The intent is to make it impossible for third parties to demand-load a KEXT that does malicious things behind your back, without you first granting explicit authorization during the install by typing your admin password. If it were not this way, it'd be trivial to compromise your machine from a shell account. It is a bug. If I, as root, explicity request that a KEXT be loaded, it should darned well be loaded no matter who owns it. I assume that by "demand loading", you mean automagically loading a KEXT as a dependancy? I agree that there should be security checks on that, but they shouldn't apply to an explicit kextload issued by root. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Terry Lambert writes: You might want to do the chown before you try loading it, or the first time will always fail... ? I do.. Sorry; I mistook the second chown as the chown you were complaining about. Mea culpa. Mike Smith caught me out on this one, too. The only drawback is that the NFS fs must be exported with root=0 to avoid running into the bug that requires kexts be owned by root:wheel. It's not a bug, and I'm unwilling to discuss the security implications further. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Andrew Gallatin 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Terry Lambert writes: > > load: mydriver.kext > > sudo chown -R root:wheel mydriver.kext > > (sudo kextload -s . -r . mydriver.kext; sudo chown -R $ > > (USER):wheel mydriver.kext) > > You might want to do the chown before you try loading it, or the first > time will always fail... ? I do.. > > The only drawback is that the NFS fs must be exported with root=0 to > > avoid running into the bug that requires kexts be owned by root:wheel. > > That's a feature, not a bug. The intent is to make it impossible for > third parties to demand-load a KEXT that does malicious things behind > your back, without you first granting explicit authorization during > the install by typing your admin password. If it were not this way, > it'd be trivial to compromise your machine from a shell account. It is a bug. If I, as root, explicity request that a KEXT be loaded, it should darned well be loaded no matter who owns it. I assume that by "demand loading", you mean automagically loading a KEXT as a dependancy? I agree that there should be security checks on that, but they shouldn't apply to an explicit kextload issued by root. > And compile up your own copy that removes this restriction. I > recommend that you do not do this; if you do it anyway, I recommend > you do not give people shell access to the modified machine. I don't think I'd even want to give people shell access to an *unmodified* mac, based on the recently publicised security contest (http://www.zdnet.com.au/news/security/soa/Mac_OS_X_hacked_in_less_than_30_m…) Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Eric Long 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 >> I turned off Airport, including disabling it in my port >> configurations and >> still had the problem. >> > > > That was my experience too. Disabling in software had no effect, I > had to physically remove the card. And it works under Panther and > Jaguar, so something is messed up in Tiger. I tried Terry's suggestion and removed AppleAirPort.kext and AppleAirPort2.kext. That didn't help. Someone wrote offlist: > Yeah, your not going crazy. I've seen that a lot. I think its an > interaction with the power management hardware. I think so too. But the fact that Brian Bergstrand had success by removing his AirPort card suggests it may be a combination of factors. I tried debugging via Firewire... And the target PB still shuts down when I enter "continue" from gdb on the dev G5. At this point I'm just going to accept that I can't use the PB as a target. I don't like using the G5 as a target because the fans get to revving so loud. I also have an 20" 2GHz Intel Core Duo iMac, so I'll try to work with it. It has built-in AirPort as well, but who knows. Maybe it will work. Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Terry Lambert 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Mar 10, 2006, at 5:20 AM, Andrew Gallatin wrote: For early development, I find it easiest to build in an NFS mounted volume and simply load my kext from there. That way, if something explodes, I can skip steps 2-3. Here is a makefile snippet: unload: mydriver.kext sudo kextunload -m com.mycompany.iokit.mydriver Now all I do to load the driver is "make load". When^H^H^H^Hif it crashes, I have the symbols ready to go. The only drawback is that the NFS fs must be exported with root=0 to avoid running into the bug that requires kexts be owned by root:wheel. -- Terry Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Terry Lambert writes: For symbolication for kext debugging, there's a knowledge base article on kext debugging on developer.apple.com that covers things pretty thoroughly, but here's the gist of it: (1) Get a debugger attached to the machine that has the kext that you want to debug loaded (2) Use the "showallkmods" command to get the load address for the kext (3) Execute the command "kextload -s /tmp -n <my_kext_name.kext>"; it will ask you for the load address (replace "<my_kext_name.kext>" with whatever your kext is) (4) Add the symbol file into the debugger using the "add_symbolfile <symbol_file_name.sym>" (replace "<symbol_file_name.sym>" with the name of the symbol file that was generated by the "kextload" command in step 3) (5) Happy Debugging! load: mydriver.kext sudo chown -R root:wheel mydriver.kext (sudo kextload -s . -r . mydriver.kext; sudo chown -R $ (USER):wheel mydriver.kext) You might want to do the chown before you try loading it, or the first time will always fail... That's a feature, not a bug. The intent is to make it impossible for third parties to demand-load a KEXT that does malicious things behind your back, without you first granting explicit authorization during the install by typing your admin password. If it were not this way, it'd be trivial to compromise your machine from a shell account. Obviously, if this bothers you enough, you can download the kextd sources from: <http://darwinsource.opendarwin.org/10.0.4/system_cmds-175.2/kextd.tproj/ > And compile up your own copy that removes this restriction. I recommend that you do not do this; if you do it anyway, I recommend you do not give people shell access to the modified machine. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Andrew Gallatin 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Terry Lambert writes: > > For symbolication for kext debugging, there's a knowledge base article > on kext debugging on developer.apple.com that covers things pretty > thoroughly, but here's the gist of it: > > (1) Get a debugger attached to the machine that has the kext that you > want to debug loaded > (2) Use the "showallkmods" command to get the load address for the kext > (3) Execute the command "kextload -s /tmp -n <my_kext_name.kext>"; it > will ask you for the load address > (replace "<my_kext_name.kext>" with whatever your kext is) > (4) Add the symbol file into the debugger using the "add_symbolfile > <symbol_file_name.sym>" > (replace "<symbol_file_name.sym>" with the name of the symbol file > that was generated by the "kextload" command in step 3) > (5) Happy Debugging! For early development, I find it easiest to build in an NFS mounted volume and simply load my kext from there. That way, if something explodes, I can skip steps 2-3. Here is a makefile snippet: load: mydriver.kext sudo chown -R root:wheel mydriver.kext (sudo kextload -s . -r . mydriver.kext; sudo chown -R $(USER):wheel mydriver.kext) unload: mydriver.kext sudo kextunload -m com.mycompany.iokit.mydriver Now all I do to load the driver is "make load". When^H^H^H^Hif it crashes, I have the symbols ready to go. The only drawback is that the NFS fs must be exported with root=0 to avoid running into the bug that requires kexts be owned by root:wheel. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Brian Bergstrand 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 9, 2006, at 5:24 PM, Eric Long wrote: Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEENOjedHYW7bHtqIRAm8SAJ9c8nOHOq/NZg0Vml2bR4SJ47VCnwCgiyPr dmefkjt9YzSfomsf6broPeI= =EpY8 -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… So pretty clearly, the AirPort issue is that you are connected, and the default route is through that, rather than through the attached network cable. If you tell it to not use the AirPort by disconnecting/disabling it in software, your problem should go away. There's no need to physically remove the card. I turned off Airport, including disabling it in my port configurations and still had the problem. That was my experience too. Disabling in software had no effect, I had to physically remove the card. And it works under Panther and Jaguar, so something is messed up in Tiger. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Derek Kumar 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com There is a document included in the kernel debug kit, as well as a kext to permit debugging over FireWire. FireWireGDB - Special-purpose debugging over FireWire. I have been using: sudo kextload -s /tmp /tmp/MyKext.kext The KDH Read me has this tidbit: On Mar 9, 2006, at 7:39 PM, Eric Long wrote: Where can I find instructions to configure for Firewire debugging? Ok. I downloaded Kernel_Debug_Kit_10.4.5_8H14.dmg. The only document inside is "Kernel Debug Kit Read Me.html". It doesn't contain the word Firewire. None of the documents it points to via links seem to tell either. This is actually in the FireWire SDK, which you can download at: http://developer.apple.com/sdk/ The components of interest would be: FireWireKPrintf - High speed logging that hooks into kernel kprintf() output. FireLog - High speed logging, faster and more flexible than FireWireKPrintf. FireWireKDP - Remote interactive Kernel debugging over FireWire. FireWireCoreDumper - kernel coredumps over FireWire (All of which are useful if you're doing early debugging, or if the network is unavailable for some other reason). Yes. You must explicitly symbolicate your kext, " This package now includes the createsymbolfiles script which simplifies creating symbol files for kernel debugging. Run this script as follows: $ /Volumes/KernelDebugKit/createsymbolfiles -s <symbols_directory> <KEXT_to_load>" So evidently there is a useful tool there, but since it doesn't explain it's utility over simply using kextload -s, I don't know what it really does. This appears to be a script which wraps kextload to use /Volumes/ KernelDebugKit/ as the source of the kernel image and kext repository, among other things. Easier than passing lots of flags to kextload, I'd imagine. So, unless it's the boot volume, I assume this means the source paths, including volume name, must match, at least with the aid of a symbolic link. Yes. Also, the SO stabs embedded in the kernel image supplied with the kits contain paths of the form: /SourceCache/xnu/xnu-792.6.56/bsd/vfs/vfs_syscalls.c (as with open() for instance) If you install the kernel sources, and create the appropriate SourceCache symbolic link, you can also examine kernel sources while debugging with gdb. Derek _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Hello Debugger/Goodbye Machine
by Eric Long 10 Mar '06

10 Mar '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 > /Developer/Extras/Kernel Debugging/README: > ========================================= > KDP Debug over FireWire > ----------------------- Aha! Thanks. Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0