[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What would it take....

From: Samuel Thibault
Subject: Re: What would it take....
Date: Wed, 23 Dec 2009 02:48:45 +0100
User-agent: Mutt/1.5.12-2006-07-14

Da Zheng, le Wed 23 Dec 2009 09:35:03 +0800, a écrit :
> Samuel Thibault wrote:
> >> When process-shared semaphores and mutexes themselves are in the shared 
> >> memory, can we not use the similar implementation as the ones in the same 
> >> process?
> > 
> > The implementation uses Mach messages, so it's basically the same thing.
> > With different tasks, you need to add the task name along the port name.
> > And you need that to be done securely, including for a semaphore between
> > a root process and a user process. In a process of a single user, much
> > less issues happen.
> I didn't realize there is a security issue.

There are always security issues whenever you have things shared between
different users :)

For instance, a processus can trust the port names it gives to itself. A
processus can however not trust port names it gets from somebody else
through just shared memory. An authority is needed to make sure both
parties are behaving correctly.

> Then must process-shared semaphores and mutexes be implemented in
> shared memory? or it's completely through IPCs?

Note that posix mutexes are always shared between processus through
shared memory anyway (the application is responsible for sharing the
memory). That can be used for fast locking (through atomics etc) and
reverting to ports can be done only in the contention case.

For semaphores, sem_init() behaves the same way. sem_open() is different
in that it doesn't requires shared memory, but I'd advise to just
automatically set up a shared memory segment and just work the same.

Anyway, deciding between shared memory or pure IPC is not really an
issue.  I believe the more difficult part is how to make process
actually perform IPCs securely.  It can probably be useful to check how
shm was implemented.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]