Re: Could kernel copy memory between processes directly?

[Zvezdan Petkovic <zvezdan@CS.WM.EDU>]

On Mon, Jul 08, 2002 at 10:53:38AM -0400, Ian Darwin wrote:
> > Definitively no, everyone is saying that. If you haven't heard about
> > synchronous messaging I encourage you to read:
> > 
> > http://www.qnx.com/developer/docs/momentics_nc_docs/neutrino/sys_arch/kernel.html
> > (section "Synchronous message passing")
> > 
> > It's a bit similar to Mach messaging. The whole idea could be described
> > like procedure call into another process.
> > 
> > For shared memory processes must be trusted while for SRR the client
> > (Sender) cannot break the server (Receiver), Important factor, isn't it :-)
> 
> You've said this before but not elaborated.  Perhaps you do not
> understand that a shared memory *segment* is just that - a relatively
> small piece of memory that is mpaped into both processes. It does
> NOT give either process access to all the other processes' memory,
> so I'm not sure why you think trust is such a big issue.  There is a
> single integer key required to locate the smh segment AND filesystem-like
> permissions to control access; if you need more secure authentication,
> you can have a shared private key or whatever, exchanged through the SHM
> segment.  The Crypto libraries give you the mechanism and, if nobody
> but your two apps  know the policy, so much the better.
> 

Absolutely correct. One can easily allocate even SYSVSHM from kernel on
one side and user-level process (a daemon) from the other. User-level
process does NOT gain kernel privileges because of that. :-)

And if one measures the performance, SHM is faster than message-passing,
AFAIK. 

However, there might be some use of the direct kernel-to-kernel message
passing between remote nodes on the net to avoid performance loss. I
know of at least one such research (with the Linux kernel though).

-- 
Zvezdan Petkovic <zvezdan@cs.wm.edu>
http://www.cs.wm.edu/~zvezdan/