Lists

Open Menu Close Menu

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: remote kernel debugging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: remote kernel debugging

Subject: Re: remote kernel debugging
From: Charu Tiwari <email@hidden>
Date: Tue, 12 Aug 2014 11:38:15 +0530

I removed nvram boot-args from host machine but still no success. kdp-remote still doesn't work :(

Regards,

~Charu
Proud to be a donor of the AAP. Join the movement today. http://donate.aamaadmiparty.org

On Tue, Aug 12, 2014 at 9:50 AM, David Tay <email@hidden> wrote:

You need fwkdp running in a terminal session on the host mac. The nvram boot-args setting needs only to be applied to the target.

David
>
> Message: 1
> Date: Mon, 11 Aug 2014 18:12:33 +0530
> From: Charu Tiwari <email@hidden>
> To: email@hidden
> Subject: Regd. code-sign API on 'xpcproxy binary' hang and remote
> kernel debugging
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset="utf-8"
>
> Our application/component basically provides user control to block/allow
> applications in Mac OS X. It has following features
>
>
>
> i) Create a rule to Allow/block 'launch' of different applications by
> creating a rule.
>
> ii) Create a rule to Allow/block network access to an application.
>
>
>
> Our application has a kext 'App.kext' which registers for
> 'KAUTH_SCOPE_VNODE' and 'KAUTH_SCOPE_FILEOP' operations.
>
>
>
> 'App.kext' handles KAUTH_VNODE_EXECUTE action for every process and sends
> it to userland (appd daemon) to decide whether to allow its launch or not
> (based on 'rules' added by user)
>
>
>
> 'App.kext' also handles
> KAUTH_FILEOP_CLOSE/KAUTH_FILEOP_EXCHANGE/KAUTH_FILEOP_RENAME actions.
>
>
>
> When 'xpcproxy' binary is executed/launched, 'App.kext' blocks it and sends
> its 'process information’ to it's userland counterpart 'appd'.
>
>
>
> As ‘Appd’ allows 'apple signed' binaries to launch (irrespective or rules
> added by user) we check whether the ‘binary’ is apple signed or not.
>
>
>
> We are using security framework provided by apple to check for ‘apple
> signing’ of binary. Following API doesn't return when we use it for
> 'xpcproxy' binary (xpcproxy process is still blocked by App.kext as it is
> waiting for 'appd daemon process for its response whether to block/allow
> it) and system goes unresponsive.
>
>
>
> SecStaticCodeCheckValidity(code, kSecCSDefaultFlags,
>
> appleAncorReq );
>
>
>
>
>
> *Step Followed for debugging Issue:*
>
>
>
> To debug the scenario, I tried remote debugging (using two machines) with
> both machines installed YOSEMITE (dev preview 5).
>
>
>
> Installed command line tools (released on 4th august) from apple developer
> account.
>
>
>
> Added nvram boot-args as following in target machine and rebooted it (Also
> added in host machine)
>
>
>
> boot-args="debug=0x146 kext-dev-mode=1 kdp_match_name=firewire fwkdp=0x8000"
>
>
>
> Both machines connected using 'firewire cable 800'. Host machine using
> 'Thunderbolt to firewire adapter' and target machine has a firewire port.
> In network preferences both machines shows firewire connected (with
> self-assigned IP’s).
>
>
>
> On the Host machine I ran 'fwkdp' then tried following steps.
>
>
>
> i) Downloaded latest kernel debug kit (released on 4th August for YOSEMITE)
>
> ii) cd /Volumes/KernelDebugKit
>
> iv) lldb /Volumes/KernelDebugKit/kernel
>
> v) (lldb) target create --arch x86_64 kernel // Tried With or without this
> command.
>
> vi) (lldb) platform select remote-macosx // Tried with or without this
> command
>
>
>
> On the target machine I forced a panic/sent NMI (non maskable interrupt).
>
>
>
> on Host machine I tried following commands to remotely connect to debug the
> target machine but it fails. I tried it before/after the target machine
> panic but it always fails.
>
>
>
> (lldb) kdp-remote localhost
>
> error: KDP_REATTACH failed
>
>
>
> I also tried IP of the target machine/1.2.3.4 etc. with different
> combinations but unable to connect to target machine.
>
>
>
> *Could Anyone help me in identifying the reason for code-sign API to hang
> for '/usr/libexec/xpcproxy' binary while 'xpcproxy' process is blocked.*
>
>
>
> *I would also like to know the steps to remotely debug the target machine
> kernel.*
>
>
>
> Host Machine info =>
>
> MAC OS X YOSEMITE (10.10 Dev Seed 5)
>
> MacBook Pro (Retina, 13-inch, Late 2013)
>
> Processor 2.4 GHz Intel Core i5
>
> Memory 8 GB 1600 MHz DDR3
>
> Graphics Intel Iris 1536 MB
>
>
>
> Target machine info => (panic machine)
>
> MAC OS X YOSEMITE (10.10 dev seed 5)
>
> MacBook Pro (13 inch, Mid 2009)
>
> Processor 2.26 GHz Intel Core 2 Duo
>
> Memory 8 GB 1067 MHz DDR3
>
> Graphics NVIDIA GeForce 9400M 256 MB
>
>
> Regards,
> Charu
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.apple.com/mailman/private/darwin-kernel/attachments/20140811/16e9e39d/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> Darwin-kernel mailing list
> email@hidden
> https://lists.apple.com/mailman/listinfo/darwin-kernel
>
> End of Darwin-kernel Digest, Vol 11, Issue 34
> *********************************************

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Follow-Ups:
- Re: remote kernel debugging
  - From: David Tay <email@hidden>
- Re: remote kernel debugging
  - From: Vadim Galitsyn <email@hidden>

References:
	>Re: remote kernel debugging (From: David Tay <email@hidden>)

Prev by Date: Re: remote kernel debugging
Next by Date: Re: remote kernel debugging
Previous by thread: Re: remote kernel debugging
Next by thread: Re: remote kernel debugging
Index(es):
- Date
- Thread