January 2006 - Darwin-kernel

Re: x86 mac firmware?
by Shawn Erickson 10 Jan '06

10 Jan '06

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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fHs//frMxyqgLk5cu3WzXk+KmSGp86uqYGUOeMSoXpKIL5EyuTMb42siM3dJK+CVePFoeUmOCCeMizmOlSOROH5iN1jLPBXONfRnpPUMMoqLycsdKcOIzfpYznS1J9x5dhNPAUZF2giH1S/SmnAhAmdQ1pSVK30bpAFls10d/YU= On 1/10/06, Andrew Gallatin <gallatin(a)cs.duke.edu> wrote: > > Months ago when the x86 mac announcement was made, the decision > on what to use as boot firmware seemed to be an open question. > Now that the machine is apparently released, what did it end up > being? Normal old x86 BIOS, EFI, OpenFirmware? Something else? Apple updated the docs today, they use EFI. <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary…> -Shawn _______________________________________________ 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

x86 mac firmware?
by Andrew Gallatin 10 Jan '06

10 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Months ago when the x86 mac announcement was made, the decision on what to use as boot firmware seemed to be an open question. Now that the machine is apparently released, what did it end up being? Normal old x86 BIOS, EFI, OpenFirmware? Something else? Thanks, 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

Re: mbuf_outbound_finalize() awkward on intel
by Josh Graessley 10 Jan '06

10 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 10, 2006, at 5:57 AM, Andrew Gallatin wrote: There were some fixes related to this that went in. It is possible this is fixed. You should file a bug either way to make sure that this is fixed. Ideally, everything in the packet that a kext sees will be in network byte order and every function in the KPI should take packets that contain data in network byte order. Anything else would be a huge mess. Hmm.. That's definately not the case for mbuf_outbound_finalize(). By the time a packet makes it through ip_output() to dlil_output), the stack has put the ip header into network byte order. However, in_delayed_cksum_offset(), which is what is ultimately called by mbuf_outbound_finalize(), expects the ip header in native byte order. Maybe something special happens for interface filters, but I'm munging this from a driver so I don't get the benefit of any magic which may be done for interface filters. In my opinion, it is more of a documentation bug for mbuf_outbound_finalize(). It should probably have a sentence which says "For PF_INET packets, the ip header's ip_len field must be in host byte order" -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 Josh Graessley writes: That is one possible solution. In my opinion, the bug is that the any part of a packet would be in host byte order when it's passed off to a filter. Whether you're implementing an IP filter or an interface filter, the packets should be in network byte order. mbuf_outbound_finalize should handle the packet as such. smime.p7s

1 0

Re: mbuf_outbound_finalize() awkward on intel
by Andrew Gallatin 10 Jan '06

10 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Josh Graessley writes: > > There were some fixes related to this that went in. It is possible > this is fixed. You should file a bug either way to make sure that > this is fixed. Ideally, everything in the packet that a kext sees > will be in network byte order and every function in the KPI should > take packets that contain data in network byte order. Anything else > would be a huge mess. Hmm.. That's definately not the case for mbuf_outbound_finalize(). By the time a packet makes it through ip_output() to dlil_output), the stack has put the ip header into network byte order. However, in_delayed_cksum_offset(), which is what is ultimately called by mbuf_outbound_finalize(), expects the ip header in native byte order. Maybe something special happens for interface filters, but I'm munging this from a driver so I don't get the benefit of any magic which may be done for interface filters. In my opinion, it is more of a documentation bug for mbuf_outbound_finalize(). It should probably have a sentence which says "For PF_INET packets, the ip header's ip_len field must be in host byte order" > Again please file a bug and test this on the latest release (I'm not > sure what's out right now). This was xnu-792.6.22 (8.3.0). 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

Re: mbuf_outbound_finalize() awkward on intel
by Josh Graessley 09 Jan '06

09 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -josh On Jan 9, 2006, at 2:23 PM, Andrew Gallatin wrote: I'm running 8.3.0 on x86 (plain Darwin, not an Intel Mac). I ported some driver code from ppc, and noticed that packets where I had called mbuf_outbound_finalize() resulted in kernel error messages: cksum: out of data This is because by the time a packet gets to a driver, the ip->ip_len ends up in network byte order. In order to use mbuf_outbound_finalize() on intel, I needed to byteswap ip->ip_len. Eg: ip = (struct ip *)((char *)mbuf_data(m_head) + ETHER_HDR_LEN); ip->ip_len = ntohs(ip->ip_len); mbuf_outbound_finalize(m_head, PF_INET, ETHER_HDR_LEN); ip->ip_len = htons(ip->ip_len); This is just a heads up for the next guy who runs into this.. _______________________________________________ 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 There were some fixes related to this that went in. It is possible this is fixed. You should file a bug either way to make sure that this is fixed. Ideally, everything in the packet that a kext sees will be in network byte order and every function in the KPI should take packets that contain data in network byte order. Anything else would be a huge mess. Again please file a bug and test this on the latest release (I'm not sure what's out right now). 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/jgraessley% 40apple.com This email sent to jgraessley(a)apple.com smime.p7s

1 0

mbuf_outbound_finalize() awkward on intel
by Andrew Gallatin 09 Jan '06

09 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I'm running 8.3.0 on x86 (plain Darwin, not an Intel Mac). I ported some driver code from ppc, and noticed that packets where I had called mbuf_outbound_finalize() resulted in kernel error messages: cksum: out of data This is because by the time a packet gets to a driver, the ip->ip_len ends up in network byte order. In order to use mbuf_outbound_finalize() on intel, I needed to byteswap ip->ip_len. Eg: ip = (struct ip *)((char *)mbuf_data(m_head) + ETHER_HDR_LEN); ip->ip_len = ntohs(ip->ip_len); mbuf_outbound_finalize(m_head, PF_INET, ETHER_HDR_LEN); ip->ip_len = htons(ip->ip_len); This is just a heads up for the next guy who runs into this.. 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

Re: tcplognke for 10.3 still available?
by Justin C. Walker 08 Jan '06

08 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 8, 2006, at 04:35 , Alexander Loddoch wrote: Hi List! I think the earlier version has been deprecated into oblivion :-} Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- "Weaseling out of things is what separates us from the animals. Well, except the weasel." - Homer J Simpson -------- _______________________________________________ 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.… Just a short question: Is the "old" version of the tcplog-sample code (i.e. for <=10.3) still available somewhere? This email sent to site_archiver(a)lists.apple.com

1 0

tcplognke for 10.3 still available?
by Alexander Loddoch 08 Jan '06

08 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi List! Thanks a lot! Alex -- Alexander Loddoch Institut f. Geophysik, Universitaet Muenster Corrensstr. 24 D-48149 Muenster, Germany Telefon: +49-251-83-33597 Fax: +49-251-83-36100 _______________________________________________ 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.… Just a short question: Is the "old" version of the tcplog-sample code (i.e. for <=10.3) still available somewhere? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel NKE projects user space daemon.
by Herb Petschauer 06 Jan '06

06 Jan '06

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:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E4Jy9vPqxyb7z5AQekTI74ag4b1LPu5FFuXx6NjaCNdY0H8qguRfg1vvUrYIbiyQJdRIcsgDcNdGnqBN/LJuXVnTVDbVExcu9Fg7KZzmpS0R+L26x12DfJJS/zXewsQnKGGfROvvFsb0m60mknye24QQzTMpVYgvDvTaxMBjrZ8= On 1/5/06, Terry Lambert <tlambert(a)apple.com> wrote: > On Jan 5, 2006, at 2:26 AM, Stephane Sudre wrote: > > On 04 Jan 2006, at 22:47, Terry Lambert wrote: > >> Using the output of the "ps" program is actually the recommended > >> method of getting information which is the least prone to breakage > >> in future versions of the OS going forward. For the most part, I > >> personally hate the KERN_* sysctl's - they are data interfaces, and > >> therefore subject to becoming potentially stale. > > > > I agree that the sysctl thing is a problem since for instance the ps > > code using sysctl from Panther is not working on Tiger. > > It's not a supported API, it is an SPI. Applications are not intended > to use it. System utilities are permitted to use it, so long as they > are revised in lockstep with the base OS. Applications - no matter > *who* writes them - are expected to talk to the system utilities, and > get the information in a nice, safe, abstract, and nominally future- > proof way, instead of going fishing. Any other use of it is "at your > own substantial risk of your software breaking, maybe as soon as the > next software update", and strongly discouraged. > > > >> If you use the output of "ps" with appropriate field selection > >> arguments to get only the data you want, then we can change things > >> out from under you, and your application will still work, since > >> "ps" is revised in lockstep with the kernel itself. > >> > >> As Mike also pointed out in another message, "ps" is OK for this > >> particular case, since the issue only comes up when specific > >> network traffic is being allowed/denied via a user interaction. > >> The "ps" program itself won't trigger this in the normal case, > >> since it's run from local disks, and has no network dependencies of > >> its own. > > > > Yet the problem with using ps is that you are relying on an external > > tool which may change in the future and to which you do not have > > access as changes are being made. Example: the ps source code for > > Tiger was not available until the release of Tiger. > > This is true; however, this complaint is almost completely mitigated > by the fact that there are international and defacto standards for the > "ps" program, and as long as neither of those standards change, you > can be pretty darn sure that standards conforming use of the program > will continue to work as expected. > > The reason we suggested that you use specific output formatting and > process-of-interest constraint options, rather than groveling through > the default unqualified and unconstrained output, was *specifically* > to insulate you from potential changes to those standards or the > tool's output outside the scope of control of standards, or any bug > fixes we might have to do. > > > > An extreme case could also be that the ps tool is not installed on > > the computer. > > Then having it available becomes a prerequisite for your software. > > This may be inconvenient, but it's less inconvenient than, say, > needing to install your application as SUID root, like "ps" itself, or > your SUID application crashing or being used as a gateway to > compromise system integrity, or dozens of other worse things than > having "ps" available to people who already have shell access to the > machine. > > > > Anyway, the main problem IMHO is that OS X/Darwin is lacking either > > a true and trustful API to get this information or a proc folder > > (even though I think I saw such a folder in one case (maybe it was > > on OS X Server)). > > Welcome to the world of systems tools. > > There really isn't any UNIX or UNIX-like system in existence that > doesn't have some form of data interface that requires changes to > system utilities, or user applications that think (or act like) they > are system utilities. This includes things like the ill-designed > "procfs" on many systems. And if an administrator takes away "ps", > they will surely take away "/proc", so that people can't write or > download their own copy of "ps" to override the administrators > decision, unless "/proc" is also disabled - at which point you are in > the same boat. > > The bottom line is that, if you insist on using data interfaces - even > supported ones, which these are not - instead of using procedural > interfaces to talk to programs that use data interfaces, to insulate > yourself from any unforeseen OS changes... well, you are probably > going to eventually be unhappy when your application suddenly stops > working. > > > > >>> This can be done from a bootstrap session. You just have to launch > >>> a helper tool for the UI. > >>> > >>> If the UI does not need to be really complex, you can also use a > >>> CFUserNotification dialog. > >> > >> We discourage this - "...can't be done *legitimately*..." [emphasis > >> mine] - because you never know that what happens to work right now > >> will continue to work the same way in some far off future. There's > >> a big difference between "can be done this way" and "should be done > >> this way". > > > > I'm not sure to see where the illegitimate part lies in the > > CFUserNotification API or launching a helper tool. Can you shed some > > light on this? > > Using it or launching a helper tool that uses it from the bootstrap > session is unsupported. If you think about it, it should be obvious > to you why this is the case. > > -- Terry > _______________________________________________ Delurk: see my current favourite tech note, aka "argh, where were you a few years ago but we figured it out", <http://developer.apple.com/technotes/tn2005/tn2083.html> -H. Lurk: _______________________________________________ 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: Kernel NKE projects user space daemon.
by Terry Lambert 06 Jan '06

06 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Then having it available becomes a prerequisite for your software. Welcome to the world of systems tools. -- Terry _______________________________________________ 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 Jan 5, 2006, at 2:26 AM, Stephane Sudre wrote: On 04 Jan 2006, at 22:47, Terry Lambert wrote: Using the output of the "ps" program is actually the recommended method of getting information which is the least prone to breakage in future versions of the OS going forward. For the most part, I personally hate the KERN_* sysctl's - they are data interfaces, and therefore subject to becoming potentially stale. I agree that the sysctl thing is a problem since for instance the ps code using sysctl from Panther is not working on Tiger. It's not a supported API, it is an SPI. Applications are not intended to use it. System utilities are permitted to use it, so long as they are revised in lockstep with the base OS. Applications - no matter *who* writes them - are expected to talk to the system utilities, and get the information in a nice, safe, abstract, and nominally future- proof way, instead of going fishing. Any other use of it is "at your own substantial risk of your software breaking, maybe as soon as the next software update", and strongly discouraged. If you use the output of "ps" with appropriate field selection arguments to get only the data you want, then we can change things out from under you, and your application will still work, since "ps" is revised in lockstep with the kernel itself. As Mike also pointed out in another message, "ps" is OK for this particular case, since the issue only comes up when specific network traffic is being allowed/denied via a user interaction. The "ps" program itself won't trigger this in the normal case, since it's run from local disks, and has no network dependencies of its own. Yet the problem with using ps is that you are relying on an external tool which may change in the future and to which you do not have access as changes are being made. Example: the ps source code for Tiger was not available until the release of Tiger. This is true; however, this complaint is almost completely mitigated by the fact that there are international and defacto standards for the "ps" program, and as long as neither of those standards change, you can be pretty darn sure that standards conforming use of the program will continue to work as expected. The reason we suggested that you use specific output formatting and process-of-interest constraint options, rather than groveling through the default unqualified and unconstrained output, was *specifically* to insulate you from potential changes to those standards or the tool's output outside the scope of control of standards, or any bug fixes we might have to do. An extreme case could also be that the ps tool is not installed on the computer. This may be inconvenient, but it's less inconvenient than, say, needing to install your application as SUID root, like "ps" itself, or your SUID application crashing or being used as a gateway to compromise system integrity, or dozens of other worse things than having "ps" available to people who already have shell access to the machine. Anyway, the main problem IMHO is that OS X/Darwin is lacking either a true and trustful API to get this information or a proc folder (even though I think I saw such a folder in one case (maybe it was on OS X Server)). There really isn't any UNIX or UNIX-like system in existence that doesn't have some form of data interface that requires changes to system utilities, or user applications that think (or act like) they are system utilities. This includes things like the ill-designed "procfs" on many systems. And if an administrator takes away "ps", they will surely take away "/proc", so that people can't write or download their own copy of "ps" to override the administrators decision, unless "/proc" is also disabled - at which point you are in the same boat. The bottom line is that, if you insist on using data interfaces - even supported ones, which these are not - instead of using procedural interfaces to talk to programs that use data interfaces, to insulate yourself from any unforeseen OS changes... well, you are probably going to eventually be unhappy when your application suddenly stops working. This can be done from a bootstrap session. You just have to launch a helper tool for the UI. If the UI does not need to be really complex, you can also use a CFUserNotification dialog. We discourage this - "...can't be done *legitimately*..." [emphasis mine] - because you never know that what happens to work right now will continue to work the same way in some far off future. There's a big difference between "can be done this way" and "should be done this way". I'm not sure to see where the illegitimate part lies in the CFUserNotification API or launching a helper tool. Can you shed some light on this? Using it or launching a helper tool that uses it from the bootstrap session is unsupported. If you think about it, it should be obvious to you why this is the case. This email sent to site_archiver(a)lists.apple.com

1 0