[okl4-developer] A doubt about blocking receive

[Ben Leslie]

On Tue Sep 11, 2007 at 10:11:55 +0530, Kalamkar, Dhiraj D wrote:
>Agree that there is a potential for covert channel. But only microkernel
>can keep track of blocked receivers (or senders) and there is no way for
>root server (e.g. iguana server) to find out blocked receivers on a
>particular sender before killing that particular sender.
>
>Also, microkernel should at least provide support for timeout for
>blocking send/receive operations. Otherwise, there is a good potential
>for intended or unintended denial of service attack.

There are very good reasons for not providing timeouts for blocking
operations. The main reason here is that for most operations there is
no sensible way for a useful timeout value to be picked. Say for
example you pick 10msec, but the reply is not ready until 11msec, what
do you do? You can retry, but in that case, you might as well have
just picked a greater time period. The second reason is that removing
timeouts can significantly reduce the complexity inside the kernel.
Finally, for cases when a timeout really is desired, i.e: when you
have some human interaction, where a timeout can be related to a human
event, then you can use a user-level timer server. For example you can
register to receive a timeout, after a particular time. This follows
the minimality principle of micro-kernels, where if feature can be
provided outside the micro-kernel, it should be.

Hope that explains some of the issues involved.

Best regards,

Ben

>-----Original Message-----
>From: developer-bounces at okl4.org [mailto:developer-bounces at okl4.org] On
>Behalf Of Gernot Heiser
>Sent: Tuesday, September 04, 2007 6:07 PM
>To: developer at okl4.org
>Subject: Re: [okl4-developer] A doubt about blocking receive
>
>Mwarton wrote:
>
>> You are correct in this case, t1 will remain blocked waiting for t2,
>> even if t2 is deleted.  However, If t1 was blocked sending to t2, it
>> would be aborted and returned failure.  The reason for the difference
>> is that the kernel does not internally track waiters on a specific
>> thread.
>
>Please note that it is inherently not the microkernel's job to keep
>track of what partners you might be communicating with, and whether or
>not they still exist.
>
>In fact, from the security point of view, this would create a security
>hole (covert channel). The present receive behaviour is therefore
>required. You can expect the present send behaviour to change in a
>future API version, in order to eliminate this potential covert
>channel.
>
>Gernot
>
>_______________________________________________
>Developer mailing list
>Developer at okl4.org
>https://lists.okl4.org/mailman/listinfo/developer
>
>_______________________________________________
>Developer mailing list
>Developer at okl4.org
>https://lists.okl4.org/mailman/listinfo/developer