top - download
⟦7d560fa61⟧ Wang Wps File
Length: 17300 (0x4394)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN63.08«
Derivation
└─⟦003a8b650⟧ Bits:30006009 8" Wang WCS floppy, CR 0044A
└─ ⟦this⟧ »~ORPHAN63.08«
WangText
…1b……00……00……00……00…?…0a……00……00…?…0b…?
?…07…>…0e…>…0f…>…06…>…07…=…0d…=…0e…=…01…=…86…1 …02… …02… …02…
…02…CPS/SDS/001
…02…OKH/810227…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 .....................................
277
5.6.1 Summary of Requirements.............. 277
5.6.1.1 General Description ..............
277
5.6.1.1.1 Process Concept ..............
279
5.6.1.1.2 Security .....................
279
5.6.1.1.3 Process Environment ..........
281
5.6.1.1.4 Intrfaces ................... 281
5.6.1.2 Functions ........................
284
5.6.1.2.1 Directory Functions ..........
284
5.6.1.2.1.1 Access to Objects ........
285
5.6.1.2.2 Security .....................
285
.6.1.2.2.1 Access Authorization ..... 286
5.6.1.2.3 Device Management ............
287
5.6.1.2.3.1 Device Security ..........
289
5.6.1.2.4 Process Management ...........
289
5.6.1.2.4.1 Process Hierarchy ........
90
5.6.1.2.4.2 Process Attributes .......
292
5.6.1.2.4.3 Process Management
Functions ................
292
5.6.1.2.5 Process Scheduling ...........
293
5.6.1.2.5.1 Priorities ...............
293
5.6.1.2.5.2 Time Slicing ............. 294
5.6.1.2.5.3 Process Scheduling
Interfaces ...............
294
5.6.1.2.6 Process Communication ........
294
5.6.1.2.6.1 Synchronization Elements .
294
5.6.1..6.2 Basic Process Communication
Functions ................
295
5.6.1.2.6.3 IO System ................
296
5.6.1.2.7 Page Management ..............
300
5.6.1.2.7.1 Page Manager Concepts ....
301
5.6.1.2.72 Page Manager Functions ... 304
5.6.1.2.7.3 Page Manager Security
Aspects ..................
307
5.6.1.2.8 Timer Management .............
307
5.6.1.3 Kernel Control ...................
308
5.6.1.3.1 Parameter Control ............
308
5.6.1.3.2 Initialization ...............
309
5.6.1.3.3 Error Hndling ............... 309
5.6.1.4 Characteristics ..................
309
5.6.1.4.1 Availability .................
310
5.6.1.4.2 Security .....................
310
5.6.1.5 Design and Construction ..........
310
5.6..6 Documentation ..................... 310
5.6.2 Environment ..........................
310
5.6.2.1 Standard Hardware, Firmware and
Software .........................
310
5.6.2.2 External Interfaces ..............
310
5.6.2.3 Subsystem Interfaces ............. 310…86…1
…02… …02… …02… …02…
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
lvel 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 certin 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 accessble
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 lyers. 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, eachconsisting 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 i shown on
the diagram 5.6.1.1-1.
5.6.1.1-1…86…1 …02… …02… …02… …02…
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 y 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 assoiated 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 memor, 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 atany 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 Trnslation Tables
belonging to the process. They are loaded into the
map module each time the process resumes execution.
(See figure 5.6.1.1.1-1)
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 resourcesare allocated to and exchanged
between processes. So security actually amounts to
controlling the access to system resources, including
information carrying resources, by processes.…86…1
…02… …02… …02… …02…
Fig. 5.6.1.1.1-1
Relations between HW and SW packages…86…1 …02… …02… …02… …02…
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 envionment looks as if
the process is 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
proceses 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 ERNEL.
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. Based upon synchronization elements,
the I/O system implements special tools for data exchange
with SFM and IOC.
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
Contols all disk storage.
c) IOC
Controls all communication lines.
The main interfaces are shown on the diagram overleaf.…86…1
…02… …02… …02… …02…
Figure 5.6.1.1.4-1…01…KERNEL Interfaces…86…1 …02… …02… …02… …02…
1. I/O Activation
2. I/O Completion Notification
3. I/O Instruction
4. Device Interrupt
5. Process creation, deletion, activation, and deactivation
6. Timer Interrupt 7. Send,
Await
and
I/O
System
Functions
8. Page Fault Interrupt
9. Segment creation, deletion, transfer, and mapping
10. Set Time
11. Read Time, Schedule and Cancel Time Signal
12. Time Signal
13. Timer Interrupt
14. Error Report to CallingProcess
15. Error Report to Parent
FIGURE 5.6.1.1.4-1 (CONT.)
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 emory 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 creatin 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 instancs 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 distributin
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 i section 5.6.1.2.4.
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 whch 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 capabilites 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 withsecurity 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 capabilties 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 consisent 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, thes 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 ased 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 entitiesare 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 ofsubjects 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
whih 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 Use
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 inheited
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 withinformation
of its own classification level or lower.
The behaviour of an unstrusted process is unpredictable.
The general security policy can now be stated:
1) Any process is allowed to read information from
objects of security level lower tan 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 o 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 n 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 hanlers 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 ontrol 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 case 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 notifictions
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 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 lgical sub-devices. A disk device is by SFM subdivided
into a number 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 protectd.
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̲
Process mnagement 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 transfrmations 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 tw 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 whi
