[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipc security
Re: ipc security
Fri, 08 Oct 2004 19:41:16 +0200
Mozilla Thunderbird 0.8 (X11/20040926)
Marcus Brinkmann wrote:
At Fri, 08 Oct 2004 16:04:03 +0200,
Bas Wijnen <address@hidden> wrote:
- One solution is to make IPC of map items a priviledged action, which
can only be done by threads in the root server's address space
I don't like this very much, because it is like cutting off the whole
That's why I expect the L4 people to not like really like it, and only
want it in the kernel if it can be switched off ;-)
However, for the Hurd I don't see the problem. We don't really trust
any task (except physmem.)
But you could actually extend the meaning of the redirector
field by saying: If the redirector is set to "any local thread" then
map items (in inter-AS IPC) are not allowed, otherwise the message
will be processed normally.
Sort of a built-in redirector with the behaviour I described :)
I think a kernel change like the first one you described (well, I
prefer my idea, but anyway, a small non-intrusive kernel change) would
be acceptable. We don't need to do it. We just need to ensure the
1. We understand the security limitations of our design, and their
2. We can offer strategies to people who want to go beyond these
limitations that are practical.
At least for this issue, we have done 1 (by understanding how L4
works) and 2 (redirectors, or a small kernel extension + corresponding
small change in the OS code), so we are fine.
For the moment (and probably some years to come) I agree that it isn't
neccesary. Everything will work fine without it. However, eventually
it should be done to have a good system.
If the server can not trust the client, how can it know about the memory
it uses? I thought the server could only send a string item (or accept
one), not know where it's coming from.
I don't understand your question. String items are copied from the
address space of the sender to the address space of the receiver at
IPC time. You specify the source of the string item in the sender via
StringItems and the destination buffers in the receiver via
My problem is on page 63 of the reference manual, where Xfer pagefaults
are described. It is specifically stated that either side can be
starved by a malicious pager from the other side. The solution to this
is not to use string items. You seem to think that specifying a 0
timeout will also solve the problem (by aborting at the first
pagefault.) I don't see anything about 0 timeouts in the manual, but
the presented solution (don't use strings) suggests to me that it
In fact, I might have make a mistake in the above paragraph you
replied to. It may be indeed the case that you can not differentiate
between "local pagefaults" and "remote pagefaults" when specifying the
You can, there is a send and a receive Xfer timeout. However, the
timeouts are only checked at pagefault, which means that a pager not
responding to the page fault will hang the IPC.
Using containers is _very_ expensive and may be even more complicated
to use properly than string items.
Aren't containers just memory pages which are mapped into more than one
address space? Creating them can cost a lot, which is why I thought
about the "container manager" task, which has a permanent container with
the server. Then if any task which trusts the manager wants to get a
string of, say, 300 bytes, the server can copy it into the container
(which is just a memcpy within the address space) and after that, the
manager can do a string IPC to the actual client. The overhead is the
memcpy, which probably takes as long as the string transfer itself
(after all, that also is just a memcpy.) It seems to me you think there
is more overhead than that. Am I missing something? Or do you think
the container must be resized in the operation? That can happen
sometimes, but I think it should be possible to give it a reasonable
size, so it doesn't need to resize often.
To do string items properly is in fact not too complicated: You only
need to wire down the memory areas involved. That's just a call to
the internal pager library which just has to mark those pages as
currently not available for swap out. That's fast.
Sure, but the server can only hope the client does that, the client
cannot be trusted.
In fact, in some scenarios, you don't even need to do that, it's
probably sufficient to touch the pages before sending the message and
hope they are not swapped out immediately.
You either trust that a 0 timeout will work, or you trust the client's
pager. I'm pretty sure you don't trust the pager, so it must be the
timeout. Perhaps I should just try it out.
Description: OpenPGP digital signature