November 2008 - Darwin-dev - lists.apple.com

interprocess communication
by Rakesh Singhal 20 Nov '08

20 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=YeL6eCTzumnV/xyaAfZsU4ldzHzWpMdoVCTSzJzJZRU=; b=enRHjn6I7LxP3DnPjq3XEFIDrPScvZKfC9oiGQECI5j/0WAV2ArMvAyyeq+Pavyvrs cbi/n07EfQ8G6qTByMxhn3N7SwSegWS4H6Cd1HQseGGR7uzP3vQL50HzVWz0BLUXXTcM aWs0s1S6QAnIfi/GL0h0mPQQhLm/+4Eu6VdC4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=Q3vvnwPAwkS6h//1dH99ndVRuicQiBBFS/MPeHfeoyEiAvYKSPTmZpeGb3vambUTuJ Pn8zcntk+RX3uKzlCsvnfyts3u+NrjrjmMU9jQyEkwIU6r+M9rtfzVl2rQkR+A2PAesq 8JDmV6o3XbQRxaatpgVjnTBICu+1OR4yAWH2s= Hi all I want some advice on Inter Process Communication (IPC). I have one dynamic library(dylib) and one application(app). Actually I am porting something from Windows so I will write about windows code. In Application, I create one event object (eventName). Now, I create one thread and call waitForSingleObject and now it is waiting for someone to set the event and the it will come out. In DLL I create one event object of same name (eventName). Now, whenever I need, set the event in DLL then in application that thread comes out of wait and executes the code and again start waiting. I want to implement similar kind of thing in Mac also. I want to create one event with same name in both process and application should notified whenever dylib set the event. I do not know that I have to do with event or something else. DLL is standard C++ dynamic library and application is standard C++ tool (command line utility). Please suggest me to solve this issue. Thanks and regards rksinghal _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: open stub in libc trashing word in caller's frame?
by R. Matthew Emerson 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 19, 2008, at 5:21 PM, Dave Zarzycki wrote: So if we do something like pushl <precious stuff> pushl $O_RDONLY pushl <address of path> call _open R.Matthew Emerson, Thank you. Bug number 6386516. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… then, the <precious stuff> word on stack below the O_RDONLY word is going to get its high half zeroed. Good call. Please file a bug. This email sent to site_archiver(a)lists.apple.com

1 0

loginwindow
by Kevin Metha 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=9s6ubIIp6BwxoBE4XvSsZWp+azxmTxmCkzNlEIU0Cb0=; b=gLINFOZV79QRprXbNIC/DFM+flIYRvxLRn+Z4FBGn/6TJAhlQHZGYhDppZhe+CALZz mZGJE5PvCA8pRE2SOEUNbj0LX0RtJdhmt6ydgFE3lAt3EUEMXOqbhzquvkT1Kpj2886e zWqXcoBbQRIJczgKvWQ+p3zrr5l0xuystIGs8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=X6wPY/xq+D7zCWqmUcNoaTaMDWqgbvm5OleGt79tjQaJPfaaKoJy//vDs43NJGSWaI kuM2p93RB+lbWmEqTdSW+cSq2UBUw61AsDCtCDJqrvF7c2zWENdGTtxaa2DvNYxippk8 67oJa/BWG4b05S88Ie9y1KZ6LSENWbDxIFisk= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: open stub in libc trashing word in caller's frame?
by R.Matthew Emerson 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 19, 2008, at 3:23 PM, Dave Zarzycki wrote: [...] So if we do something like pushl <precious stuff> pushl $O_RDONLY pushl <address of path> call _open On Nov 19, 2008, at 11:25 AM, R.Matthew Emerson wrote: I work on a Common Lisp compiler. >From the libc sources (Libc-498/sys/open.c), we see and the code for this (on Mac OS X 10.5.5) is 0x90925a44 <open>: push %ebp 0x90925a45 <open+1>: mov %esp,%ebp 0x90925a47 <open+3>: mov 0xc(%ebp),%eax 0x90925a4a <open+6>: movzwl 0x10(%ebp),%edx ; [1] 0x90925a4e <open+10>: or $0x20000,%eax 0x90925a53 <open+15>: mov %edx,0x10(%ebp) ; [2] 0x90925a56 <open+18>: mov %eax,0xc(%ebp) 0x90925a59 <open+21>: leave 0x90925a5a <open+22>: jmp 0x908a0e88 <open$NOCANCEL$UNIX2003> Like I mentioned, we see the int open(const char *, int, ...) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The callee is not setting up the stack frame correctly. mode_t is a short, but it must be word aligned on the stack. One can observe this fact by reviewing what GCC actually generates by this code: But in this case, there is no mode argument for the caller to properly align. I'm sorry if I'm being thick, but if I call the open stub in libc with only two arguments, e.g. like with open(path, O_RDONLY), isn't the libc stub trashing the word where a mode argument would be if I'd called it with 3 arguments? then, the <precious stuff> word on stack below the O_RDONLY word is going to get its high half zeroed. We have a way to call C library functions from the lisp. We process the C headers with a custom ffigen and use the resulting data to know the C types, number of arguments, and so forth. When we call open(2) on 32-bit x86, though, something odd seems to be happening. /* * open stub: The legacy interface never automatically associated a controlling * tty, so we always pass O_NOCTTY. */ int open(const char *path, int flags, mode_t mode) { return(__open_nocancel(path, flags | O_NOCTTY, mode)); } The problem here is that if we call this with only two args, this code will trash a word in the caller's frame (see [1] and [2] marked above). prototype in fcntl.h, and don't know anything about the __DARWIN_ALIAS_C(open) stuff, which is why we end up calling the "legacy" interface. Do I need some remedial i386 ABI instruction? Or is something else wrong? This email sent to site_archiver(a)lists.apple.com

1 0

Re: open stub in libc trashing word in caller's frame?
by Dave Zarzycki 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Nov 19, 2008, at 5:10 PM, R. Matthew Emerson wrote: On Nov 19, 2008, at 3:23 PM, Dave Zarzycki wrote: [...] So if we do something like pushl <precious stuff> pushl $O_RDONLY pushl <address of path> call _open R.Matthew Emerson, Good call. Please file a bug. davez On Nov 19, 2008, at 11:25 AM, R.Matthew Emerson wrote: I work on a Common Lisp compiler. >From the libc sources (Libc-498/sys/open.c), we see and the code for this (on Mac OS X 10.5.5) is 0x90925a44 <open>: push %ebp 0x90925a45 <open+1>: mov %esp,%ebp 0x90925a47 <open+3>: mov 0xc(%ebp),%eax 0x90925a4a <open+6>: movzwl 0x10(%ebp),%edx ; [1] 0x90925a4e <open+10>: or $0x20000,%eax 0x90925a53 <open+15>: mov %edx,0x10(%ebp) ; [2] 0x90925a56 <open+18>: mov %eax,0xc(%ebp) 0x90925a59 <open+21>: leave 0x90925a5a <open+22>: jmp 0x908a0e88 <open$NOCANCEL$UNIX2003> Like I mentioned, we see the int open(const char *, int, ...) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The callee is not setting up the stack frame correctly. mode_t is a short, but it must be word aligned on the stack. One can observe this fact by reviewing what GCC actually generates by this code: But in this case, there is no mode argument for the caller to properly align. I'm sorry if I'm being thick, but if I call the open stub in libc with only two arguments, e.g. like with open(path, O_RDONLY), isn't the libc stub trashing the word where a mode argument would be if I'd called it with 3 arguments? then, the <precious stuff> word on stack below the O_RDONLY word is going to get its high half zeroed. We have a way to call C library functions from the lisp. We process the C headers with a custom ffigen and use the resulting data to know the C types, number of arguments, and so forth. When we call open(2) on 32-bit x86, though, something odd seems to be happening. /* * open stub: The legacy interface never automatically associated a controlling * tty, so we always pass O_NOCTTY. */ int open(const char *path, int flags, mode_t mode) { return(__open_nocancel(path, flags | O_NOCTTY, mode)); } The problem here is that if we call this with only two args, this code will trash a word in the caller's frame (see [1] and [2] marked above). prototype in fcntl.h, and don't know anything about the __DARWIN_ALIAS_C(open) stuff, which is why we end up calling the "legacy" interface. Do I need some remedial i386 ABI instruction? Or is something else wrong? This email sent to site_archiver(a)lists.apple.com

1 0

Re: open stub in libc trashing word in caller's frame?
by Dave Zarzycki 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com R. Matthew Emerson, int foo(char *path, int flags, short mode, int word) { return 0; } int main(void) { return foo("hello", 123, 755, 0xdeadbeef); } 0x00001fcd <main+0>: push %ebp 0x00001fce <main+1>: mov %esp,%ebp 0x00001fd0 <main+3>: sub $0x18,%esp 0x00001fd3 <main+6>: movl $0xdeadbeef,0xc(%esp) 0x00001fdb <main+14>: movl $0x2f3,0x8(%esp) 0x00001fe3 <main+22>: movl $0x7b,0x4(%esp) 0x00001feb <main+30>: movl $0x1ff9,(%esp) 0x00001ff2 <main+37>: call 0x1fca <foo> 0x00001ff7 <main+42>: leave 0x00001ff8 <main+43>: ret davez On Nov 19, 2008, at 11:25 AM, R.Matthew Emerson wrote: I work on a Common Lisp compiler. >From the libc sources (Libc-498/sys/open.c), we see and the code for this (on Mac OS X 10.5.5) is 0x90925a44 <open>: push %ebp 0x90925a45 <open+1>: mov %esp,%ebp 0x90925a47 <open+3>: mov 0xc(%ebp),%eax 0x90925a4a <open+6>: movzwl 0x10(%ebp),%edx ; [1] 0x90925a4e <open+10>: or $0x20000,%eax 0x90925a53 <open+15>: mov %edx,0x10(%ebp) ; [2] 0x90925a56 <open+18>: mov %eax,0xc(%ebp) 0x90925a59 <open+21>: leave 0x90925a5a <open+22>: jmp 0x908a0e88 <open$NOCANCEL$UNIX2003> Like I mentioned, we see the int open(const char *, int, ...) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/zarzycki%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The callee is not setting up the stack frame correctly. mode_t is a short, but it must be word aligned on the stack. One can observe this fact by reviewing what GCC actually generates by this code: The above generates the following. Please note the word alignment of the short value: We have a way to call C library functions from the lisp. We process the C headers with a custom ffigen and use the resulting data to know the C types, number of arguments, and so forth. When we call open(2) on 32-bit x86, though, something odd seems to be happening. /* * open stub: The legacy interface never automatically associated a controlling * tty, so we always pass O_NOCTTY. */ int open(const char *path, int flags, mode_t mode) { return(__open_nocancel(path, flags | O_NOCTTY, mode)); } The problem here is that if we call this with only two args, this code will trash a word in the caller's frame (see [1] and [2] marked above). prototype in fcntl.h, and don't know anything about the __DARWIN_ALIAS_C(open) stuff, which is why we end up calling the "legacy" interface. Do I need some remedial i386 ABI instruction? Or is something else wrong? This email sent to zarzycki(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

open stub in libc trashing word in caller's frame?
by R.Matthew Emerson 19 Nov '08

19 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I work on a Common Lisp compiler. >From the libc sources (Libc-498/sys/open.c), we see and the code for this (on Mac OS X 10.5.5) is 0x90925a44 <open>: push %ebp 0x90925a45 <open+1>: mov %esp,%ebp 0x90925a47 <open+3>: mov 0xc(%ebp),%eax 0x90925a4a <open+6>: movzwl 0x10(%ebp),%edx ; [1] 0x90925a4e <open+10>: or $0x20000,%eax 0x90925a53 <open+15>: mov %edx,0x10(%ebp) ; [2] 0x90925a56 <open+18>: mov %eax,0xc(%ebp) 0x90925a59 <open+21>: leave 0x90925a5a <open+22>: jmp 0x908a0e88 <open$NOCANCEL$UNIX2003> Like I mentioned, we see the int open(const char *, int, ...) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… We have a way to call C library functions from the lisp. We process the C headers with a custom ffigen and use the resulting data to know the C types, number of arguments, and so forth. When we call open(2) on 32-bit x86, though, something odd seems to be happening. /* * open stub: The legacy interface never automatically associated a controlling * tty, so we always pass O_NOCTTY. */ int open(const char *path, int flags, mode_t mode) { return(__open_nocancel(path, flags | O_NOCTTY, mode)); } The problem here is that if we call this with only two args, this code will trash a word in the caller's frame (see [1] and [2] marked above). prototype in fcntl.h, and don't know anything about the __DARWIN_ALIAS_C(open) stuff, which is why we end up calling the "legacy" interface. Do I need some remedial i386 ABI instruction? Or is something else wrong? This email sent to site_archiver(a)lists.apple.com

1 0

Leopard sed(1) behavior hangs...
by Harry Plate 18 Nov '08

18 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AclJ0PsBduHLe/k36EG8mrPL5L+FEg== Thread-topic: Leopard sed(1) behavior hangs... User-agent: Microsoft-Entourage/12.14.0.081024 [had submitted this to the Unix-porting list; it was suggested I try this list] I have been moving my build environment to Leopard (fm Tiger) for the past couple of weeks on a part-time basis. The Xcode projects (fm 2.5.1) all required changes - to deal with SRCFILE, and some new gcc visibility warnings. But I finally got that all cleaned up. What is killing me now are the numerous sh scripts that we use for testing on multiple platforms. I got beyond the tr(1) issues - where new complaints about illegal bytes sequences were encountered. Nice. But sed(1) seems to completely lockup in many cases; the process list tells that it is hanging and consuming 99% of its particular cpu. It appears that it must be hung" upon the initial open - cuz its output stream has produced nothing. I initially assumed that this was a similar issue as tr(1) (ie, text encoding) - and I tried a few things to normalize the incoming data stream to a particular text encoding (using iconv(1)). While that would seem to fix some hangs; other tests would then lock up. Sampling sed (using Shark) did not tell me anything; there were no symbol names revealed... Anyone have any comments on this behavior? Suggestions to remedy it? -harry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Device name of modem port
by Rakesh Singhal 18 Nov '08

18 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=Jt8q/42ywX2+TD/X46Wz9dtF5Un4spmnwE4OX4ERKyM=; b=t+6fdO6P5MIdNKRJ9AxNpuvh1gypF9B6d0kz6AL+oPlcXlgHLpEEhZoK2mzLv+XLiJ KeYcUJmvQyuiMsUv2+Lq2ILn2ZPqvKZqL+d/1+54MIpu8LPCPVR/wlq8C3Nnzg1Gv72y M/dyoZAyfECKQrdDjfDm02TO3+iQK4FZZuq/A= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JCgX5iBtE9IRep/mWmsLLMJEUQUU/kpSIp24wm+wU4UPk+1+BhX+gQqj7mUtMhmsh4 y9AQ18gjt7TBCNy5IP6UJK0gtO9Rrhdpx7iQwaQidRM6t6xbiT6OZ3Pc02r2J6Cmp6Ya 14LH91rWliV53U9AMj4XE83e6T6mHEXVhJTew= Hi all I am using SerialPortSample to get the information of modems on the system. I have one USB device and creates the virtual serial port (modem prt). Now, I am able to get the path to open the file and communicate with it. I need the device name for the same device. I can see the device name in IORegistry but not able to get it at code level. In my case, the device name is shown as object of IOUSBInterface class. Although I could not explain it properly but I hope you understood my query. I want the device name of which I am accessing the virtual serial port. I think I can do it using IORegistryEntryGetParentIterator, but in that case should I pass kIOServicePlane for plane parameter? Thanks in advance. Regards rksinghal _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Process Termination Detection
by Shawn Erickson 17 Nov '08

17 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JZzTiCrD8QjX0+qbVzjGUEsddF4DDGYOS/qzQB15a/c=; b=iP64U6YMDJqWs12xiwfIqr2CsYsZn4SXb7LNM1SozJBnwXGBJxY21nCRifb8EyxNPN Luv1CVUoD8VJyuvj/Os6V+DykyAcHhZuGrHX2akO19pIFFggXhumQ49V+YIYs5tPdImt 9TXTNUfTbU4j2Xd+Z2S7Md7qMMMWx6SqQ8yR8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=XPXEAny33RtPVJxMtWhvSe9OYGlNC1h2wV5/XeGK/qUgC7Qt9P8vVtFzzPlMbtVMaq ydV/L3WVzxgF3luqzCJ2jw8m8qMtkp9UW4cciQ0dcsTXW9Qs/r4kuyGfFWHnMUq5XOyk cq/OG25aX2cMoXONeEOiBT1FuBm7BCkDKqj54= On Sat, Nov 15, 2008 at 5:22 AM, Terry Lambert <tlambert(a)apple.com> wrote: > Maybe you can tell us a little bit more about the program you are trying to > attack, and why knowing that it has exitted will facilitate your attack, and > how narrow a time window you believe you have before the attack would fail, > and we could help you narrow things down. No attempt to attack anything here... In a nut shell ... we have a small "cluster" of processes that together make up our product. Part of this cluster of processes are launched by a single LaunchDaemon and the other part of this cluster of processes are launched by one or more LaunchAgents (aqua session or pre-login). The launch agent cluster up communicates with the launch daemon, etc. As part of this product we have the concept of processes that depend on other processes and hence need to know when a member of this cluster of processes dies (killed, crashed out, etc.) so we can take action to recover or tear down possibly orphaned processes (and possibly collect crash information). We are evaluating built-in methods to do this process watching as well as looking at methods we can implement using IPC internal to our process cluster. Basically trying to explore the options available while we figure out how best to meld that into our product code base which was originally tooled for Windows. On a side note we plan for all of our processes (executables) to be code signed with using same identity since the cluster of processes together make up on product from the end users point of view. -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0