User: Password:
|
|
Subscribe / Log in / New account

Fast interprocess communication revisited

Fast interprocess communication revisited

Posted Nov 11, 2011 0:31 UTC (Fri) by cmccabe (guest, #60281)
Parent article: Fast interprocess communication revisited

Great writeup, Neil!

I didn't realize Binder had the transaction ID semantics you mentioned.

It might be worth mentioning that Binder allows the callee to identify the caller's UID and PID. Since Android gives each application its own UID, this is sufficient to implement a relatively sophisticated security policy.

Also, since Android 2.0, bionic supports mutexes and semaphores with PTHREAD_PROCESS_SHARED. (It's just futexes, after all.) So you can roll your own zero-copy solution if you're so inclined. As best as I understand, Binder always does one copy, so if you're passing an enormous amount of data, you might want to do this.


(Log in to post comments)

Fast interprocess communication revisited

Posted Nov 12, 2011 3:32 UTC (Sat) by neilbrown (subscriber, #359) [Link]

Thanks.

The passing of uid and pid is no different from Unix Domain sockets, except that they pass gid as well where binder doesn't. As I wanted to report on novelty rather than just pick holes in things there seemed little point in mentioning it - but yes, it could certainly be useful.

I wonder about the wisdom of using a shared-memory locks (such as a futex) between process with different uids. Presumably the reason that they have different uids is that they don't trust each other. And as a rogue process can corrupt a futex leaving the other processes unable to work effectively with them, it doesn't seem safe. Between processes in the same security domain (with same uid) it does make sense, but I'm not sure that applies to Android.

As yes - you might be able to create a zero-copy solution with shared mappings (if you trust the other processes) but my understanding from the CMA discussion was that this isn't as easy as it sounds. It means that you need to keep all of they data that you might want to send to some other process in shared memory. Which comes close to having your entire heap in shared memory. There might be reasons to not want to do this. But I'm not speaking from experience, just from what I've read, so this is probably an over-simplification.

Fast interprocess communication revisited

Posted Nov 14, 2011 11:27 UTC (Mon) by abacus (guest, #49001) [Link]

I wonder about the wisdom of using a shared-memory locks (such as a futex) between process with different uids. Presumably the reason that they have different uids is that they don't trust each other.
One way of setting up shared memory is by mapping a tmpfs file in memory. One can control which processes can map such a file by assigning proper (group) security attributes to it.

It's absolutely impossible.

Posted Nov 14, 2011 17:31 UTC (Mon) by khim (subscriber, #9252) [Link]

And as a rogue process can corrupt a futex leaving the other processes unable to work effectively with them, it doesn't seem safe.

It's impossible to corrupt a futex, not matter "what" and "if". Futex exist entirely in kernelspace, it does not matter if processes trust each other or not.

You can corrupt interprocess mutex (built on top of futex), but this is question of mutex implementation.

Fast interprocess communication revisited

Posted Nov 14, 2011 19:23 UTC (Mon) by cmccabe (guest, #60281) [Link]

It's certainly true that when you start sharing a lot of memory between processes, you start to see some of the same issues that you see with threads. I would encourage people to not go down this road unless they really have have to.

I'm curious whether it is safe in theory to share a futex with a malicious process. Obviously, the malicious guy can cause a denial-of-service (for example, by refusing to release the lock), but can he do more than that? I've read through some of the futex READMEs, including Ulrich Drepper's, but I still don't feel confident enough to answer this question.

(This is ignoring the practical reality that when you share enough memory, you'll inevitably forget to validate something somewhere in one process or the other.)

Fast interprocess communication revisited

Posted Nov 17, 2011 14:24 UTC (Thu) by renox (subscriber, #23785) [Link]

> I wonder about the wisdom of using a shared-memory locks (such as a futex) between process with different uids

I don't think that Binder is for 'untrusted' usage, if I read correctly the article if you send a message it becomes immediately part of the memory of the destination process, so it seems to be easy to create a DOS (increase the memory usage of the destination process too much and it would be killed) but maybe there are safeguards which weren't mentioned..

Fast interprocess communication revisited

Posted Nov 17, 2011 19:53 UTC (Thu) by neilbrown (subscriber, #359) [Link]

When a processes calls mmap on the binder fd, it specifies how much space to map. Binder refused to map more than 4Meg. If you send a message to a process and it doesn't have room in that space to store the message, you get an error back.

So the worst one process can do to another is fill up its incoming queue so that it cannot get real work done.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds