Mechanism for downgrading a RAM dataspace to read-only access #5815
Description
In situations where ROM modules are dynamically created, they are backed by RAM dataspaces, which are by their nature not read-only. There are currently two coping strategies for dealing with this leaky abstraction.
First, ROM servers like report_rom and fs_rom create one RAM dataspace per client. So "ROM" modules are not shared by different clients. Each client can in principle change the content of ones own ROM module, but this has presumably no effect on others.
Second, the cached_fs_rom server does not hand out the RAM-dataspace capability directly, but creates a managed dataspace per ROM module where the RAM dataspace is attached read-only. The client receives only the managed dataspace with the read-only attachment. So from the client's perspective, the ROM module is in fact read-only. Hence, one ROM module can be shared among multiple clients.
Both approaches have downsides. The first approach violates the expectation that ROM modules are read-only. Should a client delegate such a ROM module to an untrusted peer, the integrity of the ROM content cannot be presumed because the untrusted peer can technically mutate the content. Even though this situation may sound artificial, it is at least surprising. It effectively blocks performance optimizations based on the caching of ROM modules (e.g., think of caching .lib.so ROMs for children forked by the libc) because one can never be sure that a ROM module remains in tact once shared with an untrusted party.
In contrast, the second approach is safe but costly because each ROM needs a dedicated region map created via core's RM service. In addition to the added costs, the RM mechanism has the major downside that it is unavailable on base-linux. So for scenarios that need to run on Linux, cached_fs_rom cannot be used. This includes all scenarios that are routinely test-driven via goa run on a Linux host, e.g., all the packages based on the pkg/unix examples. Right now, those packages cannot benefit from the performance advantages of cached_fs_rom but have to use the plain fs_rom, which wastefully creates a copy for each ROM instance.
To overcome those downsides, we could add a new RPC function "seal" to the PD-session interface. For a RAM dataspace allocated by the PD, the seal operation downgrades the dataspace such that any subsequent attach of the dataspace will result in read-only mappings. Attachments established prior the sealing are unaffected. This way, the original creator of the RAM dataspace is able to keep a writeable mapping while all other peers are downgraded to read-only access. This may be useful for ROM services like report_rom that support version changes of ROMs over time. For ROM services like cached_fs_rom handing out ROMs with constant data, the RAM dataspace - once filled with content using a temporary attachment - can be detached before sealing. Now, by definition, no mutation can happen while the ROM module exist.