In order to perform useful operations, objects interact by means of method calls. To provide safe execution of applications, it is necessary to ensure that object interaction is governed by some precisely defined access control policy.

The E1 protection model is based on three assumptions:

1. Object methods have no immediate access to the internal state of other objects (object isolation requirement).
2. Objects can interact only by method calls.
3. Method calls are monitored by the operating system, which validates each call within effective access control policy.

These assumptions are provided, accordingly, by three mechanisms: protection domains, crossdomain calls and access control mechanism.

Operating system protection model has to be based on facilities provided by the underlying hardware platform, primarily, virtual memory mechanisms in modern microprocessors. Therefore, object protection is closely related to virtual memory organization.

In E1 all objects reside in a single virtual address space. Object interfaces are invoked directly by their virtual addresses, just as in C++ methods are invoked through the pointer to an object. The major advantage of such a virtual memory organization is a convenient programming model, which greatly simplifies the communication between objects. A single E1 address space spans the whole distributed system. Hence, all objects in the system are accessible by their unique virtual addresses from any network node.

The 4-gigabyte address space of modern 32-bit processors is, obviously, insufficient for holding all code and data of the distributed system. Therefore, single address space operating system (SASOS), like E1, requires a hardware platform with wide virtual address space.

Generally speaking, the E1 distributed object model could be implemented within the traditional private address space approach. In this case, smart pointers could be used to reference objects beyond the local address space. However, the single address space approach results in a simpler and easier-to-use architecture. Further analyzes of SASOS advantages can be found, for example, in [10, 22].

Let us return to the problem of distributed objects protection. The E1 protection model is based on object isolation requirement. According to that, the object's state is not directly accessible to other objects. To achieve such kind of isolation within a single address space, it is necessary to place each object into a separate protection context, so that virtual memory outside this context is unavailable to object methods. Although this scheme provides correct object isolation, it introduces a significant overhead. First, since memory management units of modern processors operate at page granularity, protection context can consist of an integral number of pages only, which results in extremely inefficient use of physical memory, especially in the case of small objects. Secondly, within the outlined approach every method invocation results in protection context switch, which requires a number of additional CPU cycles. During intensive object interaction context switching would consume a significant part of CPU time.

In order to provide effective object isolation in E1, we introduce the notion of protection domain, offering a trade-off between efficiency and safety of interaction. Protection domain represents a part of a single virtual address space, containing one or several distributed objects. Each object in E1 belongs to exactly one domain. Associated to each domain is a separate protection context, isolating internal domain objects from the other objects in the system. However, objects inside domain are not protected from each other. Intradomain method invocations do not require the protection context switch.

While arranging objects in domains, one must take into account the following factors:

• placing objects in different domains protects them from accidental or deliberate attempts of unauthorized access;
• method invocations within domain are more efficient than crossdomain calls;
• objects use physical memory more efficiently inside a common domain, than when placed in separate domains;

Due to the above conditions, one should place intensively communicating objects which jointly implement some functionality to common domain.

Domains provide global isolation of objects within the framework of a distributed system. If the object has several replicas, then in every node its replica resides in the same domain and at the same memory address. Therefore, if two objects are isolated from each other, i.e. reside in different domains, then their replicas will be placed in different domains in all nodes. Like other E1 primitives, domains are distributed objects. A replica of each domain is placed in each node, where there is a replica of at least one object, belonging to this domain.