In the orthogonal scheme for segmentation and paging, segments (stored within a page and/or spanning several pages) can be individually protected using access rights bits which do not affect other segments held in the same page(s). The Monads systems take advantage of this in several ways.

• An address space (which contains one of
  • the persistent file segments of a module,
  • the code segments of a module
  • the stack segments of a persistent process, or
  • the heap segments of a module active in a process)

  has a "red tape area" at the beginning which contains system segments associated with the address space. This allows system and user information to be stored together in a single address space, without risk that the system information can be modified by the user.

  Such information includes for example
  • page tables (mapping pages of the address space to disk addresses),
  • information about the owner of the address space,
  • information about the use of the address space (e.g. when created, synchronisation information, links to related address spaces, pointer to the root user segment(s) in the address space).

• User segments within the address space can contain protected information (especially module capabilities, which cannot be directly accessed by the user but which can be addressed in a segmented manner (e.g. as a linked list of module capabilities).

• In the case of an address space for a process stack, sensitive information is stored between user segments (e.g. the linkage information between modules, but also - as we shall see later - parameter segments).

Abandoning the orthogonal scheme means that these protection situations must be realised in a different way. In a pure paging scheme access rights can only be imposed at the page level, so that we must in effect place sensitive information in different pages. This can be achieved as follows:

Address Space Red Tape

The special "red tape" segments at the beginning of an address space must be rounded up to an integral number of pages. This potentially leads to a small loss due to internal fragmentation of the memory. In this case an address space has two basic parts: red tape and user information, as follows:

This solution means that the internal user segments of an address space cannot be individually protected as they are in Monads. Instead the user sees (for each address space type which he can address) a single large segment, as in conventional systems. This means that segments containing Kernel information cannot be stored in user addressable segments as happens in the Monads systems.

Special Segments (e.g. Module Capability Segments)

In the Monads system these are flexibly implemented as "normal" (but protected) segments in the user area. Hence it is possible to place them in linked lists, etc. With SPEEDOS this is no longer possible. The solution is to include such segments in the red tape area of a module. This at least allows module capabilities to be stored in separate lists for the persistent data of a module, for the temporary heap of a module, etc.

Process Stacks

In implementing persistent process stacks we encounter additional protection problems.

The first is the linkage both between the routines of an individual module (inter-routine linkage) and also ­ even more significant from a protection viewpoint ­ between separate modules (inter-module linkage).

The second is the protection of information passed as (normal data) parameters from one module to another. This would not have been a special problem in the original Monads design, but for SPEEDOS this additional protection is required in order to implement the SPEEDOS solutions for the confinement problem (see Confinement of Objects).

In addition there is the issue that module capabilities can be passed as parameters; in Monads these would be passed in protected segments. In SPEEDOS they cannot simply be held in a single segment in the red tape of the address space, as this would lead to a situation in which any module could potentially acess the module capabilities passed to earlier called modules (or to extremely complicated software.

To solve these problems SPEEDOS uses two stacks:

• a system stack which holds linkage information and module capability parameters, and
• a user stack which holds in separate pages the local data of a process and the parameters passed between modules in the process.

Because only the Kernel can access the system stack directly, different segment types can be held contiguously, thus avoiding excessive internal fragmentation.

The associated user stack in principle contains two kinds of segments: local data and data parameters. The latter are only for passing parameters between modules, not between the routines of a single module. They begin on separate page boundaries, thus allowing the parameter data to be set to read only mode when the confinement permission permit_enq is turned off for the module.

In some versions of the SPEEDOS system it may be possible to eliminate local data segments and/or data parameter segments entirely, by using heap addressing for local data segments and/or by restricting inter-module call parameters to a small number of value parameters which can be passed in registers. (In this case registers must be cleared on an inter-module return if the permit_enq permission has been turned off.)