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.

MuseumWaalsdorp@tno.nl