April 2003 - Darwin-kernel - lists.apple.com

Re: Mach Scheduler
by Justin Walker 01 Apr '03

01 Apr '03

You and Gautame Godse should compare notes. Look for the thread "kernel multi-tasking algorithm" in the archives for this list. There's not much that is *Right Up To Date*, other than the code (which you are welcome to peruse <http://developer.apple.com/darwin>). There are also copious reports from CMU on Mach scheduling which, while not directly applicable, will shed light. Regards, Justin On Tuesday, Apr 1, 2003, at 10:03 US/Pacific, Steven Clark wrote: Hello. I am a student and I am doing a report on Darwin's CPU Scheduler. I am unable to find any information that explains exactly how it works. The closest information I can find is from the kernel programming prospective at http://developer.apple.com/techpubs/macosx/Darwin/General/ KernelProgramming/ About/index.html If anyone knows where I can find more specific information please email me at vencub(a)core.com Thank you for your help. Steven _______________________________________________ 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. -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* _______________________________________________ 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: Which header file(s) define 'ether_header' and 'ether_header_t'
by Justin Walker 01 Apr '03

01 Apr '03

Hi, Michael, On Tuesday, Apr 1, 2003, at 10:23 US/Pacific, Michael Birdsong wrote: I have run into an issue in building an NKE after a few months of NOT compiling this particular project. In the latest version of Mac OS X (after 10.1.5) it seems the definitions for the structures: "ether_header" and "ether_header_t" have been moved from their old header file locations, I'm throwing compile errors. On my system (10.2.4) the structure is defined in <net/ethernet.h>. There is also a different definition in the kernel tree (xnu/bsd/netinet/ip_compat.h). I'd use the former. FWIW, it does not seem to have moved. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* _______________________________________________ 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: Which header file(s) define 'ether_header' and 'ether_header_t'
by Joshua Graessley 01 Apr '03

01 Apr '03

The definitions should be in /usr/include/net/ethernet.h -josh On Tuesday, Apr 1, 2003, at 10:23 US/Pacific, Michael Birdsong wrote: I have run into an issue in building an NKE after a few months of NOT compiling this particular project. In the latest version of Mac OS X (after 10.1.5) it seems the definitions for the structures: "ether_header" and "ether_header_t" have been moved from their old header file locations, I'm throwing compile errors. Are there replacements for these structures, or have they just move to a header file which I am not (yet) including? Thank you all in advance for your time and effort on my behalf. michael --- birdsong(a)cisco.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. _______________________________________________ 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

Which header file(s) define 'ether_header' and 'ether_header_t'
by Michael Birdsong 01 Apr '03

01 Apr '03

I have run into an issue in building an NKE after a few months of NOT compiling this particular project. In the latest version of Mac OS X (after 10.1.5) it seems the definitions for the structures: "ether_header" and "ether_header_t" have been moved from their old header file locations, I'm throwing compile errors. Are there replacements for these structures, or have they just move to a header file which I am not (yet) including? Thank you all in advance for your time and effort on my behalf. michael --- birdsong(a)cisco.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

Mach Scheduler
by Steven Clark 01 Apr '03

01 Apr '03

Hello. I am a student and I am doing a report on Darwin's CPU Scheduler. I am unable to find any information that explains exactly how it works. The closest information I can find is from the kernel programming prospective at http://developer.apple.com/techpubs/macosx/Darwin/General/KernelProgramming/ About/index.html If anyone knows where I can find more specific information please email me at vencub(a)core.com Thank you for your help. Steven _______________________________________________ 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: mprotect with PROT_NONE throws SIGBUS, not SIGSEGV
by Steven Bytnar 01 Apr '03

01 Apr '03

On Tue, Apr 01, 2003 at 11:05:19PM +1000, Andre Pang wrote: > I have feeling that the following diff to xnu-10 is a start to solving > the problem, and may even be sufficient: > > --- ./bsd/uxkern/ux_exception.c.old Tue Apr 1 22:52:52 2003 > +++ ./bsd/uxkern/ux_exception.c Tue Apr 1 22:53:39 2003 > @@ -277,7 +277,8 @@ > switch(exception) { > > case EXC_BAD_ACCESS: > - if (code == KERN_INVALID_ADDRESS) > + if (code == KERN_INVALID_ADDRESS || > + code == KERN_PROTECTION_FAILURE) > *ux_signal = SIGSEGV; > else > *ux_signal = SIGBUS; > > However, I can't actually test this because I'm running Mac OS X > 10.2.4, and the 10.2.4 kernel (xnu-344.26) isn't up on the Apple CVS > servers yet :(. You could always do a binary patch to your kernel! B) Let's convert some constants to their values: ./osfmk/mach/kern_return.h:#define KERN_INVALID_ADDRESS 1 ./osfmk/mach/kern_return.h:#define KERN_PROTECTION_FAILURE 2 ./osfmk/mach/exception_types.h:#define EXC_BAD_ACCESS 1 ./bsd/sys/signal.h:#define SIGSEGV 11 /* segmentation violation */ ./bsd/sys/signal.h:#define SIGBUS 10 /* bus error */ otool -vVt /mach_kernel | less # search for "ux_exception" You'll find this code segment in the MacOS X 10.2.4 /mach_kernel. _ux_exception: 0020ca0c mfspr r0,lr 0020ca10 stmw r29,0xfff4(r1) 0020ca14 stw r0,0x8(r1) 0020ca18 or r30,r4,r4 0020ca1c stwu r1,0xffb0(r1) 0020ca20 or r31,r3,r3 0020ca24 or r29,r6,r6 0020ca28 bl _machine_exception 0020ca2c cmpwi r3,__framesize 0020ca30 bne 0x20cb10 0020ca34 cmplwi r31,0x6 0020ca38 bgt 0x20cb10 0020ca3c lis r9,0x21 // get offset in jump table. 0020ca40 rlwinm r11,r31,2,0,29 0020ca44 addi r9,r9,0xca58 0020ca48 lwzx r0,r11,r9 0020ca4c add r0,r0,r9 0020ca50 mtspr ctr,r0 0020ca54 bctr // jump table 0020ca58 .long 0x000000b8 //28CA58+B8=28CB10 (case EXC_BAD_ACCESS) 0020ca5c .long 0x0000001c //28CA58+1C=28CB74 (case EXC_BAD_INST...) 0020ca60 .long 0x00000030 0020ca64 .long 0x00000038 0020ca68 .long 0x00000040 0020ca6c .long 0x00000048 0020ca70 .long 0x000000b0 // compare r30 to KERN_INVALID_ADDRESS 0020ca74 cmpwi r30,0x1 // if (r30 == KERN_INVALID_ADDRESS) return SIGBUS 0020ca78 li r0,0xb 0020ca7c beq 0x20cb0c // if (r30 != KERN_INVALID_ADDRESS) return SIGSEGV 0020ca80 li r0,0xa 0020ca84 b 0x20cb0c 0020ca88 li r0,0x4 0020ca8c b 0x20cb0c 0020ca90 li r0,0x8 0020ca94 b 0x20cb0c 0020ca98 li r0,0x7 0020ca9c b 0x20cb0c 0020caa0 lis r0,0x1 0020caa4 ori r0,r0,0x1 0020caa8 cmpw r30,r0 0020caac beq 0x20caf0 0020cab0 bgt 0x20cac4 0020cab4 lis r0,0x1 0020cab8 cmpw r30,r0 0020cabc beq 0x20cae8 0020cac0 b 0x20cb10 0020cac4 lis r0,0x1 0020cac8 ori r0,r0,0x2 0020cacc cmpw r30,r0 0020cad0 beq 0x20caf8 0020cad4 lis r0,0x1 0020cad8 ori r0,r0,0x3 0020cadc cmpw r30,r0 0020cae0 beq 0x20cb00 0020cae4 b 0x20cb10 0020cae8 li r0,0xc 0020caec b 0x20cb0c 0020caf0 li r0,0xd 0020caf4 b 0x20cb0c 0020caf8 li r0,0x6 0020cafc b 0x20cb0c 0020cb00 li r0,0x9 0020cb04 b 0x20cb0c 0020cb08 li r0,kLog2CacheLineSize 0020cb0c stw r0,__framesize(r29) 0020cb10 lwz r0,0x58(r1) 0020cb14 addi r1,r1,0x50 0020cb18 lmw r29,0xfff4(r1) 0020cb1c mtspr lr,r0 0020cb20 blr We could make this patch: echo << EOF > x.s ; replacement for code starting at 0020ca74 cmpwi r30,0x2 ; if <= 2 li r0,0xb ; SIGSEGV (if <= 2) ble 0x1b0c li r0,0xa ; SIGBUS (if > 2) b 0x1b0c EOF [jsg3-10:~] sbytnar% cc -c -o x.o x.s [jsg3-10:~] sbytnar% otool -vVt x.o x.o: (__TEXT,__text) section 00000000 cmpwi r30,0x2 00000004 li r0,0xb 00000008 ble 0x1b0c 0000000c li r0,0xa 00000010 b 0x1b0c [jsg3-10:~] sbytnar% hexdump x.o 0000000 feed face 0000 0012 0000 0000 0000 0001 0000010 0000 0001 0000 007c 0000 0000 0000 0001 0000020 0000 007c 0000 0000 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0014 0000 0098 0000040 0000 0014 0000 0007 0000 0007 0000 0001 0000050 0000 0000 5f5f 7465 7874 0000 0000 0000 0000060 0000 0000 5f5f 5445 5854 0000 0000 0000 0000070 0000 0000 0000 0000 0000 0014 0000 0098 0000080 0000 0000 0000 00ac 0000 0002 8000 0400 0000090 0000 0000 0000 0000 2c1e 0002 3800 000b 00000a0 4081 1b04 3800 000a 4800 1afc 0000 0010 00000b0 0000 00c3 0000 0008 0000 00c2 00000bc That looks like PowerPC code starting at offset 0x98. It looks like our constants are visible in the opcodes. Interestingly enough, offset 0x3C points to this, so it must be it. 2c1e0002 // cmpwi 3800000b // li... 4081xxxx // insert appropriate offset from original 3800000a // li... 4800xxxx // insert appropriate offset from original This binary patch assumes that it's ok to return SIGSEGV for code == KERN_SUCCESS, when before, it would return SIGBUS. I'll leave it as an excercise for the reader to find the actual offset in the /mach_kernel binary and to do the hex editing. :) I'm not sure if there are any checksums or date-checking by the kernel loader/linker, so binary patching may or maynot work. Does anyone recall offhand if Mach-O/BootX has either of those features? Enjoy, --Steve _______________________________________________ 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

mprotect with PROT_NONE throws SIGBUS, not SIGSEGV
by Andre Pang 01 Apr '03

01 Apr '03

Hi, The following code: 1 char *mm_mem; 2 mm_mem = mmap (0, pagesize, PROT_NONE, MAP_PRIVATE | MAP_ANON, -1, 0); 3 mm_mem[0] = 'a'; 4 mprotect (mm_mem, pagesize, PROT_NONE) != 0 5 mm_mem[0] = 'b'; shows two bugs on Mac OS X 10.2.4 (xnu-344.26): 1. mmap (line 2) seems to ignore the protection flags given to it; it always assumes (at least) PROT_READ|PROT_WRITE even though I've explicitly specified PROT_NONE. Line 3 executes without an error, even though it should return a SIGSEGV. Which leads me to the more serious bug #2 ... 2. When line 5 is executed, the kernel should raise a SIGSEGV. Instead, a SIGBUS is raised. This is important because various libraries will install a SIGSEGV signal handler to intercept the segmentation fault, and won't be expecting a SIGBUS. I have feeling that the following diff to xnu-10 is a start to solving the problem, and may even be sufficient: --- ./bsd/uxkern/ux_exception.c.old Tue Apr 1 22:52:52 2003 +++ ./bsd/uxkern/ux_exception.c Tue Apr 1 22:53:39 2003 @@ -277,7 +277,8 @@ switch(exception) { case EXC_BAD_ACCESS: - if (code == KERN_INVALID_ADDRESS) + if (code == KERN_INVALID_ADDRESS || + code == KERN_PROTECTION_FAILURE) *ux_signal = SIGSEGV; else *ux_signal = SIGBUS; However, I can't actually test this because I'm running Mac OS X 10.2.4, and the 10.2.4 kernel (xnu-344.26) isn't up on the Apple CVS servers yet :(. Is there a temporary workaround for this bug? I need to install a SIGSEGV signal handler for the mmap'ed region so that I can flip the protection bits, enable PROT_READ for the faulting address and then restart execution of the program. This works fine on Linux and seems to be POSIX behaviour; I can provide code examples if needed. Thanks, -- % Andre Pang : just.your.average.bounty.hunter _______________________________________________ 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: panic in m_copym() from udp_output()..
by Quinn 01 Apr '03

01 Apr '03

At 20:41 -0500 31/3/03, Andrew Gallatin wrote: When exercising the built-in "UniNEnet" gigE interface on a powerbook, I noticed that OS-X 10.2.4 falls over rather quicky under load. Please file a bug. <http://developer.apple.com/bugreporter/> While the Apple folks on this are interested in the abstract sense, the person responsible for this driver isn't on the list. If you file a bug it will get to that person. TIA -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ 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: Non-executable stack
by Jim Magee 31 Mar '03

31 Mar '03

On Monday, March 31, 2003, at 8:11 PM, Ragnar Sundblad wrote: On den 31 mars 2003 19:52 -0500 Jim Magee <jmagee(a)apple.com> wrote: Do you want us to change the PowerPC architecture? Yes, wherever it has shortcomings, I would like you to! :-) Except that we don't control it. It's part of the documented architecture for 32-bit processors. It is not an implementation feature of aspecific processor in the family. It's kind of like you asking Intel to change the P5 MMU (in a way that means old OSes aren't going to run on it). They won't do it. We can make suggestions for the next architecture. But we'll never have any luck changing the one that's sitting on your desk. Or do you think it is worth taking 256MB of virtual address space from each task and making it no-execute, and then forcing all stacks to be in there (requiring many/most programs to be re-built to adapt to it)? What is the limit today, 2.5G or something? How many apps fits well in 2.5G but absolutely not in 2.25G? Sure, more space to apps is good, but if you are that close you will probably have to take other measures to handle it anyway. It's the contiguous and aligned nature of the requirement that is the problem. In essence, given all the legacy reserved memory ranges, we would likely have to put this at 0x70000000 and you would be limited to 2GB contiguous space in an application (plus there are some available ranges up above there as well, just not a big contiguous blob). Besides, all this is on the assumption that you have to execute code on the stack. More common (from a PowerPC hack perspective) is to just change link register values saved on the stack to trick the program into running code that already exists (the blr instruction is used to both call and return from a function). The only stuff that has to be on the stack is the argument data and the stomped address. Jumping to the well-known address for the system() library routine should do nicely. ;-) In fact, arranging to execute code just written on the stack is fairly tricky on the PowerPC. You have to manually synchronize the icache to the dcache. Finding code to do that in an existing application (since you can't reliably execute even it from the stack until you run it) and then getting a branch back to your code is much less likely to be successful. I can only imagine that was one of the thoughts behind the processors lack of granular no-execute permissions. Most data pages "behave" that way often enough (because of the cache issues) to sway hackers into other means (like the one I described above which would not be helped by no-execute permissions on any data). --Jim _______________________________________________ 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

panic in m_copym() from udp_output()..
by Andrew Gallatin 31 Mar '03

31 Mar '03

When exercising the built-in "UniNEnet" gigE interface on a powerbook, I noticed that OS-X 10.2.4 falls over rather quicky under load. Trying 'netperf -tUDP_STREAM -Hsome-fast-host -- -m 1472', I saw: panic(cpu 0): 0x300 - Data access Latest stack backtrace for cpu 0: Backtrace: 0x00084FAC 0x000853DC 0x00027FA8 0x0008EE68 0x00091F78 Proceeding back via exception chain: Exception state (sv=0x19269000) PC=0x001F82EC; MSR=0x00009030; DAR=0x00000008; DSISR=0x40000000; LR=0x001007D8; R1=0x11DF3B70; XCP=0x0000000C (0x300 - Data access) Backtrace: 0x00000000 0x001007D8 0x0010B9CC 0x001FB4DC 0x001FF788 0x001FF8C0 0x0020E59C 0x00092110 0x00430053 Exception state (sv=0x1969F280) PC=0x9001352C; MSR=0x0000D030; DAR=0x17170000; DSISR=0x42000000; LR=0x0000856C; R1=0xBFFFF600; XCP=0x00 000030 (0xC00 - System call) This looks like: 001f8258 A _m_copym 000ff964 A _ip_output 0010b810 a _udp_output 001fae04 A _sosend 001ff544 a _sendit 001ff864 A _sendto 0020e34c A _unix_syscall Interestingly, I can get this to happen on an 867MHz powerbook, but not on a dual 800MHz G4. Just thought y'all might be interested. Cheers, Drew _______________________________________________ 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