Re: ipc security

[Bas Wijnen]

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

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 :)

Sounds good.

> 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
> following:
>
> 1. We understand the security limitations of our design, and their
>    consequences.
>
> 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
> BufferRegisters.

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 
doesn't help.

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

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.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature