top - download
⟦adcf77170⟧ Wang Wps File
Length: 37591 (0x92d7)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »0521A «
Derivation
└─⟦c2ca659c9⟧ Bits:30006002 8" Wang WCS floppy, CR 0037A
└─ ⟦this⟧ »0521A «
WangText
…0d……07……0c……06……0b……0d……0b…
…0b… …0b……86…1
…02…
…02…
…02…
…02…CPS/SDS/001
…02…OKH/810115…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5.6 KERNEL .....................................
5.6.1 Summary of Requirements ..............
5.6.1.1 General Description ..............
5.6.1.1.1 Process Concept ..............
5.6.1.1.2 Security .....................
5.6.1.1.3 Process Environment ..........
5.6.1.1.4 Interfaces ...................
5.6.1.2 Functions ........................
5.6.1.2.1 Directory Functions ..........
5.6.1.2.1.1 Access to Objects ........
5.6.1.2.2 Security .....................
5.6.1.2.2.1 Access Authorization .....
5.6.1.2.3 Device Management ............
5.6.1.2.3.1 Device Security ..........
5.6.1.2.4 Process Management ...........
5.6.1.2.4.1 Process Hierarchy ........
5.6.1.2.4.2 Process Attributes .......
5.6.1.2.4.3 Process Management
Functions ................
5.6.1.2.5 Process Scheduling ...........
5.6.1.2.5.1 Priorities ...............
5.6.1.2.5.2 Time Slicing .............
5.6.1.2.5.3 Process Scheduling
Interfaces ...............
5.6.1.2.6 Process Communication ........
5.6.1.2.6.1 Synchronization Elements .
5.6.1.2.6.2 Process Communication
Functions ................
5.6.1.2.7 Page Management ..............
5.6.1.2.7.1 Page Manager Concepts ....
5.6.1.2.7.2 Page Manager Functions ...
5.6.1.2.7.3 Page Manager Security
Aspects ..................
5.6.1.2.8 Timer Management .............
5.6.1.3 Kernel Control ...................
5.6.1.3.1 Parameter Control ............
5.6.1.3.2 Initialization ...............
5.6.1.3.3 Error Handling ...............
5.6.1.4 Characteristics ..................
5.6.1.4.1 Performance ..................
5.6.1.4.2 Availability .................
5.6.1.4.3 Security .....................
5.6.1.5 Design and Construction ..........
5.6.1.6 Documentation .....................
5.6.2 Environment ..........................
5.6.2.1 Standard Hardware, Firmware and
Software .........................
5.6.2.2 External Interfaces ..............
5.6.2.3 Subsystem Interfaces .............
5.6 K̲E̲R̲N̲E̲L̲
5.6.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.6.1.1 G̲e̲n̲e̲r̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
KERNEL is the interface between CAMPS software and
hardware. The CR80D hardware provides a set of low
level hardware objects, such as CPUs, memory modules,
memory mapping module, I/O busses, I/O devices, and
a set of operations on those objects by means of the
CR80D instruction set.
The main purpose of most pieces of system software
is to hide certain hardware features, replacing them
with a new set of features, which are more suitable
for the application area at hand. This can be viewed
as an abstraction of the actual physical machine into
a virtual machine, which will be the only one accessible
by application software. Actually this abstraction
process is repeated a number of times and gives rise
to several layers of system software. Each layer transforms
the underlying virtual machine into a new one, which
is then provided to upper layers. KERNEL constitutes
the lowest level of system software in this sense.
The next level of abstraction above the KERNEL is constituted
by SFM and IOC respectively:
- SFM transforms each disk device (controller) into
a set of disk units, each consisting of a number
of disk files.
- IOC transforms each line termination device (LTU
or TDX Host IF) into a set of logical communication
lines.
In a rather crude model, the relations between KERNEL,
SFM, IOC and the rest of CAMPS software is shown on
the diagram overleaf.
5.6.1.1.1 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲c̲e̲p̲t̲
The most important new concept introduced by KERNEL
is that of a p̲r̲o̲c̲e̲s̲s̲.
A pr̲o̲c̲e̲s̲s̲ is defined as the transformation of a given
set of data performed by the execution of an associated
program.
A program is defined as a sequence of machine instructions.
The data associated with a process are called the p̲r̲o̲c̲e̲s̲s̲
̲d̲a̲t̲a̲.̲
The instructions for manipulating the process data
are collected in the associated program. The available
instructions are the CR80D user instructions (non privileged
hardware instructions) together with the system commands
provided by KER, SFM and IOC.
Program and process data reside in completely separate
parts of memory, and the same program may well be executed
by several processes.
Execution of processes may be truly parallel if the
machine contains more than one CPU. Otherwise execution
is pseudo-parallel, meaning that execution of the running
process may at any place in the program be interrupted
and another process may then resume execution from
a point in the program where it was previously interrupted.
Process data and program associated with a given process
are specified by two sets of Memory Translation Tables
belonging to the process. They are loaded into the
map module each time the process resumes execution.
5.6.1.1.2 S̲e̲c̲u̲r̲i̲t̲y̲
Security is closely related to the process concept
in that all system resources are allocated to and exchanged
between processes. So security actually amounts to
controlling the access to system resources, including
information carrying resources, by processes.
KERNEL implements the basic tools for protection of
resources as described in more detail in section 5.6.1.2.2.
5.6.1.1.3 P̲r̲o̲c̲e̲s̲s̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
From "within" a process the environment looks as if
the process executed within a monoprogrammed machine
with a CPU, a memory and a set of peripheral files
and/or lines. The process exchanges data with the environmental
files and lines. It does not need to recognize other
processes except that they may cause a slow down of
the CPU.
Processes may, however, cooperate in performing a specific
task. They do so by exchanging data and synchronizing
their activities. This is done by the process communication
tools provided by KERNEL.
Synchronization and data exchange between processes
is done by means of s̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲ ̲as described
in 5.6.1.2.6.
5.6.1.1.4 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
KERNEL interfaces to hardware and to all other CAMPS
software packages. Three packages are of special interest:
a) SSC
Takes all high level decisions concerning resource
allocation and resource sharing.
b) SFM
Controls all disk storage.
c) IOC
Controls all communication lines.
The main interfaces are shown on the diagram overleaf.
Figure 5.6.1.1-1…01…Relations between HW and SW packages
Figure 5.6.1.1.4-1…01…KERNEL Interfaces
5.6.1.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.6.1.2.1 D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Directory Functions are KERNEL tools for resource allocation.
Examples of system resources, from here on called o̲b̲j̲e̲c̲t̲s̲,
are memory segments, processes, CPU's and synchronization
elements. Objects are dynamically created and removed
by processes, and exchanged between processes.
KERNEL controls, that whenever a process has obtained
access to an object, either by creating it or by obtaining
it from another process, the process can not access
or manipulate the object beyond a limit defined at
creation time or time of granting the access. This
limit is called the capabilities of the process with
respect to the object. For each object a process can
only grant a subset of the capabilities that it has
got itself.
The ability of a process to create new objects is further
limited by a socalled claim on each type of resource.
A process can never create more instances of a specific
object type than defined by its claim for that object
type.
Even if KERNEL contains tools for limiting access to
existing objects and limits ability to create new objects,
it does not take any high level decisions about distribution
of available resources between processes and the dynamic
behaviour of the system in terms of creation and removal
of objects.
These decisions must be taken by special processes
playing the role of o̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲s̲y̲s̲t̲e̲m̲s̲.̲ This is further
described in section 5.6.1.2.5.
In CAMPS, the operating system functions are performed
by SSC, having responsibility for all resource management.
5.6.1.2.1.1 A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲O̲b̲j̲e̲c̲t̲s̲
There are three ways for a process to gain access to
an object:
a) C̲r̲e̲a̲t̲i̲o̲n̲
The process which originally created the object
has capabilities which it specified itself at creation
time. At that time Directory Functions checked
if the specified capabilities were compatible with
security rules.
b) I̲n̲h̲e̲r̲i̲t̲a̲n̲c̲e̲
A child may at creation time inherit specified
objects with specified capabilities from the parent.
The capabilities versus a given object can only
be a subset of those possessed by the parent. The
capabilities of the child can never be changed.
Directory functions check at creation time if the
capabilities are consistent with security rules.
c) C̲a̲t̲a̲l̲o̲g̲u̲i̲n̲g̲
Directory functions has a directory, where objects
may be catalogued. Each catalogue entry consists
of an object indentifier and an access control
list. Each entry of the access control list specifies
the capabilities of a user group to the object.
When a process wants access to a particular object,
it calls the directory function L̲o̲o̲k̲u̲p̲ ̲O̲b̲j̲e̲c̲t̲,̲
which then checks if the user group of the process
has any capabilities to the object and if the access
is consistent with security rules.
5.6.1.2.2 S̲e̲c̲u̲r̲i̲t̲y̲
KERNEL contains tools which may be used by SSC to enforce
very rigid limitations upon the information exchange
between processes, and access to objects by processes.
As described in section 4.8, these tools are used as
the second level in a two level checking mechanism.
5.6.1.2.2.1 A̲c̲c̲e̲s̲s̲ ̲A̲u̲t̲h̲o̲r̲i̲z̲a̲t̲i̲o̲n̲
Authorization of access to an object is based on
- A general security policy, and
- A discretionary access checking
The security policy is based on a multilevel - multicompartment
security system.
Objects are associated with a security classification
level for each compartment and subjects (processes)
are associated with a security clearance level for
each compartment. Both entities are described in a
common type:
- The security profile
Discretionary access checking is based on
- Identification of access classes of subjects (processes),
and
- Statements of access capabilities for explicitly
enumerated access classes of subjects vis a vis
a given object.
The identification of an access class of subjects (processes)
is based on a User Group Identification (UGI) which
is common to all subjects in that class.
Access rights are stated in an access control list
which is associated with each catalogued object. The
access control list is a list of paired UGIs and stated
access capabilities.
Certain UGIs are reserved for special use:
- System User
Identifies a subject with all access rights
- Public User
Identifies any subject which is otherwise not found
in an access control list
The general access authorization mechanism described
above is used whenever catalogued objects are accessed.
Access to an object is authorized if the following
conditions both are fulfilled:
a) The access requested is allowed according to the
access control list, or the object was inherited
from parent or created by the process itself
b) The security profile of the calling process matches
that of the object.
The security profile check uses the concept of a trusted
process:
A trusted process is assumed to work correctly with
information of its own classification level or lower.
The behaviour of an unstrusted process is unpredictably.
The general security policy can now be stated:
1) Any process is allowed to read information from
objects of security level lower than or equal to
its own level (within each compartment).
2) Any process is allowed to write information to
objects of security level higher than or equal
to its own level.
3) A trusted process is further allowed to write information
to objects of security level lower than its own
level.
These rules imply that the flow of information is generally
from lower to the same or higher security levels. Only
trusted processes can reverse this direction.
All security control information is kept in protected
memory which is only accessible in system mode.
5.6.1.2.3 D̲e̲v̲i̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Processes may not execute I/O instructions directly.
Neither are they directly activated by device interrupts.
Both functions are carried out by device handlers within
the KERNEL module DEVICE MANAGEMENT.
A device is a system resource, which by some operating
system must be granted to the process with the job
of mediating access to the device. In CAMPS, SFM and
IOC will be granted control of disk and line devices
respectively.
The external function of Device Manager is:
1) IO Activation
A procedure called by SFM or IOC, requesting a
single operation or a sequence of operation to
be performed on the device. Special cases are activation
of specific built-in test functions of the device.
2) IO Completion Notification
A notification to SFM or IOC that a requested IO
operation has been completed, either normally or
abnormally (with one or more errors). IO notifications
are passed via synchronization elements specified
by the controlling process.
The interfaces between DEVICE MANAGER and hardware
are:
3) IO Instruction
One of the CR80D instruction, if the device is
located in the processor crate, and a DMA transferred
IO command, if the device is located in an IO crate.
4) Interrupt
Signal from a device that an IO operation has been
completed fully or partially
5.6.1.2.3.1 D̲e̲v̲i̲c̲e̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
As KERNEL objects, devices are protected by the security
mechanisms described in 5.6.1.2.2.
Each physical device, however, consists of a number
of logical sub-devices. A disk device is by SFM subdivided
into a nubmer of files and items, each of which should
be protected individually. A line terminating device
similarly consists of a number of individual lines,
each of which must also be protected.
So in addition to the device protection enforced by
KERNEL, SFM and IOC respectively will enforce a protection
on a subdevice level.
The security rules described in 5.6.1.2.2 are the same,
however.
5.6.1.2.4 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
In general process management is concerned with implementation
of software processes as a data type and with implementation
of the functions available for operating on processes.
As described in 5.6.1.1.1, a process may be defined
as an incarnation of the data transformations obtained
by execution of a program in a given context. A context
is taken to mean a set of CPU registers (CPU resident
or saved) including the program and data base registers
PROG and BASE and the two Translation Table Registers
and the two Translation Tables.
A process is represented by a process descriptor (procdes)
and it is identified by a process identifier (procid).
A process may thus be referred to without knowing in
which memory locations it resides. The only instant
at which such knowledge needs to be specified is when
a process is created.
5.6.1.2.4.1 P̲r̲o̲c̲e̲s̲s̲ ̲H̲i̲e̲r̲a̲r̲c̲h̲y̲
Processes are organized with a hierarchical principle
as shown in figure 5.6.1.2.4.1-1.
A process may create subordinate processes. These are
called child processes in relation to the former process,
which in turn is called their parent process.
The purpose of having a process hierarchy is to enable
support of multiple operating systems as well as it
enables an O.S. to receive control when one of its
child processes terminates.
In CAMPS SSC will be the parent of all application
processes.
At system start SSC will own all system resources.
It will then as part of CAMPS initialization and dynamically
during CAMPS operation create child processes and furnish
them with access rights to system resources and with
security profile to be compared with object profile
whenever access is attempted.
Figure 5.6.1.2.4.1-1…01…Process Hierarchy
5.6.1.2.4.2 P̲r̲o̲c̲e̲s̲s̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
At process creation time a process is furnished with
a set of attributes used by KERNEL to control the behavior
of the process. Among the attributes are:
a) Process Identification
A unique identification to be used when subsequently
referring to the process
b) User Group Identifier
To be used in security
c) Security Profile
d) Priority
Scheduling priority of the process, refer to section
5.6.1.2.5
e) CPU Pool
The pool of CPUs which may execute the process.
Refer to section 5.6.1.2.5.
f) Claims
The number of objects within each object type that
the process may create. E.g. memory segments, child
processes, synchronization elements, etc.
g) CPU Time
The amount of CPU time that the process is allowed
to use.
5.6.1.2.4.3 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Refer to (5) on figure 5.6.1.1.4-1.
a) Create Process
Creates a new process with attributes specified
as a call parameter
The following functions may only be called by the parent
of the process.
b) Delete Process
c) Activate Process
Makes the process active, so that it will compete
with other processes for CPU time.
d) Deactivate Process
Passivates a process so that it may not execute.
e) Change Process Attributes
Changes certain process attributes such as priority.
5.6.1.2.5 P̲r̲o̲c̲e̲s̲s̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲
Once a process is created, it is confined to be executed
by the CPUs of a specific pool of CPUs. The allocation
of CPUs from a pool to the processes which are competing
for these CPUs is based on a priority scheme.
5.6.1.2.5.1 P̲r̲i̲o̲r̲i̲t̲i̲e̲s̲
There are two kinds of priorities associated with a
process:
a) T̲h̲e̲ ̲P̲h̲y̲s̲i̲c̲a̲l̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲ which is used by the CR80D
hardware to determine whether a device may interrupt
a given process. The physical priority scheme employs
16 levels. (0-15) where level 15 is the highest
level.
b) T̲h̲e̲ ̲L̲o̲g̲i̲c̲a̲l̲ ̲P̲r̲i̲o̲r̲i̲t̲y̲ which is used by the CPU allocation
algorithm for selection of the next process to
execute on a particular CPU. The logical priority
scheme may employ up to 16 levels (0-15). The maximum
number of levels in use may be defined at system
generation time together with the correspondence
between logical and physical priorities.
5.6.1.2.5.2 T̲i̲m̲e̲ ̲S̲l̲i̲c̲i̲n̲g̲
The CPU resources are multiplexed between the processes
on a particular logical priority level by a time slicing
mechanism. Each process will not have a CPU allocated
for more than the size of the time slice before the
next process at the same level (if any) is offered
the opportunity to execute.
The size of a time slice is a function of the logical
priority level. This function is defined at system
generation time.
5.6.1.2.5.3 P̲r̲o̲c̲e̲s̲s̲ ̲S̲c̲h̲e̲d̲u̲l̲i̲n̲g̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Process scheduling is directly affected by hardware
interrupts.
Refer to figure 5.6.1.1.4-1 (6).
5.6.1.2.6 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The KERNEL process communication provides functions
which enables the exchange of information between processes.
The exchange of information is realized by means of
synchronization elements and functions operating on
these elements.
5.6.1.2.6.1 S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
A synchronization element (synchel) consists of a descriptor,
a process list and an information list. It is identified
by a unique synchel identifier (SID).
The process list holds processes awaiting information
at the synchel. The information list holds information
elements which have not been awaited by processes.
At any time either process list, information list or
both are empty.
As KERNEL objects, synch elements have security profile
and access control list associated with them.
At system generation time the maximum size of an information
element is defined.
The information exchange between processes may require
an information element less than maximum size, but
it is an error condition if a process tries to use
a SEND function with an information element size greater
than maximum.
Space for the synchronization element descriptors and
a pool of information elements is allocated at system
generation time.
5.6.1.2.6.2 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Refer to figure 5.6.1.1.4-1 (7).
a) S̲e̲n̲d̲
This function sends an information element "info"
to the synchronization element identified by SID.
If a process is waiting at the sync. element identified
by SID, then the process is removed from the process
list and the 'info' is delivered to the process,
which then is conditionally started.
If no process is waiting at the sync. element then
the 'info' is stored at the information list.
In any case the calling process continues immediately
after the SEND function.
b) A̲w̲a̲i̲t̲
This function is used by a process which awaits
information to be available at one or more synchronization
elements.
When the function call is issued it is examined
whether the information is available or not. If
not, then the process is blocked until the information
becomes available or a time out occurs, otherwise,
the information is delivered to the process. The
delivery of information depends on the strategy
posed by the first parameter:
"one of": One and only one "info" element
shall be returned. The "info" to
be returned shall be selected at
a priority basis, such that the
highest priority is assigned to
the leftmost synch. element in the
parameter list.
"all of": All "info" elements shall be returned.
For the sake of clarity it is asumed that the parameter
list has only one specification of a synchronization
element.
If the information list is empty then the identification
of the calling process (PID) is inserted in the process
list and the process is stopped, otherwise an "info"
element is removed from the information list and delivered
to the process which in this case continues immediately.
The await call includes a time-out parameter specifying
the maximum time period allowed to wait for "info"
elements to become available.
5.6.1.2.7 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Page Manager, PM, provides functions for administration
of main memory and for transfer of parts of main memory
to and from backing storage. It is mainly concerned
with allocation of memory resources and access rights
to processes. PM does not contain strategies for memory
allocation, but only provides functions to SSC for
that purpose.
5.6.1.2.7.1 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲r̲ ̲C̲o̲n̲c̲e̲p̲t̲s̲
a) P̲a̲g̲e̲
A contiguous block of 1024 machine words
b) P̲a̲g̲e̲ ̲F̲r̲a̲m̲e̲
A physical storage area capable of holding a page.
c) T̲r̲a̲n̲s̲l̲a̲t̲i̲o̲n̲ ̲T̲a̲b̲l̲e̲
A process can at a given time address up to 64
pages of program and up to 64 pages of data. The
program and data parts are each seen by the process
as a contigous block of words with logical addresses
from 0 to 64 K-1.
A translation table has 64 entries. Each entry
converts a logical page frame address 0-63 into
a physical main memory page frame address and an
access right to the page.
A process has two translation tables, TTs, one
for the program and one for the process data. Program
and data pages may then be scattered over the physical
memory. Each time a process is executed by a CPU,
its TTs are loaded into the Memory Map Module.
This module will convert all memory references
and check access rights at each reference.
d) A̲c̲c̲e̲s̲s̲ ̲R̲i̲g̲h̲t̲s̲ ̲t̲o̲ ̲P̲a̲g̲e̲s̲
The access rights of a process to a page may assume
the following values:
- read access
- read and write access
- no access
- absent
Except for the "absent", access rights only apply
in user mode. In system mode there is read access
to all program pages and read/write access to all
data pages.
The "absent" attribute corresponds to a hole in
the locical data space, caused for example by a
not loaded page. A reference to an absent page
causes a page fault.
e) W̲o̲r̲k̲i̲n̲g̲ ̲S̲e̲t̲
The working set of a process is defined as a set
of main memory page frames currently in use by
that process. For each process a minimum number
of main memory page frames are guaranteed. However,
the working set may be larger (if memory is available).
The minimum working set for a process is defined
by its parent.
f) V̲i̲r̲t̲u̲a̲l̲ ̲M̲e̲m̲o̲r̲y̲
A process may want to be able to refer to a memory
larger than its logical address space (2 x 64K
words).
In order to achieve this, an abstraction called
a Virtual Memory is introduced.
A process may possess a very large lump of virtual
memory, say 2M words. However, because of the limitation
in addressing capability it will only be able to
see (address) parts of its virtual memory at any
one time. The contents of those parts which are
directly addressable must reside somewhere in the
main memory and the corresponding page frames must
be mapped into its translation table. The contents
of the other parts of its virtual memory may reside
in main memory or on backing memory.
g) S̲e̲g̲m̲e̲n̲t̲s̲
A segment is defined as a portion of the virtual
memory. A segment may consist of one or more virtual
page frames, and is the fines granularity of the
virtual memory known out side of the PM.
Each segment has a unique segment identifier, SID.
Segments can be created (allocated) and deleted
(released). When a process creates a segment, it
becomes the owner of that segment. It may allow
other processes to share the segment by explicitly
identifying the processes and their capabilities
to the segment.
When a process wishes to use a segment it must
either create a segment or claim the use of a segment
to which another process has granted it access.
A segment used by more than one process is called
a shared segment.
When a process no longer wants to use a segment
it may delete the segment. If the segment was shared,
the number of users is decremented. When the last
user deletes the segment, it becomes released and
ceases to exist as a segment, and its virtual page
frames are released.
A segment has an associated security profile defined
at creation time.
h) A̲c̲c̲e̲s̲s̲ ̲R̲i̲g̲h̲t̲s̲ ̲t̲o̲ ̲S̲e̲g̲m̲e̲n̲t̲s̲
The capabilities of a process to a segment may
assume the following values:
- execute access, meaning that the segment may
be used for program. The other access rights
all apply to data segments only.
- read access
- read and write access
- no access
The capabilities of other processes are defined
by creator either by catalogueing or by inheritance.
Whenever a process creates a segment or requests
access to a segment created by any other process,
a security check is performed according to the
rules described in 5.6.1.2.2. Information flow
between processes via shared segments is thus security
checked.
i) D̲e̲m̲a̲n̲d̲ ̲P̲a̲g̲i̲n̲g̲
Demand Paging is invoked when a process encounters
a page fault in the logical address space corresponding
to a mapped-in segment. This may occur if the total
number of pages in the segments requested to be
in main memory exceeds the size of the process
main memory pool.
(Page faults may also occur if a process addresses
logical pages which do not correspond to a segment
page. This is considered a run time fault).
When invoked, the demand paging mechanism will
select a free main memory page frame from the process
pool if this is possible. Else it will select a
main memory page frame used by the process, save
its contents on backing memory and transfer the
needed segment page into main memory. The Translation
Table is updated accordingly.
The algorithm to be used for selection of a main
memory page frame is to be specified. It should
be noted that no H/W support for such an algorithm
exists.
5.6.1.2.7.2 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Refer to figure 5.6.1.1.4-1 (8) for page fault and
(9) for other functions.
a) C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲e̲g̲m̲e̲n̲t̲s̲
1) C̲r̲e̲a̲t̲e̲ ̲S̲e̲g̲m̲e̲n̲t̲
Creates a segment with the specified number
of pages and allocates room for it on backing
storage.
Security profile of segment and capabilities
of the caller are specified.
2) U̲p̲d̲a̲t̲e̲ ̲A̲c̲c̲e̲s̲s̲
Gives specified capabilities to a specified
user group.
3) L̲o̲o̲k̲u̲p̲ ̲S̲e̲g̲m̲e̲n̲t̲
Requests that specified segment, which was
catalogued by another process, becomes accessible
for the calling process.
4) D̲e̲l̲e̲t̲e̲ ̲S̲e̲g̲m̲e̲n̲t̲
The calling process does not want to use the
segment SID any more. The number of users is
decremented by one. If no process uses the
segment any more, its virtual page frames are
released, the backing memory page frames used
by the segment are released, and if the segment
was in main memory, the page frames which contained
the segment are deallocated from the working
set of the process.
b) S̲e̲g̲m̲e̲n̲t̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) G̲e̲t̲ ̲S̲e̲g̲m̲e̲n̲t̲
Requests that the specified segment be transferred
from backing to main memory, thus ready to
be mapped into the logical address space of
the caller. The segment may already be in memory
because it is in use by another process.
2) P̲u̲t̲ ̲S̲e̲g̲m̲e̲n̲t̲
The process expresses its intention not to
use the segment any more. If the segment occupies
main memory page frames in the working set
of the local process, these pages are transferred
to backing memory and released. If the segment
was used by other processes and parts of it
contained in the working set of other process(es),
these parts are not transferred to backing
storage, but the segment is marked for saving.
3) F̲r̲e̲e̲ ̲S̲e̲g̲m̲e̲n̲t̲
This function is similar to put with the only difference
that the process does not want the segment transferred
to backing memory. However, if the segment has
been marked for saving by another process, those
pages of the segment which are contained in main
memory page frames of the working set of the calling
process are transferred to backing memory before
the page frames are released.
c) S̲e̲g̲m̲e̲n̲t̲ ̲M̲a̲p̲p̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) M̲a̲p̲-̲i̲n̲ ̲S̲e̲g̲m̲e̲n̲t̲
The calling processing requests the segment
to become addressable as logical page frames
adr, adr+1,......, adr+N-1.
It is checked that these logical page frames
are free. Those pages of the segment which
are in main memory are included in the MAP
Translation Table as requested.
2) M̲a̲p̲-̲o̲u̲t̲ ̲S̲e̲g̲m̲e̲n̲t̲
The segment which was addressable via the Translation
Table partly or in total is made unaddressable.
I.e. the logical page frames addr,...., addr+N-1
are released and mapped into the nil physical
page frame.
d) H̲a̲r̲d̲w̲a̲r̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
1) P̲a̲g̲e̲ ̲F̲a̲u̲l̲t̲
Indicates that the executing process has referenced
an absent page. The actions by page manager
are described in 5.6.1.2.7.1(i).
5.6.1.2.7.3 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲s̲p̲e̲c̲t̲s̲
Page Management administrates capabilities of processes
to data and program segments. It thus contains the
basic mechanisms for security and protection, because
it can specify how processes can be protected against
each other and how the KERNEL data can be protected
against access in user mode.
Page Management is responsible for purging segments
when deleted, if their classification level is above
a specified limit. It must also assure that segments
above a specified level will never be transferred to
backing memory.
5.6.1.2.8 T̲i̲m̲e̲r̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
KERNEL includes a Real Time Clock Module, RTCM, using
the 48 bit real time clock facility of the MEMORY MAP
module, which counts the time in milliseconds and is
able to produce an alarm at a specified time.
RTCM includes the following functions, where numbers
in parenthesis refer to figure 5.6.1.1.4-1.
a) S̲e̲t̲ ̲t̲i̲m̲e̲ ̲(̲1̲0̲)̲
Sets the value of the 48 bits clock. This function
may only be called by SSC.
b) R̲e̲a̲d̲ ̲t̲i̲m̲e̲ ̲(̲1̲1̲)̲
Reads the current value of the clock. The delivered
value can be in the 48 bits format or it can be
converted to year, month, day, minute, second,
millisecond in integer or ASCII values.
c) S̲c̲h̲e̲d̲u̲l̲e̲ ̲T̲i̲m̲e̲ ̲S̲i̲g̲n̲a̲l̲ ̲(̲1̲1̲ ̲-̲ ̲1̲2̲)̲
Requests RTCM to signal a specified synchronization
element at a specified time.
The time may be specified as:
- A certain clock time (and date).
- After a certain period.
- At regular intervals.
d) C̲a̲n̲c̲e̲l̲ ̲T̲i̲m̲e̲ ̲S̲i̲g̲n̲a̲l̲ ̲(̲1̲1̲)̲
Cancels a previously scheduled time signal.
RTCM is activated by an interrupt when the MAP module
timer reaches a specified value set by RTCM. Refer
figure 5.6.1.1.4-1 (13).
5.6.1.3 K̲E̲R̲N̲E̲L̲ ̲C̲o̲n̲t̲r̲o̲l̲
5.6.1.3.1 P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
There are three main groups of parameters which control
KERNEL operation:
- Claims.
- Security profiles and access rights.
- Error Handling Parameters (see 5.6.1.3.3).
a) C̲l̲a̲i̲m̲s̲
Directory functions contain an accounting function,
keeping track of the use of system resources by
processes. Each process has a socalled c̲l̲a̲i̲m̲ on
each resource type. The claim is the maximum number
of objects of that type which may be allocated
by the process. At child creation time the parent
may give its child part of its own claims, thereby
reducing its claim with the amount offered. The
total amount of each resource type is defined at
system generation time.
b) S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲s̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲R̲i̲g̲h̲t̲s̲
All objects, including processes, have an associated
security profile, set at object creation time.
Whenever a process attempts access to an object,
it is checked if the access is consistent with
security rules as stated in 5.6.1.2.2.
Other parameters such as security level for purging
of memory segments and inhibiting of transfer to
backing storage are defined at system generation
time.
5.6.1.3.2 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The KERNEL data structures are initialized as part
of boot load procedure.
5.6.1.3.3 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
KERNEL detects the following classes of errors:
- Device errors detected by device handlers.
- Memory protection violations detected by MAP module.
- Security violations detected by directory functions.
- Parameter errors in system calls.
Each error has an associated error code and error type.
The error type is used to determine the process responsible
for error handling. At process creation time the parent
process specifies the error types which shall be handled
by the child itself. The remainding ones will be handled
by the parent.
When an error occurs, it is determined by means of
error type if the error should be reported back to
the executing process. Refer fig. 5.6.1.1.4-1 (14).
If not, it is sent to the parent in a specified synch.
element. Refer fig. 5.6.1.1.4-1 (15).
Certain errors, such as memory protection violation
can never be handled by the child.
5.6.1.4 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
5.6.1.4.1 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
TBD.
5.6.1.4.2 A̲v̲a̲i̲l̲a̲b̲i̲l̲i̲t̲y̲
Not applicable.
5.6.1.4.3 S̲e̲c̲u̲r̲i̲t̲y̲
All KERNEL data are protected so that they can only
be accessed in system mode.
5.6.1.5 D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Refer to section 2.5.
5.6.1.6 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Refer to section 2.6.
5.6.2 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.6.2.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲,̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
KERNEL executes completely within one PU.
5.6.2.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
KERNEL contains the device handlers interfacing to
Disk Controller, LTU's and TDX host interfaces. KERNEL
controls the Memory Map Module by loading translation
tables and set interrupt priorities.
5.6.2.3 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
KERNEL interfaces to all software packages.
