Re: L4-Hurd; denial of service in the memory architecture

[Johan Rydberg]

Marcus Brinkmann <address@hidden> wrote:

: > Certainly you would want that task to access THAT
: > memory, but you certainly would not want that task to be able to
: > allocate more memory against your quota.
: 
: We will have a way to share memory securely with another task.  I am not
: sure how exactly it is done at a syntactical level (ie, which kind of cap is
: passed with which operations).  Surely the semantics have (and largely are)
: defined in the Right Way.

This is what weak references is for, if I remember correctly. For vmm.tex:

To facility this, a second class capability is provided to access
containers.  Using this capability, clients may not allocate or
deallocate frames.

  error_t pm_container_share (in container_t container, 
                              in task_t remote, 
                              out container_t weak_ref)
 
: > Why does the capability to
: > read or write a container also permit expansion of the container?
: 
: I am not even sure the details are set in stone at that level.  Take this
: stuff with a grain of salt.  The design, in particular the design of the VM
: subsystem, is not exactly finished.

If you pass a weak reference to a remote task, it may not allocate (expand)
or deallocate frames from that container.  What it may do is, though, write
over frames or copy frames into its primary container (or another one.) This 
will hopefully result in full zero-copy semantics (using COW.)

-- 
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/

Playing Snap Ant - Saviour Piece