June 2005 - Darwin-kernel - lists.apple.com

disk filter driver
by santosh katvate 22 Jun '05

22 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qEDtkO830QG7lBY/0/7tPRKwD/IlDbIoH0WEouDHuoapK7LkGHFSseQ6SgY1n449WGwOTB2gJ6dWhRSC4pwtqWsxQglSP5maXsh9Xx/qlmlPc3/HcsYDkEV0Z2pJSyRw1H/wDVfXDKvJ3FiBzoh6Mu5v9qysecT5N62eclkbYbY= hello everybody i want to develop disk filter driver to trap all the disk read/ write request. I would like to know that from where i should start. if i subclass my driver class from ioblockstoragedriver and try to replace that then will i be able to accomplish my goal. OR Is their any other way to do this. thanks in advance santosh k _______________________________________________ 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: KEXT IP Filter sample code?
by Josh Graessley 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -josh On Jun 21, 2005, at 4:20 PM, Allan Hoeltje wrote: Specifically, I need a kernel extension to monitor SIP and encrypt RTP packets. Which KEXT is best suited for this, Interface or IP filter? -Allan "Quinn" <eskimo1(a)apple.com> wrote on 6/16/05 2:20 AM: At 18:39 -0700 15/6/05, Allan Hoeltje wrote: You should check out the enetlognke. <http://developer.apple.com/samplecode/enetlognke/enetlognke.html> This new, Tiger-based sample is not directly relevant (it intercepts at the Ethernet layer rather than the IP layer), but it does show general NKE concepts, including packaging, memory allocation, locking, and so on. It's also much easier to understand than the tcplognke (-: ps One of the reasons that the tcplognke isn't published yet is because socket-level filters are tricky to get exactly right. The packet oriented filters (IP and Ethernet) are much easier. S+E This email sent to jgraessley(a)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 I would recommend an IP filter. You can also modify packets in the IP filter. The IP filter will give you IP traffic from all interfaces, so you don't have to worry about installing an interface filter on every interface. The IP filter will also pass you fully assembled IP packets. You don't have to deal with IP fragmentation, interface specific frame headers, or ARP packets. The enetlognke example is very helpful as an Interface filter but I am still puzzled by a couple things. The NKE documentation states that an Interface filter can observe as well as modify network traffic. Can an IP filter also be used to modify packets? If so, would the techniques shown in enetlognke (the code wrapped in "#if SWALLOW_PACKETS") also apply to an IP filter? Thanks for the quick reply. I know that tcplognke is a socket filter and even though I need an IP filter it would still be helpful to see some kind of sample code, Tiger or pre-Tiger, that uses KEXT. _______________________________________________ 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 smime.p7s

1 0

Re: KEXT IP Filter sample code?
by Allan Hoeltje 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.4.030702.0 The enetlognke example is very helpful as an Interface filter but I am still puzzled by a couple things. The NKE documentation states that an Interface filter can observe as well as modify network traffic. Can an IP filter also be used to modify packets? If so, would the techniques shown in enetlognke (the code wrapped in "#if SWALLOW_PACKETS") also apply to an IP filter? Specifically, I need a kernel extension to monitor SIP and encrypt RTP packets. Which KEXT is best suited for this, Interface or IP filter? -Allan "Quinn" <eskimo1(a)apple.com> wrote on 6/16/05 2:20 AM: > At 18:39 -0700 15/6/05, Allan Hoeltje wrote: >> Thanks for the quick reply. I know that tcplognke is a socket filter and >> even though I need an IP filter it would still be helpful to see some kind >> of sample code, Tiger or pre-Tiger, that uses KEXT. > > You should check out the enetlognke. > > <http://developer.apple.com/samplecode/enetlognke/enetlognke.html> > > This new, Tiger-based sample is not directly relevant (it intercepts > at the Ethernet layer rather than the IP layer), but it does show > general NKE concepts, including packaging, memory allocation, > locking, and so on. It's also much easier to understand than the > tcplognke (-: > > ps One of the reasons that the tcplognke isn't published yet is > because socket-level filters are tricky to get exactly right. The > packet oriented filters (IP and Ethernet) are much easier. > > S+E _______________________________________________ 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: an issue with KPI implementation
by Terry Lambert 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- Terry Prerequisites ============= 1. Mac OS 10.4.1 2. test_nke NKE (see the attach) test_nke outputs this number to the system log (sock_count). All these steps are repeated several times for the port_number_1 = port_number_1 + 1 with the interval of 3 seconds. How to reproduce ================ 1. Login with administrative account. 3. Load the test_nke NKE (sudo kextload test_nke.kext). 4. Start the insockcnt utility (sudo ./insockcnt). 5. Wait about 30 seconds. 6. Stop the insockcnt utility by pressing 'Control+C'. 7. The number of sockets the test_nke is attached is dumped to the system log. This number may be considerably more than 0, but it should be equal to 0, because all the sockets the NKE had been attached to were closed. If the dumped socket_count is not equal 0, then the subsequent kextunload may result in a system crash. Thanks, alexklg _______________________________________________ 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.… On Jun 7, 2005, at 1:27 AM, alexklg wrote: We developed a small NKE and a sequence of steps that may make this NKE to crash even under Tiger 10.4.1 (it crashes in more stable manner under 10.4). However, even if this NKE doesn't crash (doesn't cause the system to panic), the number of the sockets it is attached to grows uncontrollably and this seems to be a Darwin issue. Do you reference count entry and exit, and use a mutex to protect the entry and exit counts, so that any in-progress operations can drain out before you actually permit the unload to complete? If not, that would most likely explain the gcrashing. The problem of sockets concerns with the uncontrollable grow of the number os sockets that were created in response to incoming connections but that were not accept'ed. For this, you will have to wait for the 2 MSL timer to expire on connections being shut down. If these are straight TCP/IP connections, be aware that if the client connection is not shutdown properly (e.g. because you are using a "WebAvalance" or similar test box that establishes connections through SYN-flooding) then the sockets created can persist for a very long time in FIN-WAIT-2 state, at least until the "backup" timeout that most OS vendors (like us) add to the TCP stack to avoid it taking forever. Basically, you should set a flag to deny additional entries once you start the unload process, and wait for everything in progress to drain out before closing, or you will end up with "orphaned stacks" trying to return through code that's no longer in the kernel address space after they eventually wakeup and try to return through your NKE. Maybe one of the networking guys can point you to example code that does the necessary counting and locking. Problem description =================== The very basic socket-filter NKE crashes on unload (kextunload). If it doesn't crash, the number of sockets the socket-filter is attached to grows uncontrollably. test_nke is a basic socket-filter global NKE that simply counts the number of sockets it is attached to. 3. isockcnt utility. The utility does the following - creates a listening TCP socket (server-side) in a separate process, The second argument of listen() is some large number (256). The listened port is some arbitrary port_number_1 - from a separate process (client-side) connects to the listening socket 100 times, - at the server side accepts the first connection from the client side and then does sleep(2), but the server-side process is killed in one second by alarm. - closes the connection from the client-side (exit(0)). This results in a large number of sockets that the test_nke is attached to but is not detached from during reasonable amount of time (about 2 minutes). Remark. From our point of view, the sockets that the filter is not detached from are the sockets from the accept queue. These sockets are created in response to incoming connections. Apparently, for them the kernel structures are allocated but these sockets are not initialized completely. We believe that this happens because accept() was not called for these sockets and meanwhile the client closed the connection (e.g. was terminated) for some reason. Remark. Even if the insockcnt utility is started without sudo (becoming super-user), and is terminated in about 2-3 minutes (instead of 30 seconds), the kernel starts lacking the resources and goes into panic. <testnke-20050606-03.tgz> _______________________________________________ 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/tlambert% 40apple.com This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using ipf_inject_input with Local Packets
by Raj Doshi 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, Thanks, Raj Doshi On Jun 20, 2005, at 11:39 AM, Josh Graessley wrote: Or it could be something else completely. -josh On Jun 19, 2005, at 11:16 PM, Raj Doshi wrote: Hello, This email sent to jgraessley(a)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.… I just wanted to follow up on this problem to indicate that Josh was correct and the checksum and the checksum flags were not getting copied over to the new mbuf. I added the following line of code for packets on the loopback interface to fix this: mbuf_set_csum_performed(my_new_mbuf, MBUF_CSUM_DID_IP | MBUF_CSUM_IP_GOOD | MBUF_CSUM_DID_DATA | MBUF_CSUM_PSEUDO_HDR, 65535); It seems that in addition to the four flags, the checksum value "65535" is necessary for the packet not to be dropped. It may be possible that you aren't setting the rcvif correctly in the mbuf pkthdr. There is a check that the loopback packets are received on the loopback interface. Another possibility is that the checksum related flags are not being carried over. These flags indicate what checksums were performed in hardware. The loopback uses a trick where it never calculates the checksums on transmit. When the packet is looped back, the loopback interface sets the flags indicating that the checksums were calculated in hardware on the card and the checksums are correct. If you strip the flags indicating the checksum was correct according to hardware, the checksums will be performed in software. Since they were never calculated on the outbound path, the checksums will be wrong and the packet will be dropped. Look for bad checksums using netstat -s. I would first like to thank Vincent Lubet for his help with my previous question on this list. Now, I have another question: I'm intercepting incoming packets in my kext with KPI IP filters (Mac OS X 10.4.1), sending them to a user-space process, getting them back (possibly modified) from the user-space process, and re- injecting them with ipf_inject_input. I've got this working fine in most cases, like when accessing remote web sites. However, http connections to 127.0.0.1:80 fail and result in messages like "NetInfo connection failed for server 127.0.0.1/local" in console.log. To attempt to isolate the problem, I've tried the following: 1. Immediately re-injecting the mbuf that I receive from the filter. In this case, the local connection works. 2. Immediately re-injecting a copy (using mbuf_dup) of the mbuf that I receive from the filter. In this case, the local connection fails. I am wondering what I can do so that these local connections will still work when I inject a copy of the original mbuf. If there is no good solution to this, then I am wondering exactly for which packets I need to avoid making copies of the mbuf. Thanks, Raj Doshi_______________________________________________ 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 This email sent to site_archiver(a)lists.apple.com

1 0

Re: auditing in Darwin?
by Quinn 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com AFAIK the user space auditing components are in projects "bsm" and "Libc". S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ 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.… At 10:43 -0700 21/6/05, Todd Heberlein wrote: Is this auditing available in Darwin? Yes. The kernel's auditing support is built in. So, when you get the kernel source (project "xnu"), you get the auditing support as well. Is this the best community for discussing internal issues of the auditing system? Well, that depends on whether these issues are related to the kernel, or the interface between the kernel and user space auditing components. If so, yes, this is the right place. OTOH, if you're just interested in the user space aspects of auditing, darwin-kernel is probably not the place you want to be. This email sent to site_archiver(a)lists.apple.com

1 0

auditing in Darwin?
by Todd Heberlein 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Is this auditing available in Darwin? Thanks, Todd _______________________________________________ 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.… Later versions of Panther (10.3.6 and above) and Tiger support BSM audit trails (you need to install the Common Criteria package first). Is this the best community for discussing internal issues of the auditing system? This email sent to site_archiver(a)lists.apple.com

1 0

Re: an issue with KPI implementation
by Quinn 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com <http://developer.apple.com/bugreporter/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ 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.… At 9:29 +0200 21/6/05, Stephane Sudre wrote: Did you file a bug report? Stephane raises a good point. This list is not the place to send official feedback to Apple about problems you're having with the system [1]. Rather, you should file a bug report using the URL below. [1] The Apple folks who help out on the list are mostly doing it in their free time. This email sent to site_archiver(a)lists.apple.com

1 0

Re: an issue with KPI implementation
by Stephane Sudre 21 Jun '05

21 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Le 7 juin 05, à 10:27, alexklg a écrit : Did you file a bug report? I think I will file a bug report. _______________________________________________ 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.… We developed a small NKE and a sequence of steps that may make this NKE to crash even under Tiger 10.4.1 (it crashes in more stable manner under 10.4). However, even if this NKE doesn't crash (doesn't cause the system to panic), the number of the sockets it is attached to grows uncontrollably and this seems to be a Darwin issue. The problem of sockets concerns with the uncontrollable grow of the number os sockets that were created in response to incoming connections but that were not accept'ed. Problem description =================== The very basic socket-filter NKE crashes on unload (kextunload). If it doesn't crash, the number of sockets the socket-filter is attached to grows uncontrollably. I'm currently investigating a similar issue where the listen queue is not cleared. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Processes running path
by Andrew Gallatin 20 Jun '05

20 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Mike Smith writes: > > On Jun 20, 2005, at 6:39 AM, Andrew Gallatin wrote: > > > Mike Smith writes: > >> > >> I'm a little puzzled by this. The kernel makes it easy to run > >> processes, > > > > As far as I can tell, it is far from easy to start run a process from > > inside the kernel. > > I didn't say that it did. Starting a process from inside the kernel > is a bad idea; > much of our runtime depends on context that is only available from a > session, > and sessions are only associated with other processes. > > The kernel makes it easy to run processes by providing handy hooks known > as system calls, which are called from userspace to start new processes. ;) Whoops. I was reading between the lines, and assuming the original poster's objection to a helper was that it was difficult for his kext to restart it if it disappeared. Maybe that's not his problem. Reading it again, I see that he never said why he didn't want all those processes running. Drew _______________________________________________ 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