Re: ipc security

[Bas Wijnen]

Marcus Brinkmann wrote:
> At Fri, 22 Oct 2004 01:24:34 +0200,
> Bas Wijnen <address@hidden> wrote:
>
> > That's new for me, I expected mere mortal threads to not be allowed to 
> > mlock() any page at all.
>
>
> Well, what is mlock()?  Just a local function call that tells your own
> pager not to swap out a page.  Remember that tasks are self-paged.

Ah, right.  I was thinking of preventing physmem from unmapping it.

> You seem to misunderstand how paging will work.  Memory is never
> swapped out without the task which owns the memory requesting it.
> This is the whole reason behind being self-paged: You want to let the
> task make the decision about paging.  So, under memory pressure (which
> may have many reasons), the client can always opt to not swap out the
> receive buffers (if you don't have too many of them), but leave them
> in the working set.

I was indeed misunderstanding it.  I think I understand it now though. :-)

> The other reason why memory may be unmapped from your address space is
> that physmem may forcibly unmap it, to copy it to a different location
> in memory (to make space for DMA buffers, superpages, etc).  This is
> the trouble-some part, and the open question is if we should allow
> untrusted tasks to lock down the physical location (and thus the
> mapping) to some extent.
>
> 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.  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.

> > > For sending data, we could also have two interfaces if needed (one
> > > using string items and one using containers).  For receiving data,
> > > this is less useful.
> >
> > I can see that for receiving there is no problem in using strings.  I 
> > don't see why containers would not be useful for huge objects.
>
>
> It is less useful because when receiving data, you may not know how
> much you receive, and thus you won't know if string items or
> containers should be used.

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.

> 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.

> 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.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature