[okl4-developer] Fwd: A doubt about blocking receive

[Jorge Torres]

---------- Forwarded message ----------
From: Jorge Torres <jorge.torres.maldonado at gmail.com>
Date: Sep 18, 2007 11:16 PM
Subject: Re: [okl4-developer] A doubt about blocking receive
To: "Kalamkar, Dhiraj D" <dhiraj.d.kalamkar at intel.com>

Hi Dhiraj,


You are correct about that, a server for IPC timeout wont work for directed
IPC messages, but having the timeout as a server, has some advantages; you
are able to use timer drivers, which operate on top of L4, which makes
timeouts handling cleaner, If it were me changing something inside kernel's
code, I would simply add a KIP field with a predefined thread ID from which
any other receiving thread can handle IPC messages regardless of it waiting
for some specific sender, and then simply edit IPC syscalls to support this.


Hope it helps,

Jorge

On 9/11/07, Kalamkar, Dhiraj D < dhiraj.d.kalamkar at intel.com> wrote:
>
>  Hi Jorge,
>
>
>
> I guess, IPC timeout server can't help for blocking sends and directed
> receives (specified destination). E.g. the code generated by IDL compiler.
> L4_Call() used by IDL client header can not use IPC timeout server and if
> server crashes before sending reply to client, client remains blocked for
> ever.
>
> At least I don't know how to use timeout server in such situation, I will
> be glad if you can help me out by giving some details about how to use it.
>
>
>
> Thanks,
>
> Dhiraj
>
>
>  ------------------------------
>
> *From:* Jorge Torres [mailto:jorge.torres.maldonado at gmail.com]
> *Sent:* Tuesday, September 11, 2007 9:18 PM
> *To:* Kalamkar, Dhiraj D
> *Subject:* Re: [okl4-developer] A doubt about blocking receive
>
>
>
> Hi Kalamkar,
>
>
>
>
>
> Yes, but you can make your own timeout by sentting a timer, it would be a
> nice idea to set an IPC timeout server, and you dont have to add such
> complexity to the kernel which is the reason of not adding such timeouts
> inside the kernel initially,
>
>
>
> Cheers,
>
>
>
> Jorge
>
>
>
>
>
> On 9/10/07, *Kalamkar, Dhiraj D* < dhiraj.d.kalamkar at intel.com> 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.
>
> Thanks,
> Dhiraj
>
> -----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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20070921/5285c3e0/attachment.htm