November 2003 - Darwin-kernel

Shielding cpu / G5
by Nicolas Castagné 28 Nov '03

28 Nov '03

Hi all, We are currently benching the bi-proc G5 for hard real-time applications. Do you know some kind of 'hard real time G5/Mac OS X community' on the net ? Is there any native feature on Panther allowing to shield a cpu : isolate the cpu from interrupts / prevent it from standard process execution ? Is there a native command allowing to run a process on a specific CPU ? Is there a command such as the quite-common UNIX mlockall() ? If not, is there any available "real-time" patch validated by Apple on Panther, which would present these features ? Or any patch used by any of you ? We did not find entries to these qsts on the archives... So thx for answer ! Nicolas CASTAGNE ------------------------------------------------------------------------ -------------------------- Dr Nicolas CASTAGNE Researcher, IR de l'ACROE / ICA, Association pour la Criation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Criation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

OpenSource for diskutil command or any information related to RAID on MAC Os X
by Johnsy George 28 Nov '03

28 Nov '03

Hi, Here's a list of questions from my side: 1) Is there an opensource available for the diskutil command? 2) Is there any sample code related to RAID operations in MAC OS X? 3) Please let me know if the XRAID has any API calls whcich could be used by an application running on MAC OS X to configure it. Thanks in advance. johnsy george _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

porting next-gen firewalls: When to build in-kernel vs. KEXT?
by OpenMacNews 27 Nov '03

27 Nov '03

hi all, 1st, a caveat ... i'm new to the kernel. that said, after reading up on some of the firewall ports (e.g. pf, ipfw2) in the *BSDs, i'm wondering about the choice of building/porting "pf" to Darwin as in-kernel code, requiring of course, a kernel recompile, vs. as a KEXT. from what i've read at <http://www.opensource.apple.com/projects/documentation/howto/html/kext_tuto…>, KEXTs, as i understand them to be (?) the Darwin analogues of "dynamically loadable kernel modules" for other *NIXs, seem like a logical route for a fw implementation .... QUESTION: if, e.g., porting the *BSD pf firewall is the goal, what are the pro/con arguments for in-kernel vs/ KEXT? AND, should this issue be more appropriately discussed in "darwin-kernel" or "darwin-development"? looking forward to hearing your thoughts ... richard _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

THREAD MOVED Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin
by OpenMacNews 26 Nov '03

26 Nov '03

Aaron, btw, after having had it suggested to move this thread to darwin-development, i did so last eve .... i won't presume to re-post your reply there, please do so if *you* like ... I've run across a small comparison between ipfilter+ipnat and ipfw+natd in the introduction section of this page: http://neon1.net/misc/firewall.html It seems a bit dated since it says pf doesn't have traffic shaping (altq support in pf (along with a slew of othe rneat features) has since been added). I haven't found anything comparing pf and ipfw2. actually a nice overview, hadn't found this one yet myself ... I'd like to see pf support myself, I use OpenBSD on a couple gateways and the ruleset syntax is very natural. Both altq and nat are integrated well into the ruleset. I have some kernel programming experience, though probably not the level of expertise for a project like this. Regards, Aaron PS- One of those neat little features of pf is the passive OS fingerprinting: block in on $ext_if proto tcp from any os {"Windows 95", "Windows 98"} \ to any port smtp that would be a nice addition to the available Darwin toolkit! thanks, richard On Mon, 24 Nov 2003, OpenMacNews wrote: ok, having done some reading re: pf/ipf, i've got to say that -- altho still a bit foreign -- it definitely seems to be well-featured, and as ipfw2, would be a not insignificant improvement over Darwin's current ipfw. as you, i have to compare ipfw2 & pf in greater depth to 'choose' between the two ... ANYONE OUT THERE HAVE ANY URLs FOR A GOOD/THOROUGH COMPARISONS OF IPFW/IPFW2/PF/IPF? either way, i agree that ipfw is getting 'long in the tooth' ... and would add my voice to suggesting that a discussion here be opened/started here on the matter. it seems to be the right forum ... i'll be happy to contribute what i can as a user, but as a kernel-developer, i'm in over my head :-S cheers, richard _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
by Aaron Linville 26 Nov '03

26 Nov '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've run across a small comparison between ipfilter+ipnat and ipfw+natd in the introduction section of this page: http://neon1.net/misc/firewall.html It seems a bit dated since it says pf doesn't have traffic shaping (altq support in pf (along with a slew of othe rneat features) has since been added). I haven't found anything comparing pf and ipfw2. I'd like to see pf support myself, I use OpenBSD on a couple gateways and the ruleset syntax is very natural. Both altq and nat are integrated well into the ruleset. I have some kernel programming experience, though probably not the level of expertise for a project like this. Regards, Aaron PS- One of those neat little features of pf is the passive OS fingerprinting: block in on $ext_if proto tcp from any os {"Windows 95", "Windows 98"} \ to any port smtp :-) On Mon, 24 Nov 2003, OpenMacNews wrote: > ok, > > having done some reading re: pf/ipf, i've got to say that -- altho still a bit foreign -- it definitely seems to be > well-featured, and as ipfw2, would be a not insignificant improvement over Darwin's current ipfw. as you, i have to > compare ipfw2 & pf in greater depth to 'choose' between the two ... > > ANYONE OUT THERE HAVE ANY URLs FOR A GOOD/THOROUGH COMPARISONS > OF IPFW/IPFW2/PF/IPF? > > either way, i agree that ipfw is getting 'long in the tooth' ... and would add my voice to suggesting that a discussion > here be opened/started here on the matter. it seems to be the right forum ... > > i'll be happy to contribute what i can as a user, but as a kernel-developer, i'm in over my head :-S > > > cheers, > > richard -----BEGIN PGP SIGNATURE----- iD8DBQE/xQMf+W1NLgrTPToRAld5AKCbM9lN02Tf2WPDSylaHSVvHHpL3wCePCVi JrGCs4I1GZpGHrFPPiKNq8A= =1hrW -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
by OpenMacNews 24 Nov '03

24 Nov '03

ok, having done some reading re: pf/ipf, i've got to say that -- altho still a bit foreign -- it definitely seems to be well-featured, and as ipfw2, would be a not insignificant improvement over Darwin's current ipfw. as you, i have to compare ipfw2 & pf in greater depth to 'choose' between the two ... ANYONE OUT THERE HAVE ANY URLs FOR A GOOD/THOROUGH COMPARISONS OF IPFW/IPFW2/PF/IPF? either way, i agree that ipfw is getting 'long in the tooth' ... and would add my voice to suggesting that a discussion here be opened/started here on the matter. it seems to be the right forum ... i'll be happy to contribute what i can as a user, but as a kernel-developer, i'm in over my head :-S cheers, richard -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenBSD's (Danielt Hartmeier's) pf is really quite neat. Loadable kernel modules aside (yeah yeah, I know the old argument that securelevel is a one-way spinlock, and we've seen the exploits that disprove that), it's well-implemented piece of software. Some of the finer points that really make it nice are the scrubbing features (dealing with duplicate IP fragments with overlapping data), the ability to compensate for weak TCP ISNs when acting as a NATting system, queueing, anchor points for externally generated rules, useful counters.... Rather than go on with glittering generalities, I think I'd like to familiarize myself better with ipfw2 (I haven't looked at it at all, to be honest). Hartmeier's pf has some support for sharing nat and filter states among systems (though I'm not sure how advanced this is at the moment. I think it uses a pseudo device). It can operate in a routing fashion or in a bridging fashion too which is quite handy. Just like Darren Reid's ipf, Hartmeier's pf uses a configuration file (using a yacc parser), as opposed to the ipfw/iptables/ipchains method of using the binary for all configuration -- yes, I've seen the iptables restore format and it's a lot closer to making it maintainable. - -Jeff On Nov 22, 2003, at 9:06 PM, OpenMacNews wrote: then again, its seems that i spoke (somewhat) too soon ... looks like OpenBSD's "pf" has been ported to FreeBSD 5.x (<http://pf4freebsd.love2party.net/>) as a lodable kernel module. what implications that has for Darwin, i honestly don't know ... comments/thoughts anyone? richard On a related note, is there any interest in exploring the potential benefits of Daniel Hartmeier's pf or Darren Reid's ipf? - -Jeff On Nov 22, 2003, at 5:53 PM, OpenMacNews wrote: hi all, what plans/progress exist for updating Darwin's "ipfw" to "ipfw2"? having moved from a FreeBSD box to a Mac, there are several features missing from ipfw that i'm having to work around ... in particular, the assignment/use of rule sets and the ability to assign boolean concatenations of IP ranges to a variable, then use the variable in a rule. or, there's always the possibility that i'm missing an already existing feature set in current Darwin .... if it exists, a friendly pointer to it would be much appreciated! thanks, richard _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Sockets in the Kernel
by Matt Jaffa 24 Nov '03

24 Nov '03

Hi, I am asking this again to see if someone will help me further. I have patched the sendto system call in the system call table. Now when my function is called it is passed the socket identifier. since it is an int I have no clue what to do with it. Within the Kernel you are not allowed to call any socket functions. so is there a way to get all the information of what process/Apllication, protocol, port it is trying to access. Any help would be appreciated. I have looked at the sys_socket.h and socket.h file but still don't know what to do. Thanks Also if there is a way to call a outside program from with in the Kernel, that would be great too. I want the outside program to be run in the background and no windows, or even the terminal to pop open. Please let me know if you know anything. Thanks again, Matt _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

fsck vs. Journaled HFS+
by James Bucanek 23 Nov '03

23 Nov '03

Greetings, First, apologies if this is the wrong forum. Please direct me to the right place if it's not. I'm trying to find some definitive word about using fsck on a Journaled HFS+ file system. I'm technical editor for a book on OS X and I'd like to get to the bottom of this. I've heard that you should never run 'fsck -fy' on a Journaled file system. I've heard that you should always run 'fsck -fy'. I've heard that Journaling is implemented in the file system, so if you boot up in single user mode and run 'fsck -fy' that the journaling system will later "undo" any fixes. I've heard that in single user mode that the journaling system has already done any required repair before you get to the single user prompt. In other words, I'm confused. What I'm trying to find out is: When do journaling fixes get applied. What exactly does 'fsck -f' do? Under what circumstances can the two conflict? And what's the generally accepted practice for maintaining volume integrity when using Journaled HFS+? Yea, I know, it's a lot of questions. But any insight or advice would be greatly appreciated. Cheers, James ______________________________________________________ James Bucanek <mailto:privatereply@gloaming.com> _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
by Jeff Nathan 23 Nov '03

23 Nov '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm going to have to really take a look at it to give it a fair treatment. I'm guessing the authors are just being humble. Still, that snippet makes ipfw2 sound rather antiquated in comparison to pf. Thanks for the link, by the way. :) Oh, and just as I asked about the kernel patch, I received the message that it had been received. So... nevermind. Take care, - -Jeff On Nov 22, 2003, at 9:31 PM, OpenMacNews wrote: Although there, of course, many resources, here's a quick <snip> from the FreeBSD man page (obviously NOT the Darwin man pg ...) summarizing the ipfw --> ipfw2 diffs ... <http://www.kerneled.com/doc/man/freebsd/man8/ipfw.html> IPFW2 ENHANCEMENTS This Section lists the features that have been introduced in ipfw2 which were not present in ipfw1. We list them in order of the potential impact that they can have in writing your rulesets. You might want to consider using these features in order to write your rulesets in a more efficient way. Handling of non-IPv4 packets ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter all packets (including non-IPv4 ones) according to the ruleset. To achieve the same behaviour as ipfw1 you can use the following as the very first rule in your ruleset: ipfw add 1 allow layer2 not mac-type ip The layer2 option might seem redundant, but it is necessary -- packets passed to the firewall from layer3 will not have a MAC header, so the mac-type ip pattern will always fail on them, and the not operator will make this rule into a pass-all. Address sets ipfw1 does not supports address sets (those in the form addr/masklen{num,num,...} ). Port specifications ipfw1 only allows one port range when specifying TCP and UDP ports, and is limited to 10 entries instead of the 15 allowed by ipfw2. Also, in ipfw1 you can only specify ports when the rule is requesting tcp or udp packets. With ipfw2 you can put port specifications in rules matching all packets, and the match will be attempted only on those packets carrying protocols which include port identifiers. Finally, ipfw1 allowed the first port entry to be specified as port:mask where mask can be an arbitrary 16-bit mask. This syn- tax is of questionable usefulness and it is not supported anymore in ipfw2. Or-blocks ipfw1 does not support Or-blocks. keepalives ipfw1 does not generate keepalives for stateful sessions. As a consequence, it might cause idle sessions to drop because the lifetime of the dynamic rules expires. Sets of rules ipfw1 does not implement sets of rules. MAC header filtering and Layer-2 firewalling. ipfw1 does not implement filtering on MAC header fields, nor is it invoked on packets from ether_demux() and ether_output_frame(). The sysctl variable net.link.ether.ipfw has no effect there. Options The following options are not supported in ipfw1 dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port. Additionally, the following options are not supported in ipfw1 (RELENG_4) rules: ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack, tcpseq, tcpwin. Dummynet options The following option for dummynet pipes/queues is not supported: noerror. - -- http://cerberus.sourcefire.com/~jeff (gpg/pgp key id 6923D3FD) "I want to know God's thoughts... the rest are details." - Albert Einstein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/wCArEqr8+Gkj0/0RAm/9AJ9nC7HnOKGJM8IxaFh33kRqVd+zygCfWPgq gG6A3uagrkxB51excWKj0NI= =99+M -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: status (plans?) of latest *BDS's ipfw2 for OSX/Darwin kernel?
by OpenMacNews 23 Nov '03

23 Nov '03

Although there, of course, many resources, here's a quick <snip> from the FreeBSD man page (obviously NOT the Darwin man pg ...) summarizing the ipfw --> ipfw2 diffs ... <http://www.kerneled.com/doc/man/freebsd/man8/ipfw.html> IPFW2 ENHANCEMENTS This Section lists the features that have been introduced in ipfw2 which were not present in ipfw1. We list them in order of the potential impact that they can have in writing your rulesets. You might want to consider using these features in order to write your rulesets in a more efficient way. Handling of non-IPv4 packets ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter all packets (including non-IPv4 ones) according to the ruleset. To achieve the same behaviour as ipfw1 you can use the following as the very first rule in your ruleset: ipfw add 1 allow layer2 not mac-type ip The layer2 option might seem redundant, but it is necessary -- packets passed to the firewall from layer3 will not have a MAC header, so the mac-type ip pattern will always fail on them, and the not operator will make this rule into a pass-all. Address sets ipfw1 does not supports address sets (those in the form addr/masklen{num,num,...} ). Port specifications ipfw1 only allows one port range when specifying TCP and UDP ports, and is limited to 10 entries instead of the 15 allowed by ipfw2. Also, in ipfw1 you can only specify ports when the rule is requesting tcp or udp packets. With ipfw2 you can put port specifications in rules matching all packets, and the match will be attempted only on those packets carrying protocols which include port identifiers. Finally, ipfw1 allowed the first port entry to be specified as port:mask where mask can be an arbitrary 16-bit mask. This syn- tax is of questionable usefulness and it is not supported anymore in ipfw2. Or-blocks ipfw1 does not support Or-blocks. keepalives ipfw1 does not generate keepalives for stateful sessions. As a consequence, it might cause idle sessions to drop because the lifetime of the dynamic rules expires. Sets of rules ipfw1 does not implement sets of rules. MAC header filtering and Layer-2 firewalling. ipfw1 does not implement filtering on MAC header fields, nor is it invoked on packets from ether_demux() and ether_output_frame(). The sysctl variable net.link.ether.ipfw has no effect there. Options The following options are not supported in ipfw1 dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port. Additionally, the following options are not supported in ipfw1 (RELENG_4) rules: ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack, tcpseq, tcpwin. Dummynet options The following option for dummynet pipes/queues is not supported: noerror. OpenBSD's (Danielt Hartmeier's) pf is really quite neat. Loadable kernel modules aside (yeah yeah, I know the old argument that securelevel is a one-way spinlock, and we've seen the exploits that disprove that), it's well-implemented piece of software. Some of the finer points that really make it nice are the scrubbing features (dealing with duplicate IP fragments with overlapping data), the ability to compensate for weak TCP ISNs when acting as a NATting system, queueing, anchor points for externally generated rules, useful counters.... Rather than go on with glittering generalities, I think I'd like to familiarize myself better with ipfw2 (I haven't looked at it at all, to be honest). Hartmeier's pf has some support for sharing nat and filter states among systems (though I'm not sure how advanced this is at the moment. I think it uses a pseudo device). It can operate in a routing fashion or in a bridging fashion too which is quite handy. Just like Darren Reid's ipf, Hartmeier's pf uses a configuration file (using a yacc parser), as opposed to the ipfw/iptables/ipchains method of using the binary for all configuration -- yes, I've seen the iptables restore format and it's a lot closer to making it maintainable. - -Jeff P.S. I sent in a kernel patch to this list a few days ago and never saw it make the list, is anyone else having problems sending messages to the list? i could've sworn it "ate" one reply that i have yet to see ... P.P.S. I submitted the same patch to Apple's patch form and actually received a bounce! (The submission page is a web form). _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0