Stella Reliability Concepts - Security

 

Operating system security

Security is one of the areas in which Stella differs most from the classical approach to system security as embodied in the POSIX standards. POSIX recognises two levels of security. The basic security level is the "original" virtual machine concept of 1960s multi-user systems where each process / task group / actor is totally isolated from all other processes / task groups / actors. Allocation of resources and communication between tasks at this level is intrinsically inefficient. On a different level, that of threads within a process / task group / actor, there is no system security at all. Ironically, this total lack of security does not greatly improve the efficiency at this level, as the tasks themselves have to provide their own contention mechanisms for shared resources. This is even less efficient than having the operating system do it for you.

The virtual machine concept, which is designed to prevent programs from accessing anything outside their own virtual machine, is very far removed from the Stella ideal of providing mechanisms for simple, safe and efficient communications between software. The virtual machine concept of system security was originally designed for multi-user systems where the most important function of the operating system was to protect users from hostile intrusions by other users. Not only has thirty years of experience has shown that this protection is more notional than real, for most modern systems this superficial type of protection is no longer of any utility.

Embedded systems do not have any users at all and so there is no possibility of intrusion. Workstations are increasingly "personal" computers and so there is only ever one user. Database servers do not, in principle, have any users and so there should be no possibility of intrusion. The weak point in the security of modern networks is not within each computer, but in the links between the computers. In some ways the virtual machine concept is more dangerous than no security at all: its hostility to applications programs gives an illusion of security and diverts attention from the real weaknesses of the system.

The basic Stella security concepts concern the interactions between tasks accessing a common address space (whether the tasks are on a single processor or multiple processors sharing memory). Where tasks do not share an address space (tasks on separate machines co-operating via a network, for example) addressing faults or deliberate attempts by one task to access outside its own resources cannot affect the other tasks.

There are three main sources of problems that can affect the security of the system.

  1. Competition for shared resources.
  2. Programming errors (accidental or deliberate!).
  3. System reconfiguration.

Competition for shared resources is a possibility in any system where there is more than one task. This is, therefore, a fairly general problem. The operating system's role in handling the problems arising from programming errors or reconfiguration, however, depends on the domain.

Competition for shared resources

Competition for shared resources - communications

The Stella approach to competition for communications data structures is to eliminate the problems at source. The most common occurrence (and most critical) of potential problems is in the communications between asynchronous tasks responding to interrupts and other asynchronous tasks or scheduled tasks. The most common operations are passing messages (or data) and releasing or activating tasks.

In Stella, these operations are performed by proprietary INTSAFE (intrinsically safe) asynchronous mechanisms which cannot give rise to any problems of competition. The data structures and access code are designed for asynchronous access by two or more tasks (on the same or different processors) without requiring any intrusive protection mechanisms.

This asynchronous approach to handling asynchronous communications is not only natural and efficient, but also it eliminates any possibility of system failure due to deadlocks.

Naturally, as the Stella design principles are, above all, pragmatic, INTSAFE mechanisms are not used for all intertask competition. Some versions of Stella have an operating system call mechanism that disables interrupts for a few instructions. In theory, this could be replaced by an INTSAFE mechanism but this would, in practice, degrade the overall interrupt response.

Competition for shared resources - resource allocation.

The Stella approach to protecting resource management data structures (for example, memory manager data structures) is also highly pragmatic. The fundamental mechanism is the atomic operation, which, although it is safe, simple and efficient, may lead to response delays. Stella provides a variety of solutions to these response problems.

The simplest solution is to restrict resource allocation to low priority tasks: higher priority tasks are not affected by the lower priority atomic operations but cannot allocate resources themselves. Tasks are thus divided into two groups: asynchronous tasks (usually all interrupt servers) and scheduled tasks (usually all applications programs). This approach provides the best compromise between simplicity, response and efficiency for most "real world" systems.

An intermediate solution provided by Stella is to maintain the division into scheduled and asynchronous tasks, but to guarantee that the applications program scheduler is never disabled for more than a pre-specified time. All operations at the operating system level (including the scheduler itself) which execute for more than the specified time are pre_emptible. The internal limit on the size of atomic operations is pre-set to 25 "instructions": this degrades the overall system efficiency by about 10%.

Stella also provides a rather academic solution that removes the distinction between interrupt servers and other tasks. This allows interrupt servers to access the whole range of operating system facilities. The penalty is that response to the first interrupt server of a burst may be delayed by up to 25 "instructions". Although this is better than most "state of the art" real-time systems, it represents a major degradation in the performance of a Stella system.

Competition for shared resources - applications programs

Applications programs can use the same mechanisms that Stella uses internally. In addition, Stella provides a special DYNEX mechanism for use with real-time applications that have been designed to used mutual exclusion for resource protection. Using a DYNEX mechanism is very similar to using a semaphore or monitor. It is, however, guaranteed to be more efficient than using a semaphore or monitor, guaranteed to provide consistent execution times and guaranteed to be immune from deadlocks, accumulation or cascades.

Stella also provides direct support for transactions. This eliminates one of the major requirements for mutual exclusion (file locks) in applications programs.

Protection against programming errors

Stella is designed to adapt to a wide variety of hardware environments. There are three ways in which programming errors can be intercepted by the operating system.
  1. Using hardware memory protection.
  2. Checking the parameters of all calls into the operating system.
  3. Detect (but not intercept) overwrites of the operating system data structures by providing operating system structure integrity checks. These checks are either invoked when the operating system accesses these structures, or invoked regularly by a timed task.

All these measures cost time and some depend on the provision of specific hardware.

Protection against programming errors - memory protection

Stella memory management is designed to support a wide range of memory protection levels depending on the hardware available and the memory manager used. The memory protection applies to tasks executing in application mode.

Protection against programming errors - shared memory

There is very little the operating system can do to protect against errors in handling shared memory. It can, however, provide facilities that make programming errors much less likely (prevention is better than cure).

Protection against programming errors - operating system calls

There are three common types of programming errors on making an operating system call.
  1. Incorrect operation. The operation requested is either not defined, or is invalid for the entity to which the call applies.
  2. Incorrect entity. The entity to which the operation applies is either not defined, does not exist or is not the correct type for the operation.
  3. Incorrect parameters. The parameters for the call are incorrect (for example, allocate a negative amount of memory.

The operating system cannot guarantee that the call is correct. For example, it cannot determine whether a memory allocation request specifies the "correct" amount of memory. The operating system can, however, ensure that erroneous calls do not crash the system.

Stella provides 4 levels of operating system call protection.
Reduced There are no checks on allocation sizes, priorities, etc., but only valid operations are performed.
Normal Negative allocations and other gross errors are rejected.
High The pointer and data structure checks are more rigorous.
Paranoid   There are operating system data structure integrity checks on every operating system call - this is normally only used for testing.

In addition, the operating system data structure integrity checks used by paranoid operating system calls are available as direct calls which may, therefore, be used from a periodic scheduled task (to check the integrity once a second, for example).

System reconfiguration

System reconfiguration is handled at a very low level in Stella. In most systems, the only system reconfiguration likely to occur is the creation and removal of application tasks and the creation and removal of IO channels. Stella is rather more general. Jobs (application tasks) and IO channels are just two forms of entity. Some entities are used to act as local data storage and links between other entities (jobs, IO channels, shared resource managers, event handlers, etc.). Other entities may be linked into the operating system (device drivers, IO protocols, utility software, etc.). Any entity can be added or removed at any time.

Some operating systems identify entities, such as tasks or IO channels, by an index into a table or by the address of the entity. This provides very little protection against removal of an entity. A task holding the table index or address of the entity may then try to access an entity that no longer exists. Some operating systems reduce the risks by using a compound ID incorporating a table index and a check key or tag. This is slightly better.

Entities in Stella are, however, identified by an entity identification structure. This structure (typically 16 bytes) provides a much higher level of protection not only against unexpected removal of entities, but also against programming errors. It also has the merit of being more efficient than a compound ID. An entity identification structure is only a unique identifier for entities in the same memory space (the same hardware). Special entity identification structures are used to keep a record of remote entities (those on other computers).

Stella allows tasks to access other entities directly without passing through the operating system. This is a highly efficient approach that is frequently used illicitly by programs executing under other operating systems where it causes serious problems when an entity is removed.

Stella, however, not only provides a clean mechanism for locating entities, it also provides protection against spurious memory accesses resulting from the unexpected removal of an entity. The operating system call to locate an entity registers the use of that entity by the "user". If an entity is "in use" when it is removed, then the entity becomes unavailable for new "users" but the remove operation does not take effect until last of the "users" is removed or releases the entity.  

  Back to table of contents.


Copyright (c) 1997 Tony Tebby.