[okl4-developer] Direct IPC from OKLinux userland processes toOKL4 services
Carl van Schaik
carl at ok-labs.com
Mon Mar 3 22:25:17 EST 2008
Hi Jorge,
Sending IPC from Linux user thread to other system threads directly is a
tricky issue for various reasons. Despite the obvious security
implications, OK Linux has some other issues.
1. OK Linux may try to preempt the user thread while it is in an IPC
with another thread. OK Linux will cancel that IPC and break the
communication.
2. If the thread is woken up by another thread other than OK Linux, you
can get two Linux user thread active at the same time. If this second
thread does a syscall to OK Linux, it will likely be killed or panic OK
Linux.
3. Thus you are probably restricted to non-blocking sending of messages
or asynchronous notification. You most likely won't be able to receive
messages unless you block and these blocking calls will be canceled
periodically.
4. You probably can't access any memory objects via shared memory from
anything else in the system. OK Linux is the pager of user threads and
Iguana won't map pages to these threads.
Problem 1 could be hacked around in the Linux kernel by putting the user
thread into a special mode. Note then that it won't be able to perform
Linux syscalls while in this mode. This may remove problem 2 and 3, but
there may be other unforeseen problems.
I hope this sheds some light on the situation.
regards,
Carl
Jorge Torres wrote:
> Hi Geoff,
>
> Thanks for your reply, but I'm not sure if you've read the previous
> e-mails on this, this is due to the following, and please forgive me
> if I'm wrong:
>
>
> It is up to the system to prevent such abuse by user threads in
> preemptive multi-tasking environments. Modules are different because
> they run with the same privileges as the Linux kernel anyway, this is
> not the case for user applications.
>
>
> Yes, but we are talking of enabling IPC communication between oklinux
> user threads and l4 native ones, true; the usual way of doing this is
> by writing a proxy driver that does it, My point is that writing such
> driver is still dangerous, just as it is enabling direct IPC on the
> basis of giving the OKLInux user thread a higher priority than the
> OKLinuxkernel one, and making the oklinux scheduler aware of it, by
> the mechanism initially proposed in this discussion.
>
> This does not work because it can allow the "current" pointer
> in Linux to get stale. e.g. Thread A runs, gets interrupted due
> to an OK Linux timer interrupt, OK Linux performs scheduling
> decision +
> dispatch and hence changes the current pointer. At this point
> the L4 timeslice expiry kicks in, the scheduler schedules Thread A
> due to robin-robin scheduling and at this point your current pointer
> is stale.
>
>
> This wont happen since as initially pointed linux scheduler would've
> been aware of it, and hence would've have sent it to a waitqueue,
> before the userlevel threads enters into dealing with native l4-iguana
> operations (please refer to the first emails on this). therefore linux
> kernel will never perform as you say, as long as the thread remains on
> the waitqueue as proposed (making the scheduler aware of threads
> performing l4native aperations).
>
>
> Unfortunately this scheme does not work as pointed out above.
>
> Note that currently the system does not enforce who the OK Linux
> user threads can Ipc() to. What we are trying to say is you
> can in theory use Ipc() inside OK Linux user threads, however, there
> are many things that need to be considered if you dec
>
>
> This is just a propossal for Damien's idea, on direct IPCing,
> nothing else, on which I have proposed that it could be possible if
> the scheduler knows that it can't schedule tasks that are doing l4 IPCing.
>
> Cheers AGAIN,
>
>
> JORGE
>
> >
> >
> > Cheers,
> >
> > Jorge
>
> -gl
>
> >
> > On Fri, Feb 29, 2008 at 12:49 AM, Nelson Tam <nelson at ok-labs.com
> <mailto:nelson at ok-labs.com>> wrote:
> >
> > > Hi all,
> > >
> > > On 29/02/2008, at 1:58 PM, Kalamkar, Dhiraj D wrote:
> > >
> > > > I am not sure whether OKLinux userland process can access Iguana
> > > > services directly even after the changes you suggested in
> OKLinux
> > > > scheduler. As far as I understand Iguana server and other
> services
> > > > are based on Iguana Single Address Space (SAS). i.e. Iguana
> server
> > > > and other services work on assumption that they have same
> virtual to
> > > > physical mappings for all the threads in Iguana PD (of
> course with
> > > > different access rights). As OKLinux user processes are external
> > > > address spaces (EAS) they can not access iguana services
> directly.
> > > >
> > > > Of course, after enabling IPC for userland OKLinux process,
> you can
> > > > do a raw IPC to any L4 thread and may write services which don't
> > > > assume Iguana SAS.
> > >
> > >
> > > On 29/02/2008, at 2:12 PM, Jorge Torres wrote:
> > >
> > > > Yes, one could use L4 native calls, and non SAS based iguana
> > > > services, like high resolution timers, or driver servers (I
> guess),
> > >
> > >
> > > Not all OKL4 services rely on the SAS. As correctly noted, as
> long as
> > > the service doesn't require any sort of shared memory, EAS threads
> > > would be able to utilise them also.
> > >
> > > Which brings me to an earlier question asked by Jorge: how to
> control
> > > IPC permissions in L4? The answer is L4_SecurityControl()
> (for IPC
> > > permissions you probably want the wrappers L4_IpcAllow() and
> cousins).
> > >
> > > But as I said before, you shouldn't do this in the OKLinux
> setup due
> > > to scheduling reasons.
> > > --
> > > (nt)
> > >
> > > Nelson Tam
> > > nelson at ok-labs.com <mailto:nelson at ok-labs.com>
> > >
> > >
> > > _______________________________________________
> > > Developer mailing list
> > > Developer at okl4.org <mailto:Developer at okl4.org>
> > > https://lists.okl4.org/mailman/listinfo/developer
> > >
>
> > _______________________________________________
> > Developer mailing list
> > Developer at okl4.org <mailto: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
>
More information about the Developer
mailing list