July 2004 - Darwin-kernel - lists.apple.com

Re: Passing a char** to a Kext from user mode
by Krishna Monian 02 Jul '04

02 Jul '04

Thanks Changing the char** to a string buffer (char*[]) solved and then using copyinstr solved the problem. I am curious Aren't GetProperty()/SetProperty() for only for for modifying registry entries? --- Marek Kozubal <marek(a)portents.com> wrote: > On Fri, 2 Jul 2004, Marek Kozubal wrote: > > > Generally, you send a pointer (ie char *) to your > kext via some > > communications method. Then inside the kernel you > use copyinstr()/copyin() > > to get the string into the kernel, or > copyoutstr()/copyout() to put it back > > to user space. You don't use a char **. You have > to create a buffer in user > > space, then create a buffer in kernel space and > copy the data back and forth. > > I just realized, that I should have mentioned this > is for kext's that are > not IOKit kext's. If you're in IOKit you use > GetProperty()/SetProperty() > type methods. > > --- > Marek Kozubal > marek(a)portents.com > __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail _______________________________________________ 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: Passing a char** to a Kext from user mode
by Marek Kozubal 02 Jul '04

02 Jul '04

On Fri, 2 Jul 2004, Marek Kozubal wrote: Generally, you send a pointer (ie char *) to your kext via some communications method. Then inside the kernel you use copyinstr()/copyin() to get the string into the kernel, or copyoutstr()/copyout() to put it back to user space. You don't use a char **. You have to create a buffer in user space, then create a buffer in kernel space and copy the data back and forth. I just realized, that I should have mentioned this is for kext's that are not IOKit kext's. If you're in IOKit you use GetProperty()/SetProperty() type methods. --- 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: Passing a char** to a Kext from user mode
by Godfrey van der Linden 02 Jul '04

02 Jul '04

The answer for this depends totally on what space you are operating in:- VFS, NKE, IOKit or other? Also what are you trying to copy from the kernel's address space to user land? How much data are you going to move? Godfrey On Jul 1, , at 16:04, Krishna Monian wrote: Hi, I am trying to write a kernel extension in which I have to pass a char** to it from a user mode application. Currently I have tried passing the pointer as a scalar and as a struct(wrapped in a struct) to the kext. However this results in some weird behavior. What is the right way to pass such information to the kext? Thanks _______________________________________________ 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: Passing a char** to a Kext from user mode
by Marek Kozubal 02 Jul '04

02 Jul '04

On Thu, 1 Jul 2004, Krishna Monian wrote: I am trying to write a kernel extension in which I have to pass a char** to it from a user mode application. Currently I have tried passing the pointer as a scalar and as a struct(wrapped in a struct) to the kext. However this results in some weird behavior. Generally, you send a pointer (ie char *) to your kext via some communications method. Then inside the kernel you use copyinstr()/copyin() to get the string into the kernel, or copyoutstr()/copyout() to put it back to user space. You don't use a char **. You have to create a buffer in user space, then create a buffer in kernel space and copy the data back and forth. HTH --- 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

Passing a char** to a Kext from user mode
by Krishna Monian 01 Jul '04

01 Jul '04

Hi, I am trying to write a kernel extension in which I have to pass a char** to it from a user mode application. Currently I have tried passing the pointer as a scalar and as a struct(wrapped in a struct) to the kext. However this results in some weird behavior. What is the right way to pass such information to the kext? Thanks __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail _______________________________________________ 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: Why isn't mach_destroy_memory_entry exported?
by Dan Bernstein 01 Jul '04

01 Jul '04

Right, haven't thought of that. It's a good thing I ran into that perceived problem with mach_destroy_memory_entry or I would have thought my solution was secure. Thanks again for your help! On Thu, 1 Jul 2004 12:10:33 -0400, Jim Magee <jmagee(a)apple.com> wrote: > Now, lets assume that while the client DID have access, it sends some > portion of that memory contents to some other server "copy-on-write." > Or it makes twelve [shared] copies of it in his own address space. Or > it requests some form of long-term IOKit UserClient direct I/O to the > memory. You have no control over any of this - regardless of the > design of your server. _______________________________________________ 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: Why isn't mach_destroy_memory_entry exported?
by Jim Magee 01 Jul '04

01 Jul '04

On Jul 1, 2004, at 11:31 AM, Dan Bernstein wrote: > When the client is not supposed to have access to the server's memory > any longer (and of course after we give it proper notification to the > effect), the server calls vm_deallocate, specifying the client task > and the address in client's space. This indeed prevents further access > by the client to that address (and should it attempt it, the client > would indeed crash with a memory access violation, but of course the > client was notified beforehand and only a malicious client would try > that. Still, I don't see how this comes close to crashing or otherwise > compromising the system. This is not different than the client doing > the same thing with an address which never was part of its address > space). Now, lets assume that while the client DID have access, it sends some portion of that memory contents to some other server "copy-on-write." Or it makes twelve [shared] copies of it in his own address space. Or it requests some form of long-term IOKit UserClient direct I/O to the memory. You have no control over any of this - regardless of the design of your server. > Anyway, all of the above is exactly as I want it to be: access is > granted and later access is revoked. My only issue is that for the > call to vm_map I need to make that map entry, and while I realize this > is not the memory allocation itself, it is still a resource that > should be disposed of when no longer needed (in fact, I want to > dispose of it right after calling vm_map, I don't need to wait till > after vm_deallocate). Given the examples I pointed out above, its probably more correct to say that "access is granted and later [you hope] access is revoked." But there are so many ways in which such attempts of revocation can be defeated (both malicious and accidental), you simply can't do it reliably. As I said before, your best bet is to abandon the memory in the server and start anew there - not try to revoke the memory from the client and all the possible copies, shares, etc... he arranged when you weren't looking. To voluntarily dispose of your [named entry] handle to the memory after the vm_map() call, simply call mach_port_deallocate() on it. --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ 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: Why isn't mach_destroy_memory_entry exported?
by Dan Bernstein 01 Jul '04

01 Jul '04

I think I found another solution that doesn't require me to use mach_make_memory_entry. Instead I use vm_remap to map the server memory into the client's address space, and vm_deallocate to revoke the client's rights when necessary. The reason I didn't use this approach in the first place was that vm_remap doesn't let you change the protection (the client needs read-only access in certain cases), but now I just remap first into server space, protect the server's copy, then remap it into client space. The reason I don't want to do what you've suggested, with the server remapping the memory as a copy (on write) for itself is that it does use up more resources (eventually most of the memory will have to be copied) and that the server keeps all sorts of pointers into that memory so I don't want to have to change its base address. Thanks for your replies, 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

Re: Why isn't mach_destroy_memory_entry exported?
by Dan Bernstein 01 Jul '04

01 Jul '04

I think I didn't make myself clear enough. All my code is in user space. I have one task ("server") that wants to share a part of its address space with another (user-space) task ("client") for a *limited* amount of time. The way I do it right now is as follows: the server allocates the memory for itself. The client sends its task port to the server. Then the server calls mach_make_memory_entry for the memory it allocated, then the server calls vm_map, specifying the client task, in order to map the server's memory into the client's address space. This works fine and indeed the client gets access the server's memory (the server lets the client know where in the client's space it mapped the memory). When the client is not supposed to have access to the server's memory any longer (and of course after we give it proper notification to the effect), the server calls vm_deallocate, specifying the client task and the address in client's space. This indeed prevents further access by the client to that address (and should it attempt it, the client would indeed crash with a memory access violation, but of course the client was notified beforehand and only a malicious client would try that. Still, I don't see how this comes close to crashing or otherwise compromising the system. This is not different than the client doing the same thing with an address which never was part of its address space). Anyway, all of the above is exactly as I want it to be: access is granted and later access is revoked. My only issue is that for the call to vm_map I need to make that map entry, and while I realize this is not the memory allocation itself, it is still a resource that should be disposed of when no longer needed (in fact, I want to dispose of it right after calling vm_map, I don't need to wait till after vm_deallocate). On Thu, 1 Jul 2004 10:55:23 -0400, Jim Magee <jmagee(a)apple.com> wrote: > > > On Jul 1, 2004, at 10:40 AM, Jim Magee wrote: > > > On Jul 1, 2004, at 1:23 AM, Dan Bernstein wrote: > >> In case the answer is "don't call mach_make_memory_entry in the first > >> place", how else can one task grant access to a piece of memory to > >> another task, so that the first task can later revoke that access? > >> Currently, I use vm_map, and that seems to require a map entry. > > > > Once access is granted to others, there is no mechanism to revoke it. > > This makes sense, since the only mechanism the system would have to > > implement a revocation would be to raise a bus error if anyone accessed > > the revoked memory (or any copy-on-write of the revoked memory passed > > on to other system servers, etc...). So, in effect, revocation could > > easily be used to crash the whole system - not something we want in the > > hands of a regular application. > > I realize I wasn't very clear here. The mach_destroy_memory_entry() > call, even if it was exported, doesn't revoke the memory represented by > the handle. It simply deletes one reference to the handle. You get > the same effect at user-space by calling mach_port_deallocate() on the > handle. But neither has any effect on tasks that have already mapped > the memory represented by the handle. It just deals with the handle > itself. > > --Jim > > > > > smime.p7s - 2K _______________________________________________ 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: Why isn't mach_destroy_memory_entry exported?
by Jim Magee 01 Jul '04

01 Jul '04

On Jul 1, 2004, at 10:40 AM, Jim Magee wrote: > On Jul 1, 2004, at 1:23 AM, Dan Bernstein wrote: >> In case the answer is "don't call mach_make_memory_entry in the first >> place", how else can one task grant access to a piece of memory to >> another task, so that the first task can later revoke that access? >> Currently, I use vm_map, and that seems to require a map entry. > > Once access is granted to others, there is no mechanism to revoke it. > This makes sense, since the only mechanism the system would have to > implement a revocation would be to raise a bus error if anyone accessed > the revoked memory (or any copy-on-write of the revoked memory passed > on to other system servers, etc...). So, in effect, revocation could > easily be used to crash the whole system - not something we want in the > hands of a regular application. I realize I wasn't very clear here. The mach_destroy_memory_entry() call, even if it was exported, doesn't revoke the memory represented by the handle. It simply deletes one reference to the handle. You get the same effect at user-space by calling mach_port_deallocate() on the handle. But neither has any effect on tasks that have already mapped the memory represented by the handle. It just deals with the handle itself. --Jim [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ 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