I'm trying to kernel debug a physical Macbook pro device.
When my setup contains a VM, between a host MacOS and guest MacOS, its working with no problem using lldb -o "kdp-remote <guest_machine_ip>"
my boot-args on my remote (to debug) Macbook are:
user$ nvram boot-args
boot-args debug=0x44 kext-dev-mode=1 pmuflags=1 -v kcsuffix=debug
When i'm triggering kernel debug using either
sudo dtrace -w -n "BEGIN { breakpoint(); }"
or LEFT CMD + RIGHT CMD + PowerButton, the system is in halt mode, not responsive to anything (Mouse not moving, etc)
But when I'm trying to connect to the machine from the host using the lldb command provided earlier, it's not working.
I've made sure the machines can ping each other and I can set up a SSH connection.
To the best of my understanding, I had to user special Apple adapters (Real™ Ethernet adapter), so I'm using the following adapters to debug the remote machine:
https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter
https://www.apple.com/shop/product/MD463LL/A/thunderbolt-to-gigabit-ethernet-adapter
The physical connections setup looks like that:
MacOS-Debugger --(USBC to Ethernet adapter)--> Ethernet cable <-- (ThunderBolt to Ethernet adapter) <-- (ThunderBolt3 to ThunderBolt2 adapter) <-- MacOS-debuggee
Generally for the debugging I used the following tutorial, which worked for VM debugging:
https://knight.sc/debugging/2018/08/15/macos-kernel-debugging.html, I didn't find the exact KDK version, but I don't think it should be the problem here
My debugger is BigSur, and my debugee is Catalina
Any ideas to what the problem may be will be helpful
Your hardware setup sounds fine. Note that you don't necessarily need a direct ethernet cable connection, you can use your normal office-/home-wide wired network, it's fine to have a switch (or even more than one) between debugger and target. The debugger machine can even be using wifi as long as it can reach the target's wired network connection that way, though it's not recommended. The Thunderbolt Ethernet interface need not be Apple branded, but its driver does need to include kernel debugging support. In practice, for example, I've successfully used the Ethernet port in a OWC brand Thunderbolt Dock as well. Using one of Apple's own adapters of course guarantees it will work.
If the boot-args on your target machine are the same as what you used in the VM, that's probably where your problem is coming from. You should specify the device to be used for kernel debugging, using the kdp_match_name= option. Use the ifconfig command in the Terminal to work out which of the listed devices is your Thunderbolt ethernet adapter (enX), possibly based on the IP address. en0 is typically wifi in Mac laptops, so you're usually looking for X > 0.
So you'll end up with something like kdp_match_name=en1 added to your boot-args. Make sure to reboot the machine cleanly before attempting a debugging session after updating the boot-args setting.
A few more comments:
kext-dev-mode=1
This option no longer has any effect. It only existed in OS X 10.10. You can remove it.
I didn't find the exact KDK version, but I don't think it should be the problem here
Having a KDK version that doesn't match the target's exact kernel binary UUID will not prevent a connection, but it will prevent you from doing any meaningful debugging as the memory layout of threads etc. will not be available.
My debugger is Big Sur, and my debuggee is Catalina
If you ever run Big Sur on your target, make sure to add wdt=-1 to your boot-args or the hung/crashed machine will reboot before you get a chance to connect with the debugger.
Related
I'm working on STM32H7 evaluation boards (Nucleo-144 and EVAL2). My IDE is STM32CUbeIDE.
My goal is to debug remotely: run STM32CubeIDE (or another IDE) on a Linux server and connect to the board through the network.
I could run successfully the following setup:
connect the board to a local PC
launch GDBserver on this local PC
on the distant Linux server, setup the Debug Configuration to connect to the remote GDB server.
This is working fine. But I need to go further: I'd like to remove the local PC, ie. the board would be connected directly through ethernet to the network.
I've been told that there is a JTAG/Ethernet adapter for Xilinx, called Smartlynq that allows to do that, but the way it works is a bit confusing for me.
Do you know about an equivalent for STM32 ecosystem ?
Would there be another setup to debug remotely without a PC in between ?
The Segger J-Link PRO is a JTAG/SWD debugger for ARM that supports Ethernet. Like the other J-Link models, it should work fine for STM32.
Use a Raspberry PI as a debug adapter.
It would be somewhat cheaper than a JLINK Pro. If there is WLAN available, take a Pi Zero W, otherwise you'd need one of the bigger ones with Ethernet. Set it up for remote work (enable ssh, set a fixed IP address etc), then you can disable the GUI desktop, and disconnect the display and the keyboard.
Running gdbserver
The Pi has an ARM CPU which supports the Thumb instruction set but not Thumb-2, so its native gdbserver might be able to debug a Cortex-M7 controller. If it can't, then you have to install the gdb-arm-none-eabi package on the Pi.
Connectint to the target board
There are two alternatives.
Connect the onboard debug adapter to an USB port on the PI, and run openocd just the way you do it on a PC.
Bypass the onboard debug adapter, and connect some pins on the Pi directly to the SWD pins of the target. You have to remove some jumpers to disable the onboard debug adapters. There is a tutorial at Adafruit on how to compile and use openocd with native SWD support.
I have to use firewire as my kernel extension loads before the target has an IP address.
My kernel extension calls PE_enter_debugger() in its start routine.
I see "waiting for debugger" twice, then just once the console says
"kdp_poll: no debugger device".
I would think that means the nvram boot-args is wrong but I've
followed the instructions:
debug=0x814e kcsuffix=development kdp_match_name=firewire fwkdp=0x8000
The host is a late 2012 Mac Mini, macOS 10.12.4 build 16E195.
The target is a mid 2010 Mac Pro with the same macOS build.
My kernel debug kit matches the macOS build.
Google yields no joy. Have you a clue for me?
The 2010 Mac Pro has built-in Firewire ports and no Thunderbolt, so I think your problem might be the fwkdp=0x8000 setting. As far as I'm aware, you only want to set that if you're debugging through a Thunderbolt-Firewire adapter (or Thunderbolt display's or dock's Firewire port) on the target machine side.
(Sorry, only just seen your question as I have alerts on the 'xnu' and 'kext' tags but 'kernel' and 'osx' are too noisy.)
I learn to use lldb to debug mac IOKit drivers in macOS 10.12.3.
two machine debug.
It's easy to connect to target machine when panic occurs.
I wonder how to show target machine system message?
Is there any command like "dmesg" in lldb?
You can connect the target and debugger machine using a FireWire cable. Set the 0x08 bit in the target machine's debug= kernel argument (DB_KPRT), and anything logged with kprintf (note: not printf/IOLog) will be routed to FireWire. (Firewire is used unless the Mac has a Serial port, which modern Macs do not - virtual machines can, though.)
To view this output, you need to be running the fwkpfv command on the Mac on the other end of the Firewire cable.
This method works fine with Thunderbolt-to-Firewire adapters and docks too, although I suspect not if you hotplug them.
I'm fighting strongly against a problem that is making me crazy.
I’m extensively using QEMU over a Win7 64bits machine for running different Linux VMs (Debian, Raspbian).
In the past I configured the network following the QEMU instructions using the OpenVPN TAP device and network bridge in Win7 : it ran perfectly and the Linux machine was able to connect the “real world” networks, internet and so on.
In the last few days, on the contrary, this nice behavior stops working. The Windows situation is unmodified (the OpenVPN TAP driver settings are the same, the bridge is still there, when the bridge is active Windows still see the network, the TAP driver becomes “busy” when the QEMU VM starts as usual, the QEMU startup scripts are still the same…), but the emulated Linux system (whatever image I use) is unable to connect the network.
The “eth0” interface is active but unable to get the IP address from the DHCP and also using fixed IP address doesn’t solve the problem, since the IP address is not seen by the “real” network.
I have tried to uninstall and reinstall again the OpenVPN TAP driver, to downgrade Win QEMU to the previous version, but no way !
The only change that I made in the HOST configuration has been to install GNS3 (with its own TAP driver), but without including the QEMU VM in any GNS3 network.
Does anybody have suggestions regarding what kind of checks I have to do on QEMU in order to solve the problem ?
Any help will be appreciated
Regards
Ugo Poddine
I was finally able to get out.
I was forced to restore a previous system image : all attempts to uninstall and reinstall the OpenVPN TAP driver were useless.
The problem is probably due to the update of the OpenVPN TAP driver : with the v.9.0.0.9 no problem, but updating to the 9.21.1 seems to have generated the problem.
I'm now able to use again QEMU and GNS3 in network.
But what a strange case !
With OSX 10.5. it's no longer possible to spoof MAC addresses of your wired interface (e.g. en0) with "ifconfig en0 laddr/ether XX:YY:...."
a/ why is that?
b/ how is it notwithstanding done by e.g. VMware "vmnet-xxx" deamons?
c/ does anyone know wether the Apple Developer package contains detailed and useful information regarding the mach kernel device interfaces? e.g. device driver example code, and the like?
Thank you very much
Grusz
A: This may be a change for security reasons in the work place (this is just pure speculation, and may or may not be true), as it seems to be a driver issue (this was possible in Tiger, I know from experience). It is still possible to this on the wireless interface en1. Even if the physical interface did not support it, the device could be put into "monitor" mode and have the MAC address matching take place higher up in the IP chain. We shall have to wait and see what Apple does about this.
B: Those daemons put your wired network into "monitor" mode, basically what this does is tell your network card that you want everything that is being sent to you to be handled by the OS, so it turns off filtering that is done on the network card (if it supports it) which would normally discard things that were not destined for itself (its MAC address), and then it does it all in software, using the standard filtering hooks provided by the OS it can listen to any incoming packets and grab those off the wire that are destined to the fake MAC address that VMWare has set.
Explained in laymen terms: Lets say you are sitting at an airport and are waiting for an announcement that you can board your plane, you passively listen but ignore everything that does not contain your flight number. Now someone else comes along and asks you to also listen for their flight number, now you have to actively listen since you can't just filter on one flight number.
C: Yes, amongst other things you will find code examples and reference manuals. They are also all available online and you may find the code for most device drivers online as well if they were developed by Apple. The documentation is fairly good however I have noticed that in certain areas it has been lacking and made it fairly difficult for me to figure out what I needed to do to get something done. Developer.apple.com's Conceptual Network Device Driver. The source code for Darwin is also available at http://www.opensource.apple.com/darwinsource/, there you can find most device drivers for Mac OS X as long as Apple is allowed to release them as Open Source (Yukon2 driver is not included)
what worked for me was this, boot into a linux distro, change mac address there so that you have a working internet connection, reboot into mac os x(tried with 10.5.5), the mac stays spoofed from linux - with my pc, it worked even over system restarts/shutdowns
to be more specific, i tried this with ubuntu 8.04(i believe), to change mac address there:
sudo ifconfig eth0 down
sudo ifconfig eth0 hw ether 000102020405
sudo ifconfig eth0 up
of course you need to replace the 000102020405 with the real MAC you want to use, beware, with other distros, even different versions of ubuntu, the MAC spoofing procedure might differ slightly(you need to restart the connection etc..) - the magic of this trick is in the fact it actually might work off a live distro, so you don't need to install anything, but i never tried this
good luck
I have the MacBookPro Retina late 2013 running OSX 10.9 and I can do it!
The first thing I tried is what has previously worked for me on linux:
sudo -s
ifconfig en0 down
ifconfig en0 lladdr aa:bb:cc:dd:ee:ff
ifconfig en0 up
However, this on my machine results in an ioctl error (power is off)
So after much experimentation I figured that you must change the mac address while the interface is up, but while it is not being used by the Airport utility. This is easier said than done!
I put these commands together and fiddled the delays until my mac changed successfully - this is what worked for me:
ifconfig en0 down; sleep 0.5; ifconfig en0 up; sleep 2;\
ifconfig en0 lladdr aa:bb:cc:dd:ee:ff; ifconfig en0
You may have to change your delays so you catch it before Airport kicks in. Hope this helps!
Edit: You may have success by booting linux as "nofu" said, but it's a hassle to set up dual boot on the MacBookPro, so let me know if this "sleep method" works for you, the delay and for what version of OSX.