Re: The correct way to identify applications in a kext
Re: The correct way to identify applications in a kext
- Subject: Re: The correct way to identify applications in a kext
- From: "Quinn \"The Eskimo!\"" <email@hidden>
- Date: Thu, 12 May 2011 16:18:33 +0100
On 12 May 2011, at 14:22, Juuso Salonen wrote:
> This user-space-helper approach is something I feel queasy about,
> although it is probably caused by my lack of understanding. Simply
> put, isn't it way too slow?
Not particularly. As I mentioned in my email, you only do this once per process, on the assumption that a process's code signature won't change on the fly [1]. One round trip to user space the first time the process makes an outgoing connection is not going to impact performance meaningfully. The built-in firewall uses essentially the same technique, and we've not had a lot of complaints (about the performance, anyway ;-).
Oh, some extra points:
o Every time you write kernel code that depends on user space code, you have to be very careful about deadlocks.
o You can avoid a world of potential deadlocks by, as a matter of policy, /not/ checking the signature for any code running as root. This prevents you from deadlocking against critical system processes (the vnode pager, the DirectoryService daemon, and so on).
o One final consequence of this design is that you must decide on a reasonable default policy if the user space code has not checked in (that is, before the launchd daemon has run) or has failed or just does not reply to your requests in a timely fashion. What that default policy should be is up to you. Common approaches include a) unilaterally denying the request, b) unilaterally allowing the request, and c) kernel panicking (for those in high-security environments).
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] Which isn't a totally valid assumption, but it's valid enough for your purposes.
_______________________________________________
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