Deceiving IPC question: Bug or Feature?

[Jonathon Earnshaw TIDSWELL]

Gernot wrote:

> We have noticed the following re deceiving IPC in L4/MIPS.
> 
> Assume task A is the chief of task B, which is the chief of task C. aa
> is a thread in A, bb a thread in B, cc a thread in C.
> 
> aa does a closed receive from bb. bb sends a deceiving message to aa
> with cc as the virtual sender. aa receives the message (although the
> virtual sender is different from the source specified in the
> receive). The kernel returns to aa the virtual sender specified by bb
> (i.e., cc), but the C bindings discard this information, so aa cannot
> see it using the C interface.
> 
> If in the otherwise identical situation aa does a closed receive from cc
> it does NOT receive the message.

>  - is this the correct behaviour?
 
Michael wrote:

> I think this should be reversed: aa should receive the message in the
> second scenario, but not in the first.

I would concur with Michael.
The first scenario has theoretical problems the second does not.
But this says nothing about what happens in other L4's, or what
is cost effective to implement in the kernel.

Argument:

Expand the problem space by adding a task D, with a thread dd,
in the same clan as C.  All IPC from dd to aa is also via bb.

If aa must specify bb in the closed receive then the kernel cannot
distinguish whether aa is waiting on cc or dd.

Since aa can only receive IPC from cc deceited via bb, the implied
meaning of a closed receive from cc "has" to be of a deceited message
from cc via bb, i.e. scenario two matches expected semantics.
[ In scenario one it means a permanent block, and there are other
ways to achieve that. ]

- JonT