December 2013 - Darwin-kernel

Re: Kernel bug in handling signals (bug 15615281)
by Eric Grant 21 Dec '13

21 Dec '13

Ben, I agree that your user-space code should not be able to crash the kernel. In that regard, it appears that you've identified a bug. That said, you *are* misusing the syscall. If you look at the source for sigaction in Libc on 10.9.0, <http://www.opensource.apple.com/source/Libc/Libc-997.1.1/sys/sigaction.c>, you will see that sigaction substitutes "our signal trampoline" for your signal handler before calling through to __sigaction. That routine is a stub found (in 10.7.5 at least) in /usr/lib/system/libsystem_kernel.dylib. It looks like this (again, in 10.7.5): ___sigaction: 00018dd8 movl $0xc002e, %eax // 46, but with bits 18-19 set as well 00018ddd calll __sysenter_trap 00018de2 jae 0x18df2 00018de4 calll 0x18de9 00018de9 popl %edx 00018dea movl 25139(%edx), %edx 00018df0 jmpl *%edx 00018df2 ret __sysenter_trap: 0001a49a popl %edx 0001a49b movl %esp, %ecx 0001a49d sysenter For what it's worth, you can also look at the kernel's handler for sigaction, <http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/kern/kern_sig.c>. That might give you a clue as to why the panic depends on the 64-bitness of the forking shell. Why not use just use Libc? You don't have to call it from C code, so there's no reason you can't call it from your Virgil (pseudo-)assembly. Just to add one more thing to the mix. You might want to check out "Mach exception handlers." See, e.g., <https://www.mikeash.com/pyblog/friday-qa-2013-01-11-mach-exception-handlers…>. Good luck, Eric On Dec 19, 2013, at 19:27:31 +0100, "Ben L. Titzer" <ben.titzer(a)gmail.com> wrote: Well I supposed you passed the of first test of trust :) Although you might not like the source code--none of it is written in C :) Checkout the repository here: https://code.google.com/p/virgil/ The binary in question is generated by my compiler from the test program in test/execute/rtex_divzero06.v3 % bin/v3c -target=x86-darwin-test -output=/tmp/ test/execute/rtex_divzero06.v3 There is some assembly language linkage that is generated by the compiler itself that sets up the default signal handlers. That assembly is generated in https://code.google.com/p/virgil/source/browse/aeneas/src/x86/X86Darwin.v3 in genSignalHandlerInstall() That code is basically: // generate code that installs a signal handler def genSigHandlerInstall(asm: X86Assembler, signo: int, handler: Addr) { asm.push_i(0); // sa_flags asm.push_i(0); // sa_mask asm.push_i(X86Addrs.ABS_CONST); // sa_handler: handler address recordPatch(asm, handler); asm.push_i(2); // TODO: why a nonzero value here? asm.movd_rm_r(X86Regs.EBX, X86Regs.ESP); asm.push_i(0); // sigaction *oact asm.push(X86Regs.EBX); // sigaction *act asm.push_i(signo); // signal number asm.push_i(0); // "dummy" value asm.movd_rm_i(X86Regs.EAX, 46); // sigaction asm.intK(0x80); asm.add.rm_i(X86Regs.ESP, 32); // pop params off stack } As you can see there is some hackery going on there. I wasn't exactly sure what I should be passing to the kernel, since it has been a pain to trace through exactly how all the structs are encoded. This all works fine on 10.6. I use the signal handlers to catch access violations (e.g. a null pointer deref by the program generates a SIGSEGV, by design of my address layout), and then generate a stacktrace. Perhaps I am misusing the syscall. But still, I should *not* be able to crash the kernel, and the behavior certainly shouldn't depend on the 64-bitness of the forking shell (!). As noted above, when forked from a 32-bit shell, then it all works as expected. _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rewriting Mach in AppleScript?!
by Michael Miller 20 Dec '13

20 Dec '13

_______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rewriting Mach in AppleScript?!
by me 20 Dec '13

20 Dec '13

_______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Rewriting Mach in AppleScript?!
by Eric Boyer 20 Dec '13

20 Dec '13

Wondering about this blog post from 2002, in which the author claims to have rewritten the Mach kernel in AppleScript and even booted it: > My first tries at getting a running my Mach kernel failed miserably but I > learned quickly from my mistakes. The running cuts were abysmally slow, > worse even than OS X itself, and I almost gave up the project then. But > after compiling my code, things picked up ten-fold. With the speed problem > hurdled, I set about tweaking my AppleScript code for talking to the > hardware. This is where knowing how to use Apple's Vector Engine libs and > Motorola's AltiVec calls came in handy, and before I knew it I had > something that ran considerable faster than the native kernel it was being > developed on! The rest is at http://www.trollaxor.com/2002/06/applescript-experience.html. I’ve never heard of being able to write a kernel in AppleScript, let alone optimizing it for special instructions/registers. AppleScript is totally abstracted from hardware, right? What the fuck? Eric _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel bug in handling signals (bug 15615281)
by Ben L. Titzer 19 Dec '13

19 Dec '13

https://code.google.com/p/virgil/ The binary in question is generated by my compiler from the test program in test/execute/rtex_divzero06.v3 % bin/v3c -target=x86-darwin-test -output=/tmp/ test/execute/rtex_divzero06.v3 There is some assembly language linkage that is generated by the compiler itself that sets up the default signal handlers. That assembly is generated in https://code.google.com/p/virgil/source/browse/aeneas/src/x86/X86Darwin.v3 in genSignalHandlerInstall() That code is basically: // generate code that installs a signal handler def genSigHandlerInstall(asm: X86Assembler, signo: int, handler: Addr) { asm.push_i(0); // sa_flags asm.push_i(0); // sa_mask asm.push_i(X86Addrs.ABS_CONST); // sa_handler: handler address recordPatch(asm, handler); asm.push_i(2); // TODO: why a nonzero value here? asm.movd_rm_r(X86Regs.EBX, X86Regs.ESP); asm.push_i(0); // sigaction *oact asm.push(X86Regs.EBX); // sigaction *act asm.push_i(signo); // signal number asm.push_i(0); // "dummy" value asm.movd_rm_i(X86Regs.EAX, 46); // sigaction asm.intK(0x80); asm.add.rm_i(X86Regs.ESP, 32); // pop params off stack } As you can see there is some hackery going on there. I wasn't exactly sure what I should be passing to the kernel, since it has been a pain to trace through exactly how all the structs are encoded. This all works fine on 10.6. I use the signal handlers to catch access violations (e.g. a null pointer deref by the program generates a SIGSEGV, by design of my address layout), and then generate a stacktrace. Perhaps I am misusing the syscall. But still, I should *not* be able to crash the kernel, and the behavior certainly shouldn't depend on the 64-bitness of the forking shell (!). As noted above, when forked from a 32-bit shell, then it all works as expected. Summary: My compiler generates programs that handle signals directly from the kernel without going through any of libc. Thus these programs use the kernel system calls to set up signal handlers. There appears to be a bug on 10.8 and later (64 bit kernels), where such programs hang when trying to handle any signals. This only appears to be the case when the program handling the signal is 32bit and is forked from a 64bit shell. See steps below for test case reproduction. Steps to Reproduce: 1. Download the attached executable. 2. Run the executable from a 32-bit shell: % arch -arch i386 sh -c './rtex_divzero06 1' This should produce the expected output: !DivideByZeroException 3. Run the executable from a 64-bit shell: % arch -arch x86_64 sh -c './rtex_divzero06 1' This unfortunately hangs on 10.8 and 10.9. Worse, on 10.9, it causes a kernel panic when trying to kill the program when it is launched directly from the shell: % ./rtex_divzero06 1 <hangs> <CTRL+C> causes a kernel panic Expected Results: See above. Program should print !DivideByZeroException. Actual Results: Program hangs on 10.8 and 10.9. When CTRL+C'ing the program, causes a kernel panic on 10.9. Version: 10.8 10.9 %uname -a Darwin <machine> 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 Notes: The program is a compiled test case from the Virgil programming language: https://code.google.com/p/virgil/ Configuration: This always occurs on 10.8 and 10.9. It never occurs on 10.6. Have not tested on 10.7. _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel bug in handling signals (bug 15615281)
by sk 19 Dec '13

19 Dec '13

Summary: My compiler generates programs that handle signals directly from the kernel without going through any of libc. Thus these programs use the kernel system calls to set up signal handlers. There appears to be a bug on 10.8 and later (64 bit kernels), where such programs hang when trying to handle any signals. This only appears to be the case when the program handling the signal is 32bit and is forked from a 64bit shell. See steps below for test case reproduction. Steps to Reproduce: 1. Download the attached executable. 2. Run the executable from a 32-bit shell: % arch -arch i386 sh -c './rtex_divzero06 1' This should produce the expected output: !DivideByZeroException 3. Run the executable from a 64-bit shell: % arch -arch x86_64 sh -c './rtex_divzero06 1' This unfortunately hangs on 10.8 and 10.9. Worse, on 10.9, it causes a kernel panic when trying to kill the program when it is launched directly from the shell: % ./rtex_divzero06 1 <hangs> <CTRL+C> causes a kernel panic Expected Results: See above. Program should print !DivideByZeroException. Actual Results: Program hangs on 10.8 and 10.9. When CTRL+C'ing the program, causes a kernel panic on 10.9. Version: 10.8 10.9 %uname -a Darwin <machine> 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 Notes: The program is a compiled test case from the Virgil programming language: https://code.google.com/p/virgil/ Configuration: This always occurs on 10.8 and 10.9. It never occurs on 10.6. Have not tested on 10.7. _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Multipathed LUN Path Control & Notifications
by Matt Bauer 11 Dec '13

11 Dec '13

I’m looking for help in getting notifications of path changes for multipathed drives such as those attached to Fibre Channel or a SAS array. i’ve been able to replicate the functionality of mpioutil to control the active/inactive paths by setting the PathState property on IOSCSIHierarchicalLogicalUnit. I can’t however read the PathState the same way (doing a IORegistryEntryCreateCFProperty). Looking at the disassembly of mpioutil, it appears it’s using a sysctl (debug.SCSIMPIOStatistics) but I haven’t been able to get that sysctl to work. I also need to get notifications of path changes from IOSCSIHierarchicalLogicalUnit/IOSCSIMutltipathedLogicalUnit. Looking at the disassembly of the IOSCSIArchitectureModelFamily it doesn’t look like notifications are provided. Is that true? Does anyone have any thoughts/suggestions? Thanks, Matt Bauer In case you’re curious why I need this, the storage array is shared with other machines and if all the machines don’t hit the correct RAID controller on the array, performance tanks. That said, if there is a true path failure, I need to know so I can tell the other machines to failover to the other path. This will ensure the performance level I require. If I can’t get IOSCSIHierarchicalLogicalUnit/IOSCSIMutltipathedLogicalUnit working, I may just change my extension to perform their functionality. _______________________________________________ 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: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0