top - download
⟦6e20a9e15⟧ Wang Wps File
Length: 10522 (0x291a)
Types: Wang Wps File
Notes: CPS/TCN/075
Names: »4407A «
Derivation
└─⟦fa2167417⟧ Bits:30006184 8" Wang WCS floppy, CR 0396A
└─ ⟦this⟧ »4407A «
WangText
…02…CPS/TCN/075
…02…OKH/831209…02……02…#
iAPX 286 SECURITY EVALUATION
…02……02…CAMPS
1 PURPOSE ........................................
3
2 REFERENCES .....................................
3
3 CONCLUSION .....................................
3
4 ADVANTAGES .....................................
4
4.1 EXECUTION LEVEL PROTECTION .................
4
4.2 SEGMENTED MEMORY ARCHITECTURE ..............
4
4.3 SYSTEM CALL VIA CAPABILITIES ...............
5
4.4 PROCESS CONCEPT ............................
5
4.5 RESOURCE MANAGEMENT ........................
6
4.6 EXECUTION SPEED ............................
6
4.7 COMPATIBILITY ..............................
6
5 DISADVANTAGES ..................................
7
5.1 I/O ARCHITECTURE ...........................
7
5.2 INTEGRATED MEMORY MAP ......................
7
5.3 ADDRESS SPACE ..............................
8
1̲ ̲ ̲P̲U̲R̲P̲O̲S̲E̲
The purpose of this document is to give an evaluation
of the new iAPX 286 processor from INTEL. The main
criteria for the evaluation are:
- Protection Features
- Support functions for efficient operating system
development.
These are the main criteria for the suitability of
a processor as a basis for implementation of secure
systems which perform reasonably.
Other criteria such as availability of peripherals
or standard software have not been considered.
My main conclusion is summarized in section 3, while
major advantages and disadvantages are described in
section 4 and 5.
2̲ ̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
(1) i APX 286 Hardware Reference Manual
(2) iAPX 286 Programmer's Reference Manual
(3) iAPX 286 Operating System Writers Guide.
3̲ ̲ ̲C̲O̲N̲C̲L̲U̲S̲I̲O̲N̲
The iAPX 286 seems to be the most promising microprocessor
at this time for development of secure systems. It
has a memory protection mechanism which is particularly
suited for the purpose, and has extensive support for
process management and for a modular operating system
featuring mutual protection between modules.
The execution speed is about 3-4 times that of CR80
D, and it supports a physical memory address space
of 16 M bytes.
The major conclusion is that it will be possible to
implement an operating system on iAPX 286, which is
faster and more secure than what is possible using
the MC 68000. This is at least the case for workstations
and other small systems. It is more difficult to compare
the two CPU's as a basis for large systems, as one
is 32 bits while the other is 16 bits. It has been
argued that it is not possible on a 16 bits machine
to run large programs written in a high level language.
4̲ ̲ ̲A̲D̲V̲A̲N̲T̲A̲G̲E̲S̲
4.1 E̲X̲E̲C̲U̲T̲I̲O̲N̲ ̲L̲E̲V̲E̲L̲ ̲P̲R̲O̲T̲E̲C̲T̲I̲O̲N̲
The processor supports 4 execution levels compared
to the normal 2 (user-system state). Each memory segment
has a level, defining the lowest execution level, which
may access the segment. This gives a very flexible
means of allocating and protecting operating system
data within each process.
4.2 S̲E̲G̲M̲E̲N̲T̲E̲D̲ ̲M̲E̲M̲O̲R̲Y̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲
The processor does not generate a conventional logical
address of fixed size. The memory is segmented, and
all memory references are of the form segment .
offset , where segment is an identification of a
segment register in the processor. Logically this mechanism
corresponds to an addressing scheme with double indexing,
and it has the advantage of complete dynamic relocatability
of code and data at any time.
Each process has a protected object table, describing
all segments available to the process. Segment size,
segment level and access rights (read, write, execute)
are part of the object descriptor for a segment. A
single unprotected instruction loads a segment register
from a specified object descriptor and performs level
check etc.. The execution time is about 2.5 u. All
memory references are checked for access rights and
segment size.
The resulting address is a 24 bits physical address,
allowing a physical memory size of 16 M bytes.
The size of a segment can be anything between 2 bytes
and 64 K bytes.
The segmented memory architecture gives the potential
for a highly efficient intertask communication with
transfer of segment descriptors instead of copying
of data. This is also facilitated by hardware support
for validation of pointer parameters in system calls.
This check takes about 70 u in DAMOS, but can be done
in less than 15 u in APX 286.
The virtual address space of a process can be very
large too, and as map-in and map-out is done very efficiently
by hardware, the large virtual address space can be
utilized efficiently by a process.
4.3 S̲Y̲S̲T̲E̲M̲ ̲C̲A̲L̲L̲ ̲V̲I̲A̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
The call to an operating system procedure is done in
the same way as a call to a normal procedure, but the
destination address is replaced by an index to a system
call descriptor in the object descriptor table. The
execution level and entry point address is specified
in the object descriptor.
This mechanism has two advantages:
- Access to a system procedure can be restricted
to certain processes and execution levels.
- System calls can be emulated by normal procedure
calls during module test.
4.4 P̲R̲O̲C̲E̲S̲S̲ ̲C̲O̲N̲C̲E̲P̲T̲
The process concept, and the context of a process in
the form of the object descriptor table, is directly
supported by hardware. Processes are objects, which
are described in the object descriptor table.
A complete process context switch by interrupt or by
the scheduler is done in about 20 u.
The current concepts in CR80 of coroutines within a
process have been introduced for performance reasons,
as cooperation between processes is very inefficient.
This can probably be avoided in APX 286 because of
the very efficient process concept.
4.5 R̲E̲S̲O̲U̲R̲C̲E̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
As memory segments can be individually protected by
execution level, the potential exists for letting the
operating system allocate the necessary control structures
by drawing upon the memory resources of the calling
process.
This has two advantages:
- The operating system needs not keep track of a
number of different resources for each process
and process family.
- The dynamic allocation and deallocation of resources
(list elements, info blocks, control blocks, etc.)
can to a large extent be avoided, thus speeding
up the operating system calls.
4.6 E̲X̲E̲C̲U̲T̲I̲O̲N̲ ̲S̲P̲E̲E̲D̲
According to the available specifications, the iAPX
286 seems to be about 3-4 times as fast as CR80M for
comparable instructions. In addition, it has a number
of instructions for support of operating system functions
which are done completely in software in DAMOS.
4.7 C̲O̲M̲P̲A̲T̲I̲B̲I̲L̲I̲T̲Y̲
The iAPX 286 is directly upwards software compatible
with 8088 used on MP-SQUARE and with 80188 used on
CR16. This means that software written for those systems
can execute unchanged on iAPX 286 with a higher execution
speed.
In order to utilize the protection features for a secure
system, an operating system kernel must, however, be
built from scratch.
This kernel could be designed to support an industry
standard operating system such as CP/M or UNIX, thus
allowing certain application systems to be used without
changes.
5̲ ̲ ̲D̲I̲S̲A̲D̲V̲A̲N̲T̲A̲G̲E̲S̲
5.1 I̲/̲O̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲
I/O is done via conventional I/O instructions, and
a device can thus not be reserved for a single process
(driver) with hardware access check. The only protection
of I/O is by execution level, just as in CR80M. This
is a major disadvantage, as it limits the possibility
for construction of untrusted or "less trusted" drivers.
The efficiency of system calls, and the possibility
of reserving specific system calls for specific processes
does, however, in nearly all cases allow for I/O procedures
on highest privilege levels, which check the I/O port
number before executing the I/O instruction. The additional
overhead, per I/O instruction, of this solution will
be about 20-30 u, which is negligible in most cases.
With relatively small additional overhead it will thus
be possible to write untrusted device drivers.
5.2 I̲N̲T̲E̲G̲R̲A̲T̲E̲D̲ ̲M̲E̲M̲O̲R̲Y̲ ̲M̲A̲P̲
The memory map and protection is integrated into the
CPU. This approach probably results in higher efficiency,
but psychologically it may give the impression that
protection and separation of hardware modules is more
distributed and thus more vulnerable than the centralized
approach with a separate MMU mediating access to memory
from several CPU's and intelligent controllers.
In particular, it limits the possibility of having
untrusted programs in intelligent controllers, as the
controllers will typically be able to access memory
directly via physical addresses.
One solution may be to let the controller have local
memory (as in the CR80 CU) which can be accessed by
CPU's, but this approach will typically involve copying
of data and will thus cause a performance degradation.
A better solution would probably be to develop a separate
MMU to mediate access to main memory from intelligent
device controllers or untrusted CPU's. This MMU should
convert 24 bits logical addresses to 24 bits physical
addresses and would be controlled by the trusted operating
system.
The ultimate solution is of course to base intelligent
controllers upon the iAPX 286, but this may limit too
much the attachment of peripherals with built in intelligence.
In addition to the evaluation of protection and efficiency
the choice of solution also depends upon patents issues,
if the discussion extends to the dualized configurations.
5.3 A̲D̲D̲R̲E̲S̲S̲ ̲S̲P̲A̲C̲E̲
The iAPX 286 is a 16 bits machine. Therefore the size
of a segment is limited to 64 K bytes.
This limitation does not matter for system software
or for "normal" applications. NMJ has, however, argued
that it is difficult or impossible to run really large
programs written in high level languages such as ADA
or Pascal.
