[cap-talk] Value of 'copy on write' as attenuation mechanism.

[Neal H. Walfield]

At Thu, 22 May 2008 21:00:03 +0200 (CEST),
Rob Meijer wrote:
> I am a bit confused as to 'real' storage for COW.
> Lets look at two scenarios:
> 
> Scenario 1:
> 
>   * Alice delegates a directory to Bob granting full access to the dir.
>   * Bob delegates a COW attenuation for this directory to Carrol
> 
> Scenario 2:
> 
>   * Alice delegates a read only attenuation of a directory to Bob.
>   * Bob delegates a COW attenuation for this directory to Carrol
> 
> With normal attenuation, the space allocated can be seen as being bound to
> the original owner of the original directory. However in the above
> scenarios, the creation of the COW attenuation should in some way bind
> potential storage for copies to the attenuation.
> 
> If not for scenario 2, you could say that the data allocation should be
> bound to the original data owner. However, given that Alice delegates a
> 'read only' attenuation to Bob, allowing Bob or Carol to claim storage in
> her name would seem strange.
> 
> Do you see my problem with fitting COW within the controled 'rw' based
> attenuation patterns? I feel I not fully understand how COW should work
> in a consistent and intuitive way for both the scenario's above.

It seems to me that in both of your scenarios, Carrol should normally
be accounted the storage, not Alice and not Bob.  The reason for this
is that it is a service that only she profits from and no one else.
(An example of a not normal situation is a transparent proxy.  In this
case, the proxy would pay but that's not a problem.)

Assuming that you are interested in Unix's normal mmap MAP_PRIVATE
semantics, all that Carrol requires is read-only access to the object
and the ability to catch her own write faults.  In both scenarios,
Carroll has the former.  On Unix-like systems, Carroll can catch
SIGSEGV signals and transparently make a copy as required.

The problem with MAP_PRIVATE semantics is that it since MAP_PRIVATE
considers each page to be an independent object, it can lead to
inconsistencies for objects that span multiple pages.  Consider such
an object.  Imagine that Dave has write access to it and Carroll has
read-only access and she implements COW for her own faults.  Imagine
she writes to the start of the object.  In this case, she will make a
copy of the first page.  Now, imagine Dave performs an update.  His
update spans both pages.  Carroll will now have an inconsistent view
of the object: she will have her copy of the first page and the second
page as updated by Dave; she will not see Dave's update to the first
page.

To solve this problem, Mach provides MAP_COPY semantics in addition to
MAP_PRIVATE.  When a user establishes a MAP_COPY region and another
writes to it, Mach creates a copy and Carroll keeps the original
version; Mach does not only create a copy when Carroll writes to a
page.  Thus, MAP_COPY creates a snapshot of the object's state at the
time of the map and only sees her own updates.

To implement MAP_COPY, one requires the ability to detect when an
update to an object is about to occur and create a copy before that
happens.  In your scenarios, Carroll does not have that ability, only
Alice does.  To implement MAP_COPY semantics, either this information
must be exposed (which is likely a security leak) or it requires that
Alice implement the COW semantics.  On EROS or Viengoos, the usual
pattern for requesting services is that the caller supply a resource
principal (on EROS, a space bank, on Viengoos, an activity) and that
principal is charged for all resources consumed on its behalf.  Thus,
in such systems, Alice can implement MAP_COPY on behalf of her clients
without requiring that she use her own storage.

Neal