Re: ipc security

[Marcus Brinkmann]

At Fri, 22 Oct 2004 13:20:56 +0200,
Bas Wijnen <address@hidden> wrote:
> > In fact, in a more complicated protocol, you could even have physmem
> > copy the memory, then let the task map the new location (atomically),
> > and then unmap the old location.  This way you could reorganize memory
> > without temporarily unmapping the memory.  But this needs the task's
> > support.  We could make it a rule that the task needs to respond to
> > that quickly (as with extra fpages).  This idea just occured to me.
> 
> If you're going to negotiate with the task anyway, you can as well let 
> physmem tell the task forcefully to swap out or free any or a certain 
> page.

That's not the same.  The purpose would be to never have the fpage be
actually unmapped and unavailable (so to guarantee that there will
never be page faults raised on that fpage).  This should work if you
just send a mapping over an existing mapping (the old mapping will be
replaced atomically).

We are talking about memory that should not be swapped out or
unmapped, so asking the task to do so is futile (otherwise we wouldn't
face the problem in the first place, and physmem could just unmap it).

> Not responding, or not swapping out is an illegal operation and 
> will get the whole address space destroyed.  Of course physmem should 
> use that as little as possible, but I think it might be good to have the 
> option.  Something needs to be done if a task reserved a lot of memory 
> when there was no load, and refuses to let go of it when the load increases.

Well, that is part of the normal guareanteed frames and extra frames
scheme.  Number of guaranteed frames can be renegotiated from time to
time (well, that's the idea anyway).
 
[...]

> If the protocol allows both, by sending either a string item, or a code 
> via untyped messages telling where the string was placed, I don't see 
> much difference between sending and receiving.  The sender will know the 
> size of the string, so it can decide which method to use.

I lost a bit track of which conditions we are assuming here.  So
apologize for dropping this part of the message.  I don't know anymore
if we talk about containers, or what, at this point.

> > Basically, it seems you are proposing that instead of mapping a
> > container and then writing to the memory mapped, you can fill
> > containers by sending string items to physmem.
> 
> Eh, no.  I propose to not use L4 string items at all, but instead send a 
> similar IPC of untyped words to physmem.  Physmem should then interpret 
> it as a string-copy command, and it will copy the string into a 
> container of the designated client.  Physmem will of course have access 
> to the string items without them being sent to it, as it has access to 
> all memory.

I don't think that's as easy as you make it sound.  The strings could
be scattered all over the place, in different containers etc.  Then
you would need to prevent your own pager from dropping those frames
until the copy is done.  And physmem would not be able to reorganize
that physical memory until it is done with the copy.  All is solvable,
but I don't see the benefit.  And why should physmem spend its CPU
time on this task?  The rason we introduce concepts like shared memory
containers is that we want to use them.  If we can't use them for such
applications, there is a fundamental flaw.

> > The idea is sound, but there is a problem.  It doesn't work.  :) The
> > receive buffers have to be set up in physmem before you receive the
> > IPC.   Any task may send its IPC to physmem, so you don't know for
>  > which container you are receiving a string item next.
> 
> Because physmem is copying the data, and not L4, it can make such 
> decisions after receiving the IPC.  And because the IPC doesn't actually 
> transfer data, no extra copying is involved.

That's true.  However, the same is true if you do the copy yourself,
and then you get a lot of "right consequences" (about where the
responsibilities are).  You can spent the IPC you would use to perform
the in-physmem-copy on mapping the memory.  The cost of installing the
mapping aetc must be small in comparison with the actual data copy.
So, the original container approach doesn't seem to be any worse than
your idea (you said yourself your approach would only be slightly
better, but we can happily agree that all attempts at actually
guessing the performance of these things which are so similar is
futile).  But the container approach seems to be more flexible, and
more manageable to me (ie, keep it simple, especially: keep physmem
simple).

However, we can keep this idea in mind, and if you are all gung-ho
about it, you may want to implement it to see how it works.
Eventually, all of such ideas have to be proven against reality.

Thanks,
Marcus