macosdebuggingkernelkernel-extensionxnu

Setting up two-machine kernel debugging over network

I'd like to check the option to debug my kernel driver installed over remote physical machine (since I don't have firewire cables). Reading the relevant documentation, I haven't seen any limitation about remote physical debugging medium, so I deduced both firewire cables and ip over wireless network should work.

I thought that lldb remote connection using kdp-remote <machine-ip> would do the trick, but I don't get any response.

From remote VM however, it succeed even though the VM can be located on remote physical machine.

My boot-args configuration are keepsyms=1 debug=0x144 -v

Solution

  • We figured out the problem in the comments (item 2 below), but for posterity, here's a list of things to check if xnu kernel debugging isn't working:

    1. The target machine must have a physical ethernet port which is connected via PCIe or Thunderbolt, or you must use a direct firewire connection (optionally via Thunderbolt). USB to ethernet adapters will not work on the target end. The client machine is less fussy, you can use wifi or USB-ethernet there.
    2. The protocol uses UDP, not TCP. Have you got a firewall running on your lldb machine which might be blocking UDP packets? (You could try sending udp packets from target to client with the nc (netcat) tool while the machine is not crashed.)
    3. Is the ARP entry correct on the client machine? arp <target ip> should yield the target interface's MAC address.
    4. The crashed Mac will NOT respond to pings, only to KDP packets via UDP. So not getting pings back doesn't mean anything.
    5. As far as I'm aware the machine won't request a new DHCP lease when it crashes, so that shouldn't be the problem, but you can always try setting a static IP address just to be sure.
    6. Did you reboot after setting the boot-args? They only take effect on a fresh boot.
    7. If SIP is active, you can only set nvram variables from the recovery environment from OS X/macOS 10.11 onwards. You can run nvram boot-args to verify that the settings stuck.

    My personal recommendation is to use FireWire for kernel debugging if possible, it seems to be the fastest and most reliable in my experience.