Re: ipc security

[Marcus Brinkmann]

At Sat, 23 Oct 2004 01:05:26 +0200,
Bas Wijnen <address@hidden> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Marcus Brinkmann wrote:
> > At Fri, 22 Oct 2004 13:20:56 +0200,
> > Bas Wijnen <address@hidden> wrote:
> > 
> >>>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.
> 
> Well, physmem could place a restriction over it that it must be a 
> contiguous part in one container.  Of course that doesn't mean it isn't 
> scattered in physmem's mappings, but it will simplify it quite a bit, I 
> guess.  Anyway, that can be seen if it would be implemented.

And makes it less useful, adding the costs of several IPCs if you need
to gather.  At least with using mapped containers, the cost is fixed
(and as I believe, already close to the minimum required).

> > 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.
> 
> I was thinking to treat the copy like L4 does: as an atomic operation. 
> Physmem cannot page fault, so finding memory to add to the receiving 
> container shouldn't take long.  Containers should be locked when used 
> anyway, right?

I am referring to implementation details in physmem.  I don't have a
clear picture on how it will be implemented, but from my experience,
such constraints lead to ugliness in the implementation (problems with
the locking hierarchy, latency, etc).  It's just my gut feeling.

Containers don't need to be locked, in fact, you can't lock them, as
the user could revoke access any time (you _have_ read
IPC-Assurance.ps by now, right?  Similar constraints apply to the TBOs
in there).  The way you do it is by catching page faults in the server
on the memory mapped from the container, and when it is revoked (and
the mapping can't be reinstalled quickly, ie the frames are gone
permanently), then you just abort the operation.

Ie, you don't trust the memory mapping - when you access it, you first
call a macro that sets it up so that any page fault will not lead to a
fatal signal, but to a longjmp that breaks out of the operation
(sortof).

> > All is solvable, but I don't see the benefit.
> 
> It solves the problem of replying unbounded strings.

I meant the benefit as compared to using shared containers in the
usual, mapping way.

[...]
> > 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).
> 
> Yes, but there is a problem which is avoided if physmem does the copy: A 
> client doesn't need a shared container with every server.  It would 
> probably be quite a waste of memory to have that.  Every client having 
> one container for all these physmem-string-transfers (from any server) 
> is quite acceptable.

I don't see how that would work at all with parallel requests in a
multi-threaded client.  I don't see much flexibility in how many such
trusted buffer objects you need to set up with servers, irregardless
how the buffer objects are used (by mapping or copying in physmem,
etc).

> > But the container approach seems to be more flexible, and
> > more manageable to me (ie, keep it simple, especially: keep physmem
> > simple).
> 
> That is a good idea as well, of course.

I think one possible way forward from here would be for you to
thoroughly understand the container model (which will not be possible
just from the hurd-on-l4 document I am afraid, because that is not
complete), and then revise your idea with that knowledge in mind, and
make a final comparison.  If you then still see a significant benefit,
I'd like to see a more specific analysis and description of those
expected benefits.

I believe you will find out that a lot of expected advantages (like
using just one shared buffer) simply don't exist.  The main difference
would have to be looked at the very end-to-end use of these objects,
and who is responsible for what.  At least that's my expectation, from
what I think what your idea amounts to.

There is still substantial amount of things to understand here for all
of us (also in implementation details of physmem) before we really can
commit to anything here.  So, I really want the discussion open here
and let us review all ideas (existing and upcoming) from time to time,
as our understanding of the issues involved gets better.

IOW, let's postpone this discussion for a while.  Eventually some
realizations will sink in, and ideas will be separated (some will
float, some will sink and drown).

Thanks,
Marcus