[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipc security

From: Bas Wijnen
Subject: Re: ipc security
Date: Fri, 22 Oct 2004 13:20:56 +0200
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]