February 2006 - Darwin-kernel

Re: Kern ext. message "An item in the Startup Items folder...Fix"
by Cliff Russell 06 Feb '06

06 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: Kern ext. message "An item in the Startup Items folder...Fix"
by Stephane Sudre 06 Feb '06

06 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 4 févr. 06, at 17:47, Peter Lovell wrote: On Feb 4, 2006, at 8:00 AM, Alain Birtz wrote: An item in the Startup Items folder ("/Library/StartupItems/myKern") does not have the proper security settings." Options are to "Disable" or "Fix" (or "Decide Later" to change nothing). Hi Alain, I had thought, actually, that "Fix" was no longer an option. _______________________________________________ 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.… After the restart Mac OS X send this message dot thef the kernel extention myKern The permission, owner and group of the kernel extention files seem exactly the same after and before the "Fix". Do I miss something ? The general rules for kexts are that all items be owned by root:wheel (uid:gid is 0:0) and that nothing be writable except by root. That usually translates to mode 755 for directories and 644 for files. Starting with 10.4, I think every file/folder within the StartupItems folder need to be owned by root:wheel, not just the kext. Someone probably realized the main security flaw was not with kexts but with startup scripts... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Darwin-kernel Digest, Vol 3, Issue 28
by Alain Birtz 05 Feb '06

05 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 4-Feb-06, at 3:02 PM, darwin-kernel-request(a)lists.apple.com wrote: ---------------------------------------------------------------------- Message: 1 Date: Sat, 04 Feb 2006 08:00:56 -0500 From: Alain Birtz <abz(a)videotron.ca> Subject: Kern ext. message "An item in the Startup Items folder...Fix" To: darwin-kernel(a)lists.apple.com Message-ID: <6A321677-D56B-4F88-9890-30975B462460(a)videotron.ca> Content-Type: text/plain; charset="us-ascii" After the restart Mac OS X send this message dot thef the kernel extention myKern An item in the Startup Items folder ("/Library/StartupItems/myKern") does not have the proper security settings." Options are to "Disable" or "Fix" (or "Decide Later" to change nothing). The permission, owner and group of the kernel extention files seem exactly the same after and before the "Fix". Do I miss something ? What cant I do to install the kernel extention correctly ? ------------------------------ Message: 2 Date: Sat, 4 Feb 2006 11:47:23 -0500 From: Peter Lovell <vpndev(a)mac.com> Subject: Re: Kern ext. message "An item in the Startup Items folder...Fix" To: Alain Birtz <abz(a)videotron.ca> Cc: Darwin Kernel List <darwin-kernel(a)lists.apple.com> Message-ID: <C39333AF-EABF-4EE0-BD6D-BB7516F76F26(a)mac.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 4, 2006, at 8:00 AM, Alain Birtz wrote: After the restart Mac OS X send this message dot thef the kernel extention myKern The permission, owner and group of the kernel extention files seem exactly the same after and before the "Fix". Do I miss something ? Hi Alain, I had thought, actually, that "Fix" was no longer an option. The general rules for kexts are that all items be owned by root:wheel (uid:gid is 0:0) and that nothing be writable except by root. That usually translates to mode 755 for directories and 644 for files. If you specify "fix" and restart, do you get the same message again, i.e. did "fix" cure the problem? Yes. when MyKern script is installed with group/owner: wheel/root the kernel extention not longer load !!! #!/bin/sh /sbin/kextload /Library/StartupItems/MyKern/MyKern.kext .... Regards.....Peter ------------------------------ _______________________________________________ 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.…

1 0

Re: Kern ext. message "An item in the Startup Items folder...Fix"
by Peter Lovell 04 Feb '06

04 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Feb 4, 2006, at 8:00 AM, Alain Birtz wrote: An item in the Startup Items folder ("/Library/StartupItems/myKern") does not have the proper security settings." Options are to "Disable" or "Fix" (or "Decide Later" to change nothing). Hi Alain, I had thought, actually, that "Fix" was no longer an option. Regards.....Peter _______________________________________________ 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.… After the restart Mac OS X send this message dot thef the kernel extention myKern The permission, owner and group of the kernel extention files seem exactly the same after and before the "Fix". Do I miss something ? The general rules for kexts are that all items be owned by root:wheel (uid:gid is 0:0) and that nothing be writable except by root. That usually translates to mode 755 for directories and 644 for files. If you specify "fix" and restart, do you get the same message again, i.e. did "fix" cure the problem? This email sent to site_archiver(a)lists.apple.com

1 0

Kern ext. message "An item in the Startup Items folder...Fix"
by Alain Birtz 04 Feb '06

04 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: KPI Interface filter and filter detachment
by Josh Graessley 03 Feb '06

03 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Feb 3, 2006, at 10:15 AM, Stephane Sudre wrote: On 3 févr. 06, at 18:10, Josh Graessley wrote: That's what I'm doing, with a fine granularity if possible. -josh _______________________________________________ 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 As currently implemented, the iff_input callback is most likely to occur on the dlil input thread. Your callback for handling data sent on a kernel control socket will occur on the thread that calls send/sendmsg/sendto. These are two different threads. I was thinking that maybe a detach event could be sent via kernel Event then a userland process would catch it and send a kern control message to the kernel while it was in an iff_input callback, then this could explain a recursive lock attempt. But from what you are saying, this does not look possible (and if it was, I would not have understood how things could be running ok). That would never be a problem. The kernel never calls out in to a user process. In the case of a kernel event socket, the kernel event is queued in the kernel event socket's receive buffer. If the process has a thread waiting on that data, the thread is kicked so it can read the data (or if the socket is being waited on in select or a kqueue). That thread would then perform the read and call the kernel control socket's send. The implementation may change in the future. You need to be very careful. One day there may be multiple input threads. R/W locks look to be the solution for this case. Be very careful with R/W locks. They can cover up some problems that you see immediately with a mutex. For example, the recursive lock problem you may be seeing could be covered up if you only take the lock for reading both times. This will likely fail in the rare case that between taking the read the first time and the second time, another thread attempts to take the lock for writing. The second read will probably wait until the write has had a chance to take the lock. The write won't succeed until all of the readers are done, including the first read which will never complete because the thread is stuck waiting to get the second read on the same lock. Other changes are possible too. Too avoid headaches, you need to be very careful with your locking. Lock only while manipulating shared data structures. Never hold a lock while calling back in to the stack, you never know when the stack might turn around and call your kext. Are the re-injection KPIs concerned? Absolutely. In fact, you'll probably get away with most mbuf manipulation routines and a lot of other stuff. The place you'll really get bit is holding the lock while injecting a packet in or out. You never know what other kexts are going to do, or the stack for that matter. Don't make assumptions. Unless you know for certain exactly what will happen when you call a function with your lock held, move the calling of that function out of the segment where you're holding a lock. smime.p7s

1 0

Re: KPI Interface filter and filter detachment
by Stephane Sudre 03 Feb '06

03 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 3 févr. 06, at 18:10, Josh Graessley wrote: R/W locks look to be the solution for this case. That's what I'm doing, with a fine granularity if possible. Are the re-injection KPIs concerned? _______________________________________________ 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.… As currently implemented, the iff_input callback is most likely to occur on the dlil input thread. Your callback for handling data sent on a kernel control socket will occur on the thread that calls send/sendmsg/sendto. These are two different threads. I was thinking that maybe a detach event could be sent via kernel Event then a userland process would catch it and send a kern control message to the kernel while it was in an iff_input callback, then this could explain a recursive lock attempt. But from what you are saying, this does not look possible (and if it was, I would not have understood how things could be running ok). The implementation may change in the future. You need to be very careful. One day there may be multiple input threads. Other changes are possible too. Too avoid headaches, you need to be very careful with your locking. Lock only while manipulating shared data structures. Never hold a lock while calling back in to the stack, you never know when the stack might turn around and call your kext. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOSyncer
by Garth Cummings 03 Feb '06

03 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: IOSyncer
by Garth Cummings 03 Feb '06

03 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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: KPI Interface filter and filter detachment
by Josh Graessley 03 Feb '06

03 Feb '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -josh On Feb 3, 2006, at 7:15 AM, Stephane Sudre wrote: OK, so this would not explain a recursive lock attempt. On 2 févr. 06, at 20:29, Josh Graessley wrote: -josh On Feb 2, 2006, at 9:36 AM, Stephane Sudre wrote: Maybe someone can shed some light on this. the callback can be sum-up to: myCallBack { mutex lock do something but never return anything mutex unlock return a value } Question: _______________________________________________ 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/jgraessley%40apple.com _______________________________________________ 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/jgraessley%40apple.com _______________________________________________ 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 As currently implemented, the iff_input callback is most likely to occur on the dlil input thread. Your callback for handling data sent on a kernel control socket will occur on the thread that calls send/ sendmsg/sendto. These are two different threads. The implementation may change in the future. You need to be very careful. One day there may be multiple input threads. Other changes are possible too. Too avoid headaches, you need to be very careful with your locking. Lock only while manipulating shared data structures. Never hold a lock while calling back in to the stack, you never know when the stack might turn around and call your kext. While using sockets inside of the kernel, never close the socket while another thread may be performing an operation on that socket (send/ recv/sockopt). Also, be very conscious of the performance impact of your kext. netperf is a decent tool for testing throughput. As you develop your kext, try running netperf with and without your kext to see what impact you're having. Gigabit is pretty dang fast, and 10 gigabit is just ridiculously fast. It doesn't take much to hose your throughput on networks running at those speeds. Mmm, is it possible for a kernel control message to be received when you are within a iff_input callback? I would say yes. But would it be considered the same "thread" or not? I believe the detach is a special case. The detach is there to notify you that your filter has been detached. In this case, that is the last call you will receive and it should only happen when we are not calling any other entry points in your filter for that interface. Let's say a KPI Interface filter is attached to every available interfaces. Let's say this KPI Interface filter is implementing a iff_input callback. now at one point an interface is going away => a detach filter is called. can the detach filter (iflt_detach) be called while we are in myCallBack? This email sent to jgraessley(a)apple.com This email sent to jgraessley(a)apple.com smime.p7s

1 0