CDC CYBER 74 - part 2

Programming and the software environment

In early 1980, Fortran'77
(FTN5) was introduced at the Physisch Laboratorium. This besides the 'old' compiler
for Fortran'66 (FTN4). The new compiler generated sometimes much faster code than
the old compiler. However, the compiler was sometimes too smart. In one of the
new releases (or "level"), the system call to the SINCOS routine delivered
both the sine and cosine values in X6 and X7 respectively. Great! As most calculations
require both values in the same piece of code. The smart compiler overlooked the
fact that a(i) in sin(a(i)) might have another value as cos(a(j)). The result
was that code that simulated anti-aircraft ballistics resulted in torpedo-behaviour.
The rockets went straight into the ground!

In the same period, we exchanged the Pascal
2 compiler by the new Pascal 3 compiler. Pascal was developed by Nicklaus Wirth
at the Eidgenosische Technische Hochschule Zürich (ETZ). The compiler delivered
highly optimised code for a CDC 6400. Additional
system routines and functions were added by both the computer center of the
Universities in Amsterdam (SARA) and us. Around 1983, we tried to convince the
Pascal compiler to compile in a couple of stages (using DIANA), a ADA-compiler
that was written in Pascal. This required very large compiler tables, ASCII
rather than 6-bit bytes. Unfortunately, this project was overtaken by more urgent
projects.

The disk capacity was always to small. This despite the exchange in February
1983 of three CDC 844-41 disk units by two
CDC 885-disk units, which gave
a double capacity. Thus we decided to remove inactive and old files each week
from the system by archiving them on magnetic tape. The users could request
an archive, delete/clean-up or a reload by using a program that looked at the
"INDEX-system". Archived data was guaranteed for two years. The INDEX-system
made heavily use of the new Cyber Control Language-features
(CCL; 1982).

Cyber Control Language (CCL)
was a - in UNIX-language - kind of shell-language. We, at the
Physisch Laboratorium TNO, added numerous features to CCL in order to let
the system use in an optimal way, both by operational users and the normal users.
Additions like "empty" parameters, print-suppressed "security" parameters
and substrings were added. Most of these additions were developed in 1980.
The CCL-procedures for the Texas Instruments Micro Development Station (MDS)
were halved in size, resulting in efficiency gains on the CYBER
during expansion, parsing and execution of the CCL-procedures.

Manchester Trace Package: post-mortem dump

The standard CDC system pointed out to Fortran users that if they made a programming
error by generating error messages like CPU Error
Modes 1, 2 or 4. This meant that the user tried to address memory outside
his allocated memory, tried to divide by zero or wanted to execute a non-existing
instruction. The only way to figure out where the problem occured was by looking
to the latest printed line and the address where the offending action took place.
The octal dump could be of some help.

User friendly was something else, especially one had to wait for the next night
before the job could be run again. Reason enough to try to obtain the 'public-domain'
(already at that time!) post-mortem dump (PMD) analysis software package developed
by the University of Manchester. As that University just got rid of the lower
Cybers and only had a CYBER 205 supercomputer left, the package support
was transfered to the University of Leicester, a NOS-site. They would provide
us with the magnetic tape with the code, but we had to develop our own changes
to get the package running under the NOS/BE operating
system. That required some changes to the Fortran compiler as well as to the
LOADER and the segmentation loader (SEGLOAD).
Just a couple of weeks after putting the PMD/Leicester Trace Package (LTP) into production,
CDC delivered a new level with surprisingly much new loader-code.
A new feature that saved a lot of the expensive fixed (non-virtual) memory was
"dynamic load" (DLL's!).
Especially, major parts of the Fortran library were made completely dynamic.
(e.g. the I/O-modules).

Adapting PMD/LTP for another operating system was one thing. One had to figure
out problem system calls (another type of system call signalling) and change them.
Adapting the package for these new dynamic, highly undocumented features, however,
required full insight and understanding of the working of the package itself.

After a lot of work, PMD/LTP was able to recognise the dynamically loaded routines
in memory. At that time, PMD/LTP was brought into production again.
That had large consequences for most users as we changed the behaviour of the loader
in such a way that the use of uninitialised data resulted in an abort of the program.
At the end this resulted in a large quality improvement and less 'strange' behaviour
of the program during execution.

Security measures

In 1976, the European Control Data Users (ECODU) working group on operating systems
ECCOS started a security study. The TNO Physisch Laboratorium took part in the
effort as well as the German RRZN
(Hannover), LUCS (London), EPFL
(Lausanne) and RUS (Stuttgart).
This effort was in line with the efforts at the Laboratory to strengthen both
the physical and the system security around its computer room. In ten main categories,
we found 45 major security vulnerabilities in the NOS/BE
operating system. We wrote test code to show the vulnerabilities and developed
code to solve these holes. At the end CDC implemented our security code in new
releases.

During the next phase, we expanded the standaard NOS/BE operating system with
additional security code. Operators could not look anymore at the console into
"sensitive" memory areas. A much stricter function separation was introduced
between Operations and Systems programming. Only after entering a password,
the console was released for full functionality. We developed a very small 100B
PP-overlay that was coded completely "relative".
Thus it could be read and executed at any place by another PP program. This
PP overlay program was cataloged (stored) as a system permanent file with by
the system at the moment of cataloging generated lees-,
modify-, append- en write passwords that included information from the system
microsecond clock. Every generated password was unique and contained characters
that were not accepted by the normal permanent file routines. Moreover, even
the system programmer, could not obtain the password unless very dirty tricks
were used, which require full access to the operating system and the system
memory. Only one control password, "Os0lem1o", (O-solemio) was left for the
system programmer to remove the system file.
Only one special system PP-program could attach the
file with the security overlay, and could trick the system by setting the read
permit in het system memory. Then it could load the system unlock overlay code
into the display PP (DSD). The overlay code contained a kind of pin code to
unlock the secured system. When the PP overlay could not be loaded, the system
was locked completely. This security code gave an optimal protection for the
operational system.

To test new developed security code requires many tricks. Debugging required
an 'open, unlocked system' while on the other hand one wanted to use sensitive
jobs. It is very cumbersome to test security in a system that is optimal secured
against users and system programmers. The trick we used was to develop and compile
the security code. Then, from behind console the
binairy "executable" code was read into memory using the (by ourselves extended)
O26-console editor, which was another PP-program).
At the left screen, the octal memory was displayed, making it easy to look at
the security code and change that by patching memory. Then, O26 was used to
save the file. That slightly adapted PP-code was brought into the system using
EDITLIB(SYSTEM). Then all the required tests could be made, and when the code
worked as expected, the original binary code could be added to the system without
another recompilation. This saved a lot of time as it took an hour compilation
time or more when extensive changes were made to, for instance the console display
driver PP DSD.

As an example of security code that was developed for the various PP-programs,
one can take the PP program ABS that could dump the absolute memory contents
onto paper or a file. The standard code of ABS allowed each user to dump a major
part of the system main memory and the user's own occupied memory space. ABS
was changed in such a way that the memory contents was reported as zeroes unless:

ABS was called by the operating system itself (the "control point zero" ABS dump).

ABS was called from a PP program that could run only in display "unlock mode". This
to please the system programmers.

ABS was supposed to dump an inherent "safe memory area": the jobs' own user space memory
and safe address ranges (tables) in the absolute memory of the system.

ABS was called by a system application.

In 1981, we introduced the Tape Security System (TSS)
which was developed by the University of Bologna, Italy.
We had to convert the package to the latest NOS/BE release, solving a number of errors,
and extended the package with improved logging. It became impossible to
read or overwrite tapes of other users, unless the password of the tape (hidden in an extended
tape label) was known.

An American contact of us developed quit efficient Data Encryption Standard (DES) utilities
in Compass (assembler). We received a deck of punch cards, a couple of weeks before
new US export rules stated that export of DES code was illegal. The DES-routines were used
by us at that time to encrypt a number of sensitive data.

In the beginning of 1984, additional security measures were taken which included
more stringent password rules to be enforced by system programs.
We changed the INTERCOM (interactive users) password system in such a way, that
an additional password file was created that contained a
"physical record unit" (PRU) of 64 words for each user. The users' PRU contained his
last ten one-way encrypted passwords. This in order to avoid (illegal) re-use of passwords.
The upcoming first PC's were sometimes programmed to do an a-b-c-..a scheme to bypass
the change of passwords. Cleverly, we only moved the ten old password stack when the password
was really used to logon. Otherwise only the new password was cycled. This countermeasure
annoyed many of the smart users! The PRU contained time/date of the last five login's
as well as counters that forced users to change their passwords after 250 uses or three months
giving them a grace number of login's.
In total, over three thousand lines of security code was developed that
modified the behaviour of fourty system applications and many PP programs and overlays.

Security measures extended also to physical security. In 1978, we developed
a method to "clean" defective disk packages. Using sand grit, we really cleaned
disks to comply with NATO
security regulations. During the introduction at the world-wide VIM/ECODU users
conference in Minneapolis of the new 885-disk
units that had head-disk assemblies (HDA's), we signaled to Control Data
that the standard maintenance contract required CDC's maintenance engineers
to take the HDA (media and heads) with them in case of errors. The security
regulations required us to keep the disks unless we could guarantee that all
data was "deeply" removed. Based upon our suggestions, Control Data made a world
wide change of the standard maintenance contract allowing sites to keep the
HDA's. The cost involved was recovered by a small "insurance" increase of the
maintenance costs.

Loader

After following a LOADER class that made clear all internals of the Loader, linking,
dynamic loading and segmentation loading, we had enough knowledge to resolve another
annoying problem for our interactive users. (the
"loader" is the system program that loads another executable program and might
start that one up. The program environment, e.g. libraries and default memory
settings are set by the loader, like the "PIF"-description in Windows 3.X)
The execution of system commands under the "interactive" NOS operating system
differed slightly from NOS/BE. Under NOS, each next command was provided by the
"terminal buffer". If not available, the system waited for the next user action.
Under the interactive subsystem of NOS/BE, INTERCOM, only one single command could
be typed ahead as the buffer only allowed one single command in the buffer. Then,
the loader received an end-of-file signal. The Loader sometimes required a number
of subsequent commands, which could not be done under Intercom for the reason
mentioned above. The new knowledge allowed us to activate the NOS code and to
make the necessary small number of changes to get it working. We provided this
code for free to many other computer centers in the world. At the end, CDC implemented
our code as well in the standard system.