Re: ipc security

[Bas Wijnen]

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.

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

> All is solvable, but I don't see the benefit.

It solves the problem of replying unbounded strings.  It can also solve 
the problem of physmem unmapping pages without asking, but a different 
solution would probably be preferable for that.  It doesn't need to be 
used in other situations (although it can.)  If the restrictions (such 
as the source string being in one container) are too strict, and you can 
as well use a different method, then go ahead.  For every transfer, a 
choice must be made, and this is just one of the options (and it's the 
only one for unbounded string replies.)

> And why should physmem spend its CPU time on this task?

Good question.  In fact, it shouldn't.  Which is why I want to view the 
copy itself as an atomic operation, which doesn't take time.  Of course 
this isn't entirely true, and actually I don't know if it even comes 
close.  At least locks are needed to prevent the memory being written 
from being freed and possibly even reused.  If extra mappings are 
needed, well, they aren't done until the client requests them.  The 
container is expanded, though, and I also have no idea how much time 
that costs.  In particular, it may have to wait for a lock to be 
released, but that is a physmem-internal thing, so that will never be 
long.  However, if the total takes a significant amount of CPU time, it 
is a problem, as physmem isn't the task to take the responsibility for it.

> The rason we introduce concepts like shared memory
> containers is that we want to use them.  If we can't use them for such
> applications, there is a fundamental flaw.

Yes, I would like a better solution, at least for bounded string 
replies, as well.

> > 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.
>
>
> 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.  An other solution is to have a client share the 
same container with all servers, but then the servers could corrupt each 
other's data, which is not acceptable.  Physmem can be trusted not to do 
that.  If it would, it can do it anyway, no matter what you do.

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

> However, we can keep this idea in mind, and if you are all gung-ho
> about it, you may want to implement it to see how it works.

I might do that, but I think other things are more important to start 
with.  And the problem is probably nonexistant once they are 
implemented.  ;-)

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature