September 2003 - Darwin-kernel

Re: Programmatic Back Trace
by Geoffrey Schmit 03 Sep '03

03 Sep '03

On 03.09.2003 at 11:06 AM, Jim Magee <jmagee(a)apple.com> wrote: > On Sep 3, 2003, at 10:23 AM, Geoffrey Schmit wrote: >> I'm currently stuck trying to find a function that is accessible by a >> kernel extension and that is equivalent to vm_read_overwrite in that >> it will return an error if the specified address is inaccessible >> rather than throwing a SIGSEGV signal. >> >> So, a couple of questions: >> >> Is there an example that captures a back trace in a kernel extension? >> If so, where is it? > > Are you trying to get a user-level backtrace or a kernel backtrace > from your kernel extension? And more importantly, why are you doing > this from a kernel extension in the first place? I'm primarily interested in getting a kernel backtrace from my kernel extension. I'm porting a library that provides various services to other kernel extensions we develop. One of these services is to capture a backtrace. For example, we may capture a backtrace when a kernel extension detects an error in order to facilitate the debugging of that error condition. As another example, we may capture a backtrace when a kernel extension acquires a resource in order to later determine who acquired that resource if the resource is leaked. Ideally, it would be beneficial for the backtrace to eventually include the stack of the user-mode thread that initiated the transition to the kernel (in scenarios where this is the case). However, that is probably pushing my luck.... I'm not at all interested in developing a kernel extension to capture user-level backtraces from arbitrary processes. > In-kernel, if you access memory you don't have mapped, you're dead > (panic). You don't get a signal to respond to. And, besides, you can't > directly access any user-level memory at all. On PowerPC, user-memory > isn't mapped into the kernel's view of memory, since the kernel gets > it own 4GB address space. i386 is slightly different, but changing > more towards the PowerPC model than the other way around. So, my problem is probably that as I walk the stack I eventually encounter an address from a user-mode thread and cause a panic. Is there a way to test if the address belongs to the kernel or otherwise determine that I should stop walking the stack? If further clarification would be helpful, please let me know. Thanks! geoff _______________________________________________ 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: Programmatic Back Trace
by Jim Magee 03 Sep '03

03 Sep '03

On Sep 3, 2003, at 10:23 AM, Geoffrey Schmit wrote: I'm currently stuck trying to find a function that is accessible by a kernel extension and that is equivalent to vm_read_overwrite in that it will return an error if the specified address is inaccessible rather than throwing a SIGSEGV signal. So, a couple of questions: Is there an example that captures a back trace in a kernel extension? If so, where is it? Are you trying to get a user-level backtrace or a kernel backtrace from your kernel extension? And more importantly, why are you doing this from a kernel extension in the first place? Maybe if you are writing a new whole-system/kernel debugger or something. But looking at user-space backtraces (or memory in general) from random points in the kernel is extremely touchy stuff and highly likely to kill the whole system if done at the wrong point. Not to pick on you in particular, but to make a point in general, the kernel is not always a better place to stuff "everything." Far fewer things work reliably within the kernel than outside. And our system provides "much sharper" tools outside the kernel than a typical Unix system - so far fewer things need to be in the kernel in the first place. Remember, the tools are so sharp that, in theory, even "the kernel" doesn't need to be in the kernel. ;-) If I can't, any suggestions on other ways to achieve my goal? For example, can I catch the SIGSEGV signal, set an error condition, and continue execution? In-kernel, if you access memory you don't have mapped, you're dead (panic). You don't get a signal to respond to. And, besides, you can't directly access any user-level memory at all. On PowerPC, user-memory isn't mapped into the kernel's view of memory, since the kernel gets it own 4GB address space. i386 is slightly different, but changing more towards the PowerPC model than the other way around. If you are always running in the execution context of a thread that is part of the process you are trying to access, you can do "copyin()." And if you are always in a clean state, you can even use vm_read_overwrite() (taking into account in-kernel semantics of such calls). But I highly recommend doing all this from outside the kernel if at all possible (have your kext block the thread in question so that the out-of-kernel process will always find the process alive if necessary). --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

Programmatic Back Trace
by Geoffrey Schmit 03 Sep '03

03 Sep '03

I need a function that performs a back trace in a kernel extension. I found the MoreBacktrace example <http://developer.apple.com/samplecode/Sample_Code/Overview/MoreIsBetter /MoreBacktrace.c.htm> and began to modify this code to work in a kernel extension. I'm currently stuck trying to find a function that is accessible by a kernel extension and that is equivalent to vm_read_overwrite in that it will return an error if the specified address is inaccessible rather than throwing a SIGSEGV signal. So, a couple of questions: Is there an example that captures a back trace in a kernel extension? If so, where is it? If not, what is a function similar to vm_read_overwrite that is accessible by a kernel extension? If there isn't, how can I test if an address is valid before trying to read it? If I can't, any suggestions on other ways to achieve my goal? For example, can I catch the SIGSEGV signal, set an error condition, and continue execution? Thanks! geoff -- Geoffrey Schmit Senior Software Engineer National Instruments geoffrey.schmit(a)ni.com www.ni.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

Keeping C data structures and assembly versions in sync
by Brad Post 02 Sep '03

02 Sep '03

I don't know if this is the forum for it, but I thought I would ask anyway. Does anyone know an easy way to keep data structures in C and their assembly counterparts in sync easily? I hate having to constantly go edit the header file for the assembly included section to keep it in sync with the C structure... Thanks. Brad _______________________________________________ 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

UDF VFS & resource forks
by Marek Kozubal 02 Sep '03

02 Sep '03

Hello! Does anyone know if the UDF file system code is anywhere in Darwin? Its not in the obvious places (xnu/bsd/miscfs, xnu/bsd, or in its own package in darwin 6.6). I am hoping that looking at the lookup() function in the UDF VFS kext will give me the answer I am looking for reguarding the following. I have a layered (stacked) file system over a UDF disk. The problem I'm having is that the resource forks (and other HFS+ style meta-data) are some how getting lost. If I mount the disk normally everything works fine. From the command line on a normal mount doing: ls -l foo/..namedfork/rsrc works as expected, however in my file system I get a ENOTDIR error in my own lookup() pass through call. So this error seems to be generated somewhere in the UDF lookup() call. So I guess my question is, how do resource forks and other HFS+ style meta-data work on the UDF/ISO disk systems? And why does the POSIX way of getting to resource forks work fine normally but not though my own file system. Resource forks and meta-data work fine for HFS+ disks in my file system. Also I've checked for the existance of ._foo files, but I did not find any sign that is how they're doing resource forks. Any help would be most appreciated! Thanks in advance. --- Marek Kozubal marek(a)portents.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: crossing user-kernel boundary (using copyin/copyout or mmap?)
by Jim Magee 01 Sep '03

01 Sep '03

On Sep 1, 2003, at 12:06 AM, Nathan Lim wrote: So I have attempted the following to get information from the kernel to the user-space client (I will also want to send information the other direction): A) allocate memory in the user space using malloc() B) pass the allocated user space void * ptr to the NKE via sysctl of an int C) in the NKE, call copyout() like this: ret = copyout(k_addr, u_addr, shareSize); This results in the copyout returning EFAULT (bad address). I checked the pointers and believe I am dereferencing all the addresses correctly, but it still doesn't work. The copyout() function only works when you are guaranteed to be running in the context of a thread within the target process. Since NKEs typically run in many random thread contexts (all the user-level threads from all applications that are pushing data through the network stack as well as the kernel-bound threads that drive data upward from the devices), very rarely will you be in the right context for the copyout(). In fact, the EFAULT cases are the least of your worries. On many of the cases where you didn't get EFAULT, you might have been corrupting some innocent task's memory. My questions are: 1) Are the copyout() and copyin() functions the best way to do this (i.e. share memory across the user-kernel boundary)? Not for NKEs to "push" data to user-space, typically. 2) Should I be using mmap() or something else instead? 3) What do I need to do to get the copyout() working? 4) Do I need to wire the memory to get the copyout() to work? Do you really need to use a "push" model for moving data from the kernel to the user-space? Can you keep the data pooled in the kernel and then call a special ioctl() to actively pull the data out from the user-level thread context? If so (and I recommend this), then you can use copyout() because you will always be in the right thread context. If you must "push" the data out of the kernel (from whatever random context you may executing in within your NKE), you probably want to use a prepare()'ed and map()'ed IOKit memory descriptor. The only trick (and it is a big one) is correctly detecting that your "special" user-level process (the one that has the memory that you are copying out to) has gone away in order to clean that up and release the hold on the memory (otherwise you will likely keep the process lingering a sort-of-zombie state waiting for the IOKit memory descriptor prepare() to be complete()'ed). --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

crossing user-kernel boundary (using copyin/copyout or mmap?)
by Nathan Lim 01 Sep '03

01 Sep '03

I am writing an application that uses an NKE (Network Kernel Extension) and a user space client. I would like to share approximately 1KB of information between the NKE and the user-space client. According to Apple's "Inside Mac OSX: Kernel Programming" document chapter entitled "Boundary Crossings": "For one, memory allocated in the kernel cannot be written to by applications, including those running as root" and "In the Mac OS X kernel, data is most easily copied into kernel space with the BSD copyin function, and back out to user space with the copyout function." So I have attempted the following to get information from the kernel to the user-space client (I will also want to send information the other direction): A) allocate memory in the user space using malloc() B) pass the allocated user space void * ptr to the NKE via sysctl of an int C) in the NKE, call copyout() like this: ret = copyout(k_addr, u_addr, shareSize); This results in the copyout returning EFAULT (bad address). I checked the pointers and believe I am dereferencing all the addresses correctly, but it still doesn't work. My questions are: 1) Are the copyout() and copyin() functions the best way to do this (i.e. share memory across the user-kernel boundary)? 2) Should I be using mmap() or something else instead? 3) What do I need to do to get the copyout() working? 4) Do I need to wire the memory to get the copyout() to work? 5) Where can I find a well commented example of an NKE (or similar) sharing memory across the user-kernel boundary? Any help is greatly appreciated! Thanks! -Nate Lim _______________________________________________ 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