dynamic reconfiguration

[Adam Lackorzynski]

On Mon Aug 08, 2016 at 12:32:02 +0200, ba_f wrote:
> Am 2016-08-05 15:08, schrieb Matthias Lange:
> > Hi,
> > 
> > On 08/04/2016 03:05 PM, ba_f wrote:
> > > But, is it also possible to do some configuration during run-time i.e.
> > > dynamic reconfiguration?
> > > Here are two examples I can think of:
> > 
> > Well, it depends ...
> > 
> > > - IPC-Channels: Instead of defining Server and its Clients in conf.cfg
> > > statically, is it possible to create IPC-Channel during run-time?
> > > Let's
> > > say, I have a L4re-App in conf.cfg defined as IPC-Server but, no
> > > Clients, yet. Now, may any L4re-App create a IPC-Channel by itself and
> > > such link to that IPC-Server?
> > 
> > The answer is 'Yes.' and 'No'. The answer to the first question is that
> > this is exactly what ned is doing. Ned creates an IPC gate object and
> > maps it into the tasks as specified in the provided Lua configuration.
> > 
> > The second is not possible for multiple reasons. The first one is, that
> > the server side already needs the IPC gate object to bind its server
> > loop to. Another task has no means to "lookup" the existing IPC gate
> > object. In fact that's the idea behind a capability system.
> 
> So, what you are saying is this: In fact, Ned maps the IPC-Channels at
> run-time but practically, one has to configure all IPC-Channels possible in
> Lua.cfg, statically.
> An ordinary L4Re-App is not able to link to an IPC-Server App if this
> channel hasn't been configured in Lua.cfg, right?

Yes.

> In this case, the L4Re-App also cannot manipulate Ned or something at
> run-time to create an IPC-Channel, afterwards.

It cannot because Ned does not have an interface to do that.
Generally, if two tasks want to communicate, both need to have a cap on
the ipc-channel. As those two cannot communicate (yet), there has to be
a third component (with appropriate access to the two that want to
communicate) to establish the connection.

> > > - New Tasks: Is a L4re-App able to create a new task? I.e. push a
> > > thread
> > > into its own address-space? The new task would require some access
> > > rights, too.
> > 
> > Yes. Ned and L4Linux are just two examples doing this.
> 
> Interesting.
> Can you give an example why and when L4Linux is doing this, please?

There's a L4 task for every Linux process. But that task does not have
any caps at all because the vCPU in L4Linux uses such a task to execute
Linux processes. There's no extra L4 thread in this case.
But L4Linux could do that.

> As L4Linux is just an "ordinary" L4Re-App I assume that any L4Re-App can
> create new tasks, don't they?

Yes, given they have access to the factory that allows them to create
new tasks and threads. Usually this is the case but it's not mandatory.

> Or, do I have to configure such L4Re-Apps with specific rights, statically
> in Lua.cfg or something?

No.

> Now, what about the security issues?
> Let's say L4Linux creates a new Task "Child".
> Does "Child" have the same access rights as L4Linux has, only?
> Or, may L4Linux even give enhanced access rights to "Child"?

L4Linux can give the child any rights it has itself, or less, but
obviously not more rights.

> E.g. "Child" could be a HW-Driver and such would require access rights to
> some HW-Address.

Then L4Linux also needs to have the rights to access this IO memory.




Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/