NLTSS
Encyclopedia
NLTSS, the Network Livermore Timesharing System, also sometimes known as the New Livermore Time Sharing System was an operating system
that was actively developed at Lawrence Livermore Laboratory (now Lawrence Livermore National Laboratory
) from 1979 until about 1988, though it continued to run production applications until 1995. An earlier system, the Livermore Time Sharing System
had been developed over a decade earlier.
NLTSS ran initially on a CDC 7600
computer, but only ran production from about 1985 until 1994 on Cray
computers including the Cray-1
, Cray X-MP
, and Cray Y-MP
models.
message passing
system. It was unique in that only a single system call was supported by the kernel of the system. That system call, which might be called "communicate" (it didn't have a name because it didn't need to be distinguished from other system calls) accepted a list of "buffer tables" (e.g. see The NLTSS Message System Interface) that contained control information for message communication - either sends or receives. Such communication, both locally within the system and across a network was all the kernel of the system supported directly for user processes
. The "message system" (supporting the one call and the network protocols) and drivers for the disks and processor composed the entire kernel of the system.
client–server system. The two primary servers were the file server and the process server. The file server was a process privileged to be trusted by the drivers for local storage (disk storage,) and the process server was a process privileged to be trusted by the processor driver (software that switched time sharing control between processes in the "alternator", handled interrupts for processes besides the "communicate" call, provided access to memory and process state for the process server, etc.).
NLTSS was a true network operating system
in that its resource requests could come from local processes or remote processes anywhere on the network and the servers didn't distinguish them. A server's only means to make such distinctions would be by network address and they had no reason to make such distinctions. All requests to the servers appeared as network requests.
Communication between processes in NLTSS by convention used the LINCS (Livermore Interactive Network Communication System) protocol suite, which defined a protocol stack
along the lines of that defined by the OSI reference model. The transport level protocol for NLTSS and LINCS was called Delta-T. At the presentation level LINCS defined standards for communicating numbered parameters as tokens (e.g. integers, capabilities, etc.) that were stored in a session level record for processing in a remote procedure call
sort of mechanism.
The notion of a "user
" was only rather peripherally defined in NLTSS. There was an "account server" that kept track of which users were using which resources (e.g. requests to create objects such as file or processes required such an account capability). Access control was entirely managed with capabilities (communicable authority tokens).
would of course not block and could check or block later. Any such differences on the user side were invisible to the file server.
known as "Model". Model extended Pascal to include an abstract data type
(object) mechanism and some other features.
NLTSS was saddled with a compatibility legacy. NLTSS followed the development and deployment of the LTSS (Livermore Time Sharing System) in the Livermore Computer Center at LLNL (~1968-1988?). NLTSS development started about the same time LTSS was ported to the Cray-1
to become the Cray Time Sharing System
. To stay backward compatible with the many scientific applications at LLNL, NLTSS was forced to emulate the prior LTSS operating system's system calls. This emulation was implemented in the form of a compatibility library called "baselib". As one example, while the directory structure and thus the process structure for NLTSS was naturally a directed graph
(process capabilities could be stored in directories just like file capabilities or directory capabilities), the baselib library emulated a simple linear (controller - controllee) process structure (not even a tree structure
as in Unix
) to stay compatible with the previous LTSS. Since scientific users never accessed NLTSS services outside the baselib library, NLTSS ended up looking nearly exactly like LTSS to its users. Most users weren't aware of capabilities, didn't realize that they could access resources across the network, and generally weren't aware that NLTSS offered any services beyond those of LTSS. NLTSS did support shared memory
symmetric multiprocessing
, a development that paralleled a similar development in the Cray Time Sharing System
.
Even the name NLTSS was something of a legacy. The "New Livermore Time Sharing System" name was initially considered a temporary name to use during development. Once the system began to run some applications in a "dual system" mode (sort of a virtual machine
sharing drivers with LTSS) a more permanent name, LINOS (LIncs Network Operating System), was chosen by the developers. Unfortunately, the management at LLNL decided that the name couldn't be changed at that point (seemingly because the previous term had been used in budget requests) so the temporary development "NLTSS" name stayed with the system throughout its lifetime.
A mass storage
system was also developed in parallel with NLTSS that used the LINCS protocols (same file and directory protocols as NLTSS). This system/software was later commercialized as the Unitree product. Unitree was generally superseded by the High Performance Storage System
that could loosely be considered a legacy of LINCS and NLTSS. For example, LINCS and NLTSS introduced a form of third party transfer (to copy file to file in NLTSS a process could send two requests to file servers, one to read and one to write and direct the file servers to transfer the data between themselves) that carried through in modified form to Unitree and HPSS.
. This generally wasn't a significant problem for disk I/O, but the systems that NLTSS ran on also supported a significant complement of very low latency solid state disks with access times under 10 microseconds. The initial latencies for file operations under NLTSS were comparable to the latency for solid state disk access and significantly higher than the LTSS latency for such access. To improve file access latency under NLTSS the implementation was changed significantly to put the most latency sensitive processes (in particular the file server) "in the kernel". This effort wasn't as significant as it might at first sound as all NLTSS servers worked on a multithreading
model. What this change really amounted to was to move the threads responsible for file server services from a separate file server process into the kernel "process". Communication to users was unchanged (still through buffer tables, LINCS tokens, etc.), but file operations avoided some significant context changes that were the primary cause of the higher latencies over what the older LTSS and the competing Cray Time Sharing System
provided. This change did significantly (~3x) improve the latency of file I/O operations, but it also meant that the file server became a trusted part of the kernel (by implementation, not by design).
A second implementation issue with NLTSS related to the security/integrity of its capability as data implementation. This implementation used a password capability model (e.g. see Control by Password). With this model any person or process that could get access to the memory space of a process would have the authority to access the capability represented by the data found in that memory. Some system architects (e.g. Andrew S. Tanenbaum
, the architect of the Amoeba distributed operating system
) have suggested that this property of access to memory implying access to capabilities is not an inherent problem. In the environment of NLTSS it sometimes happened that people took program memory dumps to others for analysis. Because of this and other concerns, such password capabilities were considered a vulnerability in NLTSS. A design was done to protect against this vulnerability, the Control by Public Key Encryption mechanism. This mechanism wasn't put into production in NLTSS both because of its significant performance cost and because users weren't aware of the vulnerability from password capabilities. Modern advances in cryptography would make such protection for capabilities practical, especially for Internet/Web capabilities (e.g. see YURLs or WideWORD).
A design issue with NLTSS that wasn't considered until years after it was removed from production was its open network architecture. In NLTSS processes were considered as virtual processors in a network with no firewalls or other restrictions. Any process could communicate freely to any other. This meant that it was not possible to do confinement even in the sense of limiting direct communication (e.g. vs. limiting covert channel
s such as "wall banging"). To correct this problem NLTSS would have to require capabilities to enable communication. Late development work on NLTSS such as "stream numbers" was getting close to such a facility, but by the time active development stopped in 1988 communication in NLTSS was still unconfined.
Operating system
An operating system is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system...
that was actively developed at Lawrence Livermore Laboratory (now Lawrence Livermore National Laboratory
Lawrence Livermore National Laboratory
The Lawrence Livermore National Laboratory , just outside Livermore, California, is a Federally Funded Research and Development Center founded by the University of California in 1952...
) from 1979 until about 1988, though it continued to run production applications until 1995. An earlier system, the Livermore Time Sharing System
Livermore Time Sharing System
The Livermore Time Sharing System was a supercomputer operating system originally developed by the Lawrence Livermore Laboratories for the CDC 7600 series of supercomputers....
had been developed over a decade earlier.
NLTSS ran initially on a CDC 7600
CDC 7600
The CDC 7600 was the Seymour Cray-designed successor to the CDC 6600, extending Control Data's dominance of the supercomputer field into the 1970s. The 7600 ran at 36.4 MHz and had a 65 Kword primary memory using core and variable-size secondary memory...
computer, but only ran production from about 1985 until 1994 on Cray
Cray
Cray Inc. is an American supercomputer manufacturer based in Seattle, Washington. The company's predecessor, Cray Research, Inc. , was founded in 1972 by computer designer Seymour Cray. Seymour Cray went on to form the spin-off Cray Computer Corporation , in 1989, which went bankrupt in 1995,...
computers including the Cray-1
Cray-1
The Cray-1 was a supercomputer designed, manufactured, and marketed by Cray Research. The first Cray-1 system was installed at Los Alamos National Laboratory in 1976, and it went on to become one of the best known and most successful supercomputers in history...
, Cray X-MP
Cray X-MP
The Cray X-MP was a supercomputer designed, built and sold by Cray Research. It was announced in 1982 as the "cleaned up" successor to the 1975 Cray-1, and was the world's fastest computer from 1983 to 1985...
, and Cray Y-MP
Cray Y-MP
The Cray Y-MP was a supercomputer sold by Cray Research from 1988, and the successor to the company's X-MP. The Y-MP retained software compatibility with the X-MP, but extended the address registers from 24 to 32 bits. High-density VLSI ECL technology was used and a new liquid cooling system was...
models.
Low-level architecture
NLTSS was a microkernelMicrokernel
In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system . These mechanisms include low-level address space management, thread management, and inter-process communication...
message passing
Message passing
Message passing in computer science is a form of communication used in parallel computing, object-oriented programming, and interprocess communication. In this model, processes or objects can send and receive messages to other processes...
system. It was unique in that only a single system call was supported by the kernel of the system. That system call, which might be called "communicate" (it didn't have a name because it didn't need to be distinguished from other system calls) accepted a list of "buffer tables" (e.g. see The NLTSS Message System Interface) that contained control information for message communication - either sends or receives. Such communication, both locally within the system and across a network was all the kernel of the system supported directly for user processes
Process (computing)
In computing, a process is an instance of a computer program that is being executed. It contains the program code and its current activity. Depending on the operating system , a process may be made up of multiple threads of execution that execute instructions concurrently.A computer program is a...
. The "message system" (supporting the one call and the network protocols) and drivers for the disks and processor composed the entire kernel of the system.
Mid-level architecture
NLTSS was a capability-basedCapability-based security
Capability-based security is a concept in the design of secure computing systems, one of the existing security models. A capability is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights...
client–server system. The two primary servers were the file server and the process server. The file server was a process privileged to be trusted by the drivers for local storage (disk storage,) and the process server was a process privileged to be trusted by the processor driver (software that switched time sharing control between processes in the "alternator", handled interrupts for processes besides the "communicate" call, provided access to memory and process state for the process server, etc.).
NLTSS was a true network operating system
Network operating system
A networking operating system , also referred to as the Dialoguer, is the software that runs on a server and enables the server to manage data, users, groups, security, applications, and other networking functions...
in that its resource requests could come from local processes or remote processes anywhere on the network and the servers didn't distinguish them. A server's only means to make such distinctions would be by network address and they had no reason to make such distinctions. All requests to the servers appeared as network requests.
Communication between processes in NLTSS by convention used the LINCS (Livermore Interactive Network Communication System) protocol suite, which defined a protocol stack
Protocol stack
The protocol stack is an implementation of a computer networking protocol suite. The terms are often used interchangeably. Strictly speaking, the suite is the definition of the protocols, and the stack is the software implementation of them....
along the lines of that defined by the OSI reference model. The transport level protocol for NLTSS and LINCS was called Delta-T. At the presentation level LINCS defined standards for communicating numbered parameters as tokens (e.g. integers, capabilities, etc.) that were stored in a session level record for processing in a remote procedure call
Remote procedure call
In computer science, a remote procedure call is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space without the programmer explicitly coding the details for this remote interaction...
sort of mechanism.
The notion of a "user
User (computing)
A user is an agent, either a human agent or software agent, who uses a computer or network service. A user often has a user account and is identified by a username , screen name , nickname , or handle, which is derived from the identical Citizen's Band radio term.Users are...
" was only rather peripherally defined in NLTSS. There was an "account server" that kept track of which users were using which resources (e.g. requests to create objects such as file or processes required such an account capability). Access control was entirely managed with capabilities (communicable authority tokens).
File server
Any process could make requests to the file server for the creation of files (returning a file capability), ask to read or write files (by presenting a file capability), etc. For example, the act of reading a file generally required three buffer tables, one to send the request to the file server, one to receive the reply from the file server, and one to receive the data from the file. These three requests were generally submitted at one time to the message system, sometimes bundled with other requests. Control bits could be set in the buffer tables to awaken (unblock) a process whenever any of the buffer tables submitted were marked "Done". A library call to read a file would typically block until the control reply was received from the file server, though asynchronous I/OAsynchronous I/O
Asynchronous I/O, or non-blocking I/O, is a form of input/output processing that permits other processing to continue before the transmission has finished....
would of course not block and could check or block later. Any such differences on the user side were invisible to the file server.
Process server
In NLTSS the process server was quite similar to the file server in that user processes could ask for the creation of processes, the starting or stopping of processes, reading or writing process memory or registers, and to be notified of process faults. The process server was an ordinary user mode process that was simply trusted to communicate with the CPU driver, just like the file server was trusted to communicate with the disk driver. The process server stored process state in files provided by the file server and in that regard appeared like any other user process to the file server.Directory server
An example higher level server in NLTSS was the directory server. This server's task was to essentially turn files (invisible to the user) into directories that could be used to store and retrieve capabilities by name. Since capabilities were simply data this wasn't a particularly difficult task - consisting mostly of manipulating access permissions on the capabilities according to the conventions defined in the LINCS protocol suite. One place where this got a bit interesting was regarding an access permission called "inheritance". If this bit was on (allowed) then capabilities could be fetched with their full access from the directory. If this bit was turned off (disallowed) then any permissions turned off in the directory capability were in turn turned off in the capability being feteched before it was returned to the requesting application. This mechanism allowed people to store, for example, read/write files in a directory, but to give other users only permission to fetch read-only instances of them.Development
The bulk of the programming for NLTSS was done in a Pascal extension developed at Los Alamos National LaboratoryLos Alamos National Laboratory
Los Alamos National Laboratory is a United States Department of Energy national laboratory, managed and operated by Los Alamos National Security , located in Los Alamos, New Mexico...
known as "Model". Model extended Pascal to include an abstract data type
Abstract data type
In computing, an abstract data type is a mathematical model for a certain class of data structures that have similar behavior; or for certain data types of one or more programming languages that have similar semantics...
(object) mechanism and some other features.
NLTSS was saddled with a compatibility legacy. NLTSS followed the development and deployment of the LTSS (Livermore Time Sharing System) in the Livermore Computer Center at LLNL (~1968-1988?). NLTSS development started about the same time LTSS was ported to the Cray-1
Cray-1
The Cray-1 was a supercomputer designed, manufactured, and marketed by Cray Research. The first Cray-1 system was installed at Los Alamos National Laboratory in 1976, and it went on to become one of the best known and most successful supercomputers in history...
to become the Cray Time Sharing System
Cray Time Sharing System
The Cray Time Sharing System, also known in the Cray user community as CTSS, was developed as an operating system for the Cray-1 or Cray X-MP line of supercomputers. CTSS was developed by the Los Alamos Scientific Laboratory in conjunction with the Lawrence Livermore Laboratory...
. To stay backward compatible with the many scientific applications at LLNL, NLTSS was forced to emulate the prior LTSS operating system's system calls. This emulation was implemented in the form of a compatibility library called "baselib". As one example, while the directory structure and thus the process structure for NLTSS was naturally a directed graph
Directed graph
A directed graph or digraph is a pair G= of:* a set V, whose elements are called vertices or nodes,...
(process capabilities could be stored in directories just like file capabilities or directory capabilities), the baselib library emulated a simple linear (controller - controllee) process structure (not even a tree structure
Tree structure
A tree structure is a way of representing the hierarchical nature of a structure in a graphical form. It is named a "tree structure" because the classic representation resembles a tree, even though the chart is generally upside down compared to an actual tree, with the "root" at the top and the...
as in Unix
Unix
Unix is a multitasking, multi-user computer operating system originally developed in 1969 by a group of AT&T employees at Bell Labs, including Ken Thompson, Dennis Ritchie, Brian Kernighan, Douglas McIlroy, and Joe Ossanna...
) to stay compatible with the previous LTSS. Since scientific users never accessed NLTSS services outside the baselib library, NLTSS ended up looking nearly exactly like LTSS to its users. Most users weren't aware of capabilities, didn't realize that they could access resources across the network, and generally weren't aware that NLTSS offered any services beyond those of LTSS. NLTSS did support shared memory
Shared memory
In computing, shared memory is memory that may be simultaneously accessed by multiple programs with an intent to provide communication among them or avoid redundant copies. Depending on context, programs may run on a single processor or on multiple separate processors...
symmetric multiprocessing
Symmetric multiprocessing
In computing, symmetric multiprocessing involves a multiprocessor computer hardware architecture where two or more identical processors are connected to a single shared main memory and are controlled by a single OS instance. Most common multiprocessor systems today use an SMP architecture...
, a development that paralleled a similar development in the Cray Time Sharing System
Cray Time Sharing System
The Cray Time Sharing System, also known in the Cray user community as CTSS, was developed as an operating system for the Cray-1 or Cray X-MP line of supercomputers. CTSS was developed by the Los Alamos Scientific Laboratory in conjunction with the Lawrence Livermore Laboratory...
.
Even the name NLTSS was something of a legacy. The "New Livermore Time Sharing System" name was initially considered a temporary name to use during development. Once the system began to run some applications in a "dual system" mode (sort of a virtual machine
Virtual machine
A virtual machine is a "completely isolated guest operating system installation within a normal host operating system". Modern virtual machines are implemented with either software emulation or hardware virtualization or both together.-VM Definitions:A virtual machine is a software...
sharing drivers with LTSS) a more permanent name, LINOS (LIncs Network Operating System), was chosen by the developers. Unfortunately, the management at LLNL decided that the name couldn't be changed at that point (seemingly because the previous term had been used in budget requests) so the temporary development "NLTSS" name stayed with the system throughout its lifetime.
A mass storage
Mass storage
In computing, mass storage refers to the storage of large amounts of data in a persisting and machine-readable fashion. Devices and/or systems that have been described as mass storage include tape libraries, RAID systems, hard disk drives, magnetic tape drives, optical disc drives, magneto-optical...
system was also developed in parallel with NLTSS that used the LINCS protocols (same file and directory protocols as NLTSS). This system/software was later commercialized as the Unitree product. Unitree was generally superseded by the High Performance Storage System
High Performance Storage System
High Performance Storage System is a flexible, scalable policy-based Hierarchical Storage Management product developed by IBM in collaboration with five DOE National Labs...
that could loosely be considered a legacy of LINCS and NLTSS. For example, LINCS and NLTSS introduced a form of third party transfer (to copy file to file in NLTSS a process could send two requests to file servers, one to read and one to write and direct the file servers to transfer the data between themselves) that carried through in modified form to Unitree and HPSS.
Implementation and design issues
The biggest knock against NLTSS during its production lifetime was performance. The one performance issue that affected users most was file access latencyLatency (engineering)
Latency is a measure of time delay experienced in a system, the precise definition of which depends on the system and the time being measured. Latencies may have different meaning in different contexts.-Packet-switched networks:...
. This generally wasn't a significant problem for disk I/O, but the systems that NLTSS ran on also supported a significant complement of very low latency solid state disks with access times under 10 microseconds. The initial latencies for file operations under NLTSS were comparable to the latency for solid state disk access and significantly higher than the LTSS latency for such access. To improve file access latency under NLTSS the implementation was changed significantly to put the most latency sensitive processes (in particular the file server) "in the kernel". This effort wasn't as significant as it might at first sound as all NLTSS servers worked on a multithreading
Thread (computer science)
In computer science, a thread of execution is the smallest unit of processing that can be scheduled by an operating system. The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process...
model. What this change really amounted to was to move the threads responsible for file server services from a separate file server process into the kernel "process". Communication to users was unchanged (still through buffer tables, LINCS tokens, etc.), but file operations avoided some significant context changes that were the primary cause of the higher latencies over what the older LTSS and the competing Cray Time Sharing System
Cray Time Sharing System
The Cray Time Sharing System, also known in the Cray user community as CTSS, was developed as an operating system for the Cray-1 or Cray X-MP line of supercomputers. CTSS was developed by the Los Alamos Scientific Laboratory in conjunction with the Lawrence Livermore Laboratory...
provided. This change did significantly (~3x) improve the latency of file I/O operations, but it also meant that the file server became a trusted part of the kernel (by implementation, not by design).
A second implementation issue with NLTSS related to the security/integrity of its capability as data implementation. This implementation used a password capability model (e.g. see Control by Password). With this model any person or process that could get access to the memory space of a process would have the authority to access the capability represented by the data found in that memory. Some system architects (e.g. Andrew S. Tanenbaum
Andrew S. Tanenbaum
Andrew Stuart "Andy" Tanenbaum is a professor of computer science at the Vrije Universiteit, Amsterdam in the Netherlands. He is best known as the author of MINIX, a free Unix-like operating system for teaching purposes, and for his computer science textbooks, regarded as standard texts in the...
, the architect of the Amoeba distributed operating system
Amoeba distributed operating system
Amoeba is an open source microkernel-based distributed operating system developed by Andrew S. Tanenbaum and others at the Vrije Universiteit. The aim of the Amoeba project is to build a timesharing system that makes an entire network of computers appear to the user as a single machine...
) have suggested that this property of access to memory implying access to capabilities is not an inherent problem. In the environment of NLTSS it sometimes happened that people took program memory dumps to others for analysis. Because of this and other concerns, such password capabilities were considered a vulnerability in NLTSS. A design was done to protect against this vulnerability, the Control by Public Key Encryption mechanism. This mechanism wasn't put into production in NLTSS both because of its significant performance cost and because users weren't aware of the vulnerability from password capabilities. Modern advances in cryptography would make such protection for capabilities practical, especially for Internet/Web capabilities (e.g. see YURLs or WideWORD).
A design issue with NLTSS that wasn't considered until years after it was removed from production was its open network architecture. In NLTSS processes were considered as virtual processors in a network with no firewalls or other restrictions. Any process could communicate freely to any other. This meant that it was not possible to do confinement even in the sense of limiting direct communication (e.g. vs. limiting covert channel
Covert channel
In computer security, a covert channel is a type of computer security attack that creates a capability to transfer information objects between processes that are not supposed to be allowed to communicate by the computer security policy...
s such as "wall banging"). To correct this problem NLTSS would have to require capabilities to enable communication. Late development work on NLTSS such as "stream numbers" was getting close to such a facility, but by the time active development stopped in 1988 communication in NLTSS was still unconfined.
External links
- Capability Computing at LLNL A discussion of the history of the use of capabilities in computing at LLNL, including a brief mention of the RATS system and how the development lead to NLTSS
- Stories of the Development of Large Scale Scientific Computing at Lawrence Livermore National Laboratory
- The NLTSS Chronicles Cartoons from the development of NLTSS and LINCS