CDC CYBER 74 - vervolg

Programmeren en de softwareomgeving

Naast Fortran’66 (FTN4), werd begin 1980 Fortran’77 (FTN5) op het Physisch Laboratorium geïntroduceerd. Een nieuwe vertaler die "soms" betere optimalisaties vertoonde dan de oude. Het ging ook wel eens mis. Zo werd in een nieuwe release ("level") gelijktijdig door de systeemroutine SINCOS de sinus- en de cosinus-waarde opgeleverd. Alleen werd door de slimme vertaler over het hoofd gezien dat sin(a(i)) een ander argument had dan cos(a(j)). Gevolg was een door het LEOK gesimuleerde luchtafweer met torpedo-werking. De afweerraketten gingen heel diep (de grond in) !

Het was ook de periode dat overgegaan werd van Pascal 2 naar Pascal 3. Pascal was oorspronkelijk door Niclaus Wirth ontwikkeld en geoptimaliseerd op een CDC 6400. Met enige achtergrondkennis werden door ons nieuwe opties aan de Pascal-vertaler toegevoegd. Omstreeks ‘83 werd gepoogd op via een tussenstap (DIANA) een in Pascal geschreven ADA-vertaler aan de praat te krijgen. Forse ingrepen waren nodig om de vertaler aan te passen. Bij gebrek aan tijd werd dit project gestopt.

Schijven bleven volstromen. Dit ondanks de omruil in februari 1983 van drie CDC 844-41 schijfeenheden in twee CDC 885-schijfeenheden, waardoor een verdubbeling van schijfruimte plaats vond. Besloten werd oude files wekelijks van het systeem te verwijderen en op magneetband te zetten. De gebruikers konden via een programma "het INDEX-systeem" aangeven of ze files wilden archiveren, opruimen of terugladen. De gearchiveerde informatie werd twee jaar gegarandeerd ("het INDEX-programma"). Het programma maakte gebruik van de net nieuwe Cyber Control Language-mogelijkheden (CCL; 1982).

Cyber Control Language (CCL) was een - in UNIX-termen - soort shell-taal. Door het Physisch Laboratorium TNO werden vele extra mogelijkheden aan CCL toegevoegd om de operationele en gebruikers "gereedschappen" optimaal te kunnen gebruiken. Zaken als "lege" parameters, niet af te drukken "security" parameters en substrings werden toegevoegd. De meeste opties werden in 1980 ontwikkeld. Hiermee konden de CCL-procedures voor het Micro Development Station (MDS) gehalveerd worden qua lengte, waardoor ook nog een efficiëncy-winst op de CYBER geboekt kon worden tijdens de expansie en verwerking van de CCL-procedures.

Manchester Trace Package: post-mortem dump

De Fortran-gebruikers werden door het systeem gewezen op een programmeerfout door foutmeldingen als CPU Error Modes 1, 2 of 4. Dit betekende dat een gebruiker buiten het programmageheugen liep, deelde door nul of een niet-bestaande instructie wilde uitvoeren. De enige manier om er achter te komen waar het probleem optrad was te kijken welke uitvoerregel als laatste geproduceerd was en in welk deel van het geheugen de fout optrad. Hierbij kon de oktale dump helpen.

Gebruiksvriendelijk was wat anders. Reden om eens het public-domain (ook toen al) post-mortem dump (PMD) analyse pakket van de Universiteit van Manchester aan te vragen. Nu was die Universiteit net overgeschakeld op de CYBER 205 supercomputer en was het pakket overgedragen aan de Universiteit van Leicester. Daar konden we het wel krijgen maar dan moesten wij zelf de aanpassingen verrichten om het onder NOS ontwikkelde pakket over te zetten naar NOS/BE. Met enige aanpassingen in de Fortran vertaler en de Loader was dat mogelijk.
Toen wij het pakket net draaiende hadden, inclusief aanpassingen voor de veel door het Physisch Laboratorium gebruikte segmentatie-loader (SEGLOAD), kwam CDC uit met een nieuwe software versie (release). Daarin was als nieuwigheid "dynamic load" (DLL's!) van modulen opgenomen. Vooral de Fortran-bibliotheek was volledig dynamisch gemaakt (o.a. de I/O-modulen). Draaibaar maken van een pakket is releatief eenvoudig omdat daar weinig inhoudelijke kennis voor nodig is. Het aanbrengen van nieuwe zaken is echter minder eenvoudig omdat dat totale inzage in de programmastructuur vergt.

Nadat het pakket ook de nieuwe dynamische routines kon herkennen in het geheugen, werd het in productie genomen. Dat had grote consequenties voor veel gebruikers omdat vanaf dat moment de loader zo ingesteld werd, dat het gebruik van (nog) niet geïnitialiseerde variabelen automatisch leidde tot het afbreken van het programma. Het had wel een sterke kwaliteitsverbetering en uiteindelijk minder "vreemde" problemen tijdens de uitvoering van het programma tot gevolg.

Beveiligingsmaatregelen

In 1976 werd door de operating system werkgroep ECCOS van de Europese Control Data gebruikersvereniging (ECODU) besloten een beveiligingsstudie te verrichten. Het Physisch Laboratorium maakte daar deel van uit tezamen het RRZN (Hannover), LUCS (London), EPFL (Lausanne) en RUS (Stuttgart). Dit strookte met de geplande aanscherping van zowel de fysieke als de systeembeveiliging op het Laboratorium. In tien hoofdcategorieën werden zo’n 45 grote beveiligingsgaten in het NOS/BE systeem ontdekt waarvoor testprogrammatuur geschreven werd en oplossingen werden ontwikkeld.

De volgende fase was het uitbreiden van het standaard NOS/BE-systeem met extra beveiligingscode. Operators konden geen "gevoelige" delen van het geheugen meer op het console zien. Een striktere functiescheiding werd doorgevoerd. Alleen na het intypen van een "wachtwoord" kon het console vrijgegeven worden. Er werd een kleine, minder dan 100B grote, PP-overlay geschreven die geheel "relatief" gecodeerd was zodat deze overal geladen en uitgevoerd kon worden. Dit programma werd opgeslagen als een systeem permanente file met door het systeem zelf, aan de hand van de microsecondeklok, berekende lees-, modify-, append- en write passwords. Ieder password was daardoor anders en voor eenieder, ook voor de systeemprogrammeurs, absoluut niet te achterhalen. Het vervangen van de code was alleen toegestaan indien men het speciale wachtwoord "Os0lem1o" (O-solemio) kende.
Slechts één PP-programma was in staat om de verwijzing naar de file met de beveiligingscode op te pakken, daarna het permissie-bit "leespermissie" in het systeemgeheugen aan te zetten en vervolgens de "unlock-code", een soort van pin-code, in te lezen. Indien de overlay niet geladen was, dan kon het systeem geheel niet UNLOCKed worden. Hierdoor was het systeem optimaal beveiligd omdat de echte beveiligingscode op geen enkele andere manier uit te lezen was.

Nog een "truc" moest toegepast worden bij het testen van nieuwe beveiligingscode. Het was namelijk altijd erg lastig om wijzigingen te testen in een systeem dat optimaal (ook tegen de systeemprogrammeurs zelf) beveiligd was en daardoor anders reageerde voor de "gevoelige"-jobs. Om nieuwe code te kunnen testen in een normale omgeving werd de beveiligingscode gewoon ontwikkeld en vertaald. Vervolgens werd de binaire "executable" code achter het console "ingelezen" met behulp van de door systeemprogrammering zelf sterk uitgebreide O26-console editor (ook een PP-programma). Vervolgens werd op het andere consolescherm de oktale geheugeninhoud zichtbaar gemaakt. Het was dan eenvoudig om de speciale beveiligingstesten te "verschuiven" door de geheugenwoorden - en daarmee de PP-code - te wijzigen. Daarna werd weer naar de O26-editor overgeschakeld en werd de gewijzigde code als tijdelijke file weggeschreven. Vervolgens werd de aangepaste PP-code met EDITLIB(SYSTEM) aan het systeem toegevoegd. Daarna kon de nieuwe beveiligingscode probleemloos uitgetest worden. Voldeed de code, dan werd de "echte" versie toegevoegd aan het systeem. Deze manier van werken bespaarde een extra vertaling, die voor verschillende PP-programma’s wel eens meer dan een uur doorlooptijd kon vergen.

Als voorbeeld van de beveiligingen die ingebouwd werden in PP-programma’s, gold het programma ABS waarmee het geheugen van het systeem op papier gedumpt kon worden. Standaard kon iedere gebruiker met ABS de inhoud van het systeemgedeelte van het geheugen en zijn eigen werkgeheugen op papier afdrukken. ABS werd door ons zo gewijzigd dat deze de geheugeninhoud als "nul" rapporteerde tenzij:

ABS aangeroepen werd door het operating systeem zelf (zogenaamd "control point zero").
ABS aangeroepen werd vanuit een PP-programma dat alleen in console "unlock mode" - onbeveiligd draaien - draaien kon.
ABS een inherent "veilig geheugengebied" moest dumpen: het eigen geheugen van de job en de "veilige" adresgebieden in het absolute geheugen van het systeem.
ABS aangeroepen werd vanuit een systeemprogramma.

In 1981 namen wij het door de Universiteit van Bologna ontwikkelde Tape Security System (TSS) in gebruik nadat dit naar een nieuw "level" geconverteerd was en nadat een aantal fouten opgelost en verbeteringen (met name logging) aangebracht waren. Voor gebruikers werd het onmogelijk om magneetbanden van anderen te lezen en/of te overschrijven, tenzij het bij de tape behorende wachtwoord bekend was.

Van een Amerikaan was, net nadat de Data Encryption Standard (DES) openbaar gemaakt was, een Fortran-implementatie van DES ontvangen. Twee maanden later viel DES ineens onder de Amerikaanse exportverboden. Dat weerhield ons niet om DES te gebruiken om gevoelige gegevens te encrypten.

Begin 1984 werden er extra eisen gesteld aan de te gebruiken wachtwoorden, hetgeen door ons middels extra programmacode afgedwongen moest worden. Het INTERCOM (interactive users) password systeem moest aangepast worden. Naast de standaard passwordfile kwam er een extra file, die aan iedere accountnaam een "physical record unit" (PRU) van 64 woorden koppelde. In die PRU werden de laatst gebruikte tien one-way encrypted wachtwoorden bijgehouden. Dit om het hergebruik van wachtwoorden tegen te gaan. Om PC’s te weren die een a-b-c-..a schema probeerden uit te voeren om weer lange tijd van het oude wachtwoord gebruik te kunnen maken, werd de lijst met eerder gebruikte wachtwoorden pas bij het tweede gebruik van een wachtwoord opgeschoven in de lijst ("countermeasure"). Ook werden in de PRU de tijd/datumgegevens van de laatste vijf login’s bijgehouden en tellers waarmee een gebruiker gedwongen werd na 250 log-ins of drie maanden gebruik zijn wachtwoord te wijzigen. In dat geval kon de gebruiker nog enkele malen inloggen voordat een gehele blokkade optrad (grace-login's).
In het totaal werden zo’n drieduizend regels beveiligingscode ontwikkeld welke ingrepen op zo’n veertig systeemprogramma’s en PP’s, alsmede op een tiental overlays van deze PP-programma’s.

Ook op hardware-gebied was het Physisch Laboratorium RVO-TNO beveiligingsbewust. In 1978 hadden wij een manier ontwikkeld om defecte schijfpakketten middels zandstralen afdoende veilig te vernietigen volgens NATO-normen. Bij de introductie van de nieuwe 885-schijfeenheden met head-disk assemblies (HDA’s) werd door het Physisch Laboratorium op de wereldwijde gebruikersconferentie in Minneapolis het probleem gesignaleerd dat bij een defect de technici volgens de onderhoudsvoorwaarden de HDA (media plus koppen) mee zouden nemen, iets dat volgens de vigerende beveiligingsrichtlijnen niet toegestaan was. Naar aanleiding van onze reactie is door Control Data een wereldwijd geldende restitutieregeling bedacht voor HDA’s. Het resterende risico kon afgedekt worden door een kleine opslag op de onderhoudstarieven voor de schijven.

Loader

Na het volgen van een LOADER-cursus waarin alles van loading, linking en dynamic loading duidelijk gemaakt werd, was de kennis daar om een van de problemen die het NOS/BE operating systeem kende voorgoed uit de wereld te helpen. (De "loader" is het programma dat er voor zorgt dat een ander programma geladen en opgestart kan worden, waarbij de 'omgeving' tevens goed ingesteld wordt, onder Windows 3.x te vergelijken met de "PIF"-beschrijving)
De wijze waarop systeemcommando’s afgehandeld werden was net iets anders onder het "interactieve" NOS besturingssysteem dan onder NOS/BE. Onder NOS werd ieder volgend commando uit de "terminal buffer" gehaald en, indien niet aanwezig, werd gewacht op het intypen door de gebruiker van het volgende (sub)commando. Onder het interactieve deelsysteem van NOS/BE, INTERCOM, kon slechts één commando vooruit gegeven worden. Daarna brak het commando proces af (einde file-signaal). Met de opgedane kennis kon de NOS-code geactiveerd worden en met een anderhalve pagina extra assembler code werd een ergernis voor de gebruikers weggewerkt. In een later stadium is deze code door vele collega computercentra overgenomen en uiteindelijk standaard geworden in het NOS/BE systeem.

MuseumWaalsdorp@tno.nl