The IBM System/ Introduction

Transcription

1 8 The IBM System/ Introduction IBM s capabiity-based System38 [Berstis 80a, Houdek 81, IBM Sa, IBM 82b], announced in 1978 and deivered in 1980, is an outgrowth of work that began in the ate sixties and eary seventies on IBM s future system (FS) project. Designers at the IBM Deveopment Laboratory in Rochester, Minnesota incorporated ideas from FS, modified by their needs, to produce a system for the commercia marketpace. It is interesting that such an advanced, object-based architecture has been appied to a very traditiona product space. Initiay, ony the COBOL and RPG III anguages were provided. The system, which incudes the CPF (Contro Program Faciity) operating system, is intended to support transaction processing and database appications constructed in commercia anguages. A major goa of the System38 design is to maintain programmer independence from the system impementation [Dahby SO]; IBM wished to retain maximum fexibiity to modify System38 s impementation for future technoogies whie supporting previousy written System38 programs. The designers aso wished to support a high eve of integrity and security at the machine interface and to support commony executed user and system functions efficienty, such as database searches and memory management [Hoffman 801. To meet these goas, IBM chose a ayered machine structure with a high-eve programming interface. The ayers of this design are shown in Figure 8-. At the owest eve is a hardware machine that directy exe- 137

2 The IBM System/38 User Appications Verticai Horizon&/ Hardware Microcode Microcode Machine Figure 8-1: System/38 Impementation Layers cutes 32-bit horizonta microcode. This horizonta microcode impements a more-or-ess standard 32-bit register machine that executes vertica microcode. The interface above the vertica microcode, caed the high-eve architecture interface in Figure 8-1, is the eve described in this chapter; it supports the user-visibe (or CPF-visibe) System38. This high-eve architecture interface is supported across impementations, whie the structure of the underying ayers can change. For exampe, performance-critica functions, such as interprocess communication and memory aocation, are handed by the horizonta microcode. The system object and capabiity support is handed in part by both microcode ayers. Different functions can be moved between microcode eves or into hardware in future versions, as performance experience is gained. In fact, this movement has aready occurred on newer System38 reeases and modes. The CPF operating system and the vertica microcode are impemented in PLiS, a PLiI-ike system programming anguage. There are approximatey 900,000 ines of high-eve PWS code and an additiona 400,000 ines of microcode support needed to impement CPF and its program products, The System38 hardware incudes a non-removabe disk that hods this arge store of microcode. The System38 s high-eve architecture interface is actuay an intermediate anguage produced by a System38 compiers. Before a program is executed, CPF transates this intermediate anguage into vertica microcode and cas to vertica microcode 138 Athough IBM cas this ayer vertica microcode, it woud generay not be considered microcode because it resembes a traditiona IBM 370-ike 32-bit instruction set and is programmed in a high-eve anguage.

3 procedures. That is, the high-eve interface is not directy executed. This transation process is described ater. IBM terminoogy is used throughout this chapter for compatibiity with System/38 pubications; it differs somewhat from that used in previous chapters. In particuar, IBM uses the foowing terms: space for segment, pointer for capabiity, authority for rights, and context for directory. These synonyms wi be presented again as each of the terms is introduced. 8.2 System Objects 8.2 System Objects System/38 instructions operate on two types of entities: scaar data eements and system objects. The scaar types are 16- and 32-bit signed binary, zoned and packed decima, and character strings. The machine supports 14 types of system objects, described in Tabe 8-1. A set of type-specific instructions is provided for each system type. SPACE PROGRAM USER PROFILE CONTEXT QUEUE byte-addressabe storage segment procedure instructions and associated data object containing information about user s resource imits and authority to access any system objects directory of object names and capabiities message queue for interprocess communication DATA SPACE coection of identicay-structured records DATA SPACE INDEX object used to provide ogica ordering for data space entries CURSOR direct interface to entries in a data space, or indirect interface through a data space index INDEX accesses data sequences based on key vaues PROCESS CONTROL SPACE object containing state information for a process ACCESS GROUP set of objects grouped together for paging performance reasons LOGICAL UNIT DESCRIPTION object describing an I/O device CONTROLLER DESCRIPTION object describing the attributes of a device controer NETWORK DESCRIPTION object describing a communications port Tab/e 8-1: Systemi System Object Types 139

4 The IBM System138 Each system object consists of two parts: a functiona portion and an optiona space portion, as shown in Figure 8-2. The functiona portion of an object is a segment containing object state (its representation); the data in the functiona portion can be examined and modified ony by microcode as a resut of type-specific instructions. Thus, the functiona portion is said to be encapsuated because it is not accessibe to programs [Pinnow 801. Optionay, a space portion can be associated with an object (IBM uses the word space to refer to a storage segment). The space portion is an attached segment for storing scaars and pointers that can be directy manipuated by user programs. Every object in the system has severa associated attributes. First is a type that identifies it as one of the 14 system object types isted in Tabe 8-1. (Objects can aso have subtypes for further software cassification.) Second is a symboic text name chosen by the user to refer to the object. Last is a unique identifier (ID) that uniquey specifies an object for the ife of the system. Object identifiers are never reused. When an object is created, the object ID is assigned by the system, whie the text name and type are specified by the programmer. Athough the contents and format of the encapsuated data in an object are not programmer accessibe, programmers must be abe to specify initia object vaues or examine an object s state. The System/38 instruction set uses tempates to convey initia information and communicate encapsuated data. A tempate is simpy a data structure with defined fieds used to transmit information at the instruction eve. For exampe, the CREATE QUEUE instruction needs to specify some information about the maximum number of messages, the size of messages, the queueing discipine, and so on. This information is 140 Figure 8-2. IBM System138 System Object

5 conveyed by creating a tempate in a space and specifying a capabiity to that space as a parameter to the instruction. Later, an instruction can be executed to produce a tempate showing information about the queue. Athough the architecture fixes the format of the tempate used to communicate information at the high-eve interface, it does not dictate how that information is maintained once it is encapsuated within the object. The ony object not containing a functiona part is a space object. A space object is a contiguous segment and is the ony object that can be manipuated at the byte eve by scaar instructions. A system object, then, is an instance of an abstract data type. System/38 instructions exist to create, manipuate, examine, and deete each of the system object types. The machine provides an interface that hides the impementation of an object from the user. An object s state is stored in one or more segments; its attributes incude a type that indicates what operations are aowed and an identifier that uniquey specifies the object. A base segment for each object contains pointers to any other segments composing the object, as we as type and ID information. 8.3 Object Addressing 8.3 Object Addressing Before examining object addressing in detai, it is necessary to describe memory management and segment addressing on the System38. Object addressing, using capabiities, is based on ower-eve segment addressing mechanisms Virtua Memory The IBM System38 architecture supports a fat, singeeve, 64-bit virtua address space. To the user at the high-eve interface (either the operating system or appication programmer), a addressabe objects and segments are in directy accessibe memory; there is no concept of secondary storage. The System/38 microcode is responsibe for moving segments between primary and secondary storage to create this virtua memory environment. The structure of a 64-bit virtua address is shown in Figure 8-3. The System38 segment size is 64K bytes. Each segment is divided into 512-byte pages. The ow-order 16 bits of the ad- 141

6 The IBM System p~o~i-- Segmeni Group Page Byte extended identification ID number offset L Figure 8-3: System138 Virtua Address dress thus provide the page number and byte offset for the. pages of a segment. For arger objects, up to 256 segments can be grouped together into segment groups. The group ID fied specifies which 64K-byte segment is being addressed within a 16M-byte segment group. The next 24 bits of the address provide a unique segment ID for the segment group. The System38 hardware ony supports 48-bit physica addresses composed of these fieds. However, when an object is created, the microcode extends the address to 64 bits by adding an additiona 16-bit fied. The fu 64-bit address is stored in a specia header with the segment. When a 64-bit address is used to access a segment, the upper 16 bits of the address are compared with the upper 16 bits of address in the segment s header. If a mismatch occurs, the addressed object has been destroyed and the reference is not aowed. At any one time, then, there can ony be 224 or 16 miion segment groups in existence. Because the address space is so arge, particuary with the i6-bit extension to the segment ID fied, segment IDS are never reused. The system assigns a new segment ID at creation that is unique for the ife of the system. If the object is deeted, references to the segment ID are not aowed. The system need not search for danging references when an object is deeted. The segment ID, therefore, provides a mechanism for determining the unique ID for system objects. System objects are named with the unique ID of the first segment containing the functiona portion of the object. The unique ID is the upper six bytes of the virtua address Pointers 142 As in other capabiity systems, objects as we as scaar data eements are addressed through capabiities. System/38 capabiities are known as pointers. There are four types of pointers in the System38:

7 system pointers address the 14 system object types (isted in Tabe 8-), space pointers address a specific byte within a space object (segment), data pointers address a specific byte within a space and aso contain attribute information describing the type of eement (e.g., character or decima), and instruction pointers address branch targets within programs. 8.3 Object Addressing Each System/38 pointer is 16 bytes ong. In order to access an object or an eement within a segment, a program must specify a pointer that addresses the object or segment eement. Pointers can contain different information at various times, incuding symboic text names, authorization information (access rights), the object type, and the unique ID for system pointers or virtua address for data and space pointers. The information within a pointer can be modified, for exampe, from text name to unique ID, to aow for ate binding of the pointer to the object. Unike the systems previousy examined, which use C-ists for the storage of capabiities, System38 pointers can be freey mixed in segments aong with scaar data. To aow storing of capabiities with data in the same segment whie sti maintaining capabiity integrity, the System38 impements a memory tagging scheme. Memory is byte addressabe and words are 32 bits ong. However, physica words of primary memory are actuay 40 bits wide. Invisibe to the programmer are a -bit tag fied and a 7-bit error correcting code. Pointers must be aigned on 16-byte boundaries. When a pointer is stored in a segment by a vaid pointer instruction, the hardware sets the associated tag bits for the four consecutive 32-bit words used to hod the pointer. Any instruction that requires a pointer operand checks that the pointer is aigned and that the four tag bits are set before using the eement for addressing. Program data instructions can freey examine pointers. However, if a program instruction modifies any data in a pointer, the microcode turns off the tag bit in the associated word or words, invaidating the pointer. Tabe 8-2 ists some of the instructions that operate on System/38 pointers. Note that a space object (a memory segment) is a system object that is addressed by a system pointer. A space pointer, on the other hand, is a capabiity that addresses a particuar byte in a space object. 143

8 The IBM System138 i44 ADD SPACE POINTER adds a signed offset to the byte address in a space pointer COMPARE POINTER FOR ADDRESSABILITY compares two pointers to see if they address the same object, the same space, or the same space eement RESOLVE POINTER searches a directory (see Section 8.3.3) for a named object and returns a pointer for that object SET DATA POINTER returns a data pointer for an eement in a space SET SPACX POINTER returns a space pointer for an eement in a space SET SPACE POINTER FROM POINTER if the source is a space or data pointer, creates a space pointer for the specified byte; or if the source is a system pointer, returns a space pointer for the associated space SET SYSTEM POINTER FROM POINTER if the source is a space or data pointer, returns a pointer for the system object conraining the associated space; if the source is a system pointer, returns a system pointer for that same object Tab/e 8-2: Contexts Svstemi38 Pointer Instructions Pointers are used to address objects; however, users refer to objects by symboic text names. System objects caed contexts impement directories for storing symboic object names and pointers. When a new object is created, its symboic name and an associated pointer are stored in a specified context. Tabe 8-3 ists the context instructions supported by the Systemi38. The symboic names stored in contexts are not necessariy unique, and a user can possess severa contexts containing the same name but referring to different objects. This feature aows for testing and ogica object substitution. A program that refers to an object by name can receive different objects depending on what context is used for name resourion. When a reference is made to a pointer containing an object name, the system examines the user s Name Resoution List (NRL). The NRL contains pointers to user contexts in the order that they shoud be searched. By changing the context ordering or manipuating entries, the user can change the objects on which the program operates.

9 CREATE CONTEXT creates a new context object and returns a system pointer to address it DESTROY CONTEXT deetes a context object MATERIALIZE CONTEXT returns name and pointer for one or more objects addressed by a context RENAME OBJECT changes the symboic name for an object in a context 8.3 Object Addressing Tab/e 8-3: System/38 Context Instructions Physica Address Mapping Because of the arge size of a System38 virtua address, standard address transation schemes invoving indexing of segment/page tabes with the segment/page number address fied cannot be used. Instead, the System38 hardware uses hashing with inked ist coision resoution to find the primary memory address for a specified virtua address. The basic units of physica and virtua storage are 5 12-byte pages. A transation scheme is used to ocate a page in primary memory. The upper 39 bits of a 48-bit virtua address, encompassing the unique segment ID, specify a unique virtua page address for the page. A hashing function is appied to these bits to obtain an index into a data structure caed the Hash Index Tabe (HIT), shown in Figure 8-4. The hashing function is an EXCLUSIVE-OR of ow-order bits from the segment ID and group ID fieds, and reverse-order bits from the page number fied. This function provides uniform mapping from the sparse address space to the HIT [Houdek 801. The HIT entry contains an index of an entry in the Page Directory Tabe (PDT). The PDT contains one entry for each page of primary memory. Each entry contains the virtua address of a corresponding primary memory page. That is, the index into the PDT is the page frame number for the virtua address described in the entry. Each entry aso contains a ink. The hardware checks the virtua address at the first entry pointed to by the HIT and foows the inked ist unti a virtua address match is found or the ist ends. If a match is found, the index of that entry is used as the page frame number in the primary memory address. If no match is found, the page is not 145

10 The IBM System I Wtua page address (Hash) Byte Virtua Address 4 Page directory index Hash index Tabe (H/U L--c Virtua address Link 1 (List search) Page Directory (PD T) Tabe Virtua address NM (P D T index) Physicai page frame Byte Physica Address Figure 8-4. System/38 Virtua Address Transation 146 in primary memory and the hardware must oad the page from secondary storage. The performance of this search depends on the uniformity of the hashing function and the ength of the ists in the Page Directory Tabe. In order to shorten the ist engths, the Hash Index Tabe is constructed to be twice the size of the Page Directory Tabe. Two optimizations are used to avoid this two-eve tabe search on every reference. First, the hardware contains a twoway associative transation buffer to cache recent address transations (the buffer size is different for different System38 modes, typicay 2 x 64 or 2 x 128 entries). To check the transation buffer, the virtua page fied is hashed to an offset that seects one entry in each haf of the buffer. The two seected entries, which contain a virtua page address and transated primary memory page frame number, are checked for a match. If the virtua address matches, the page frame number is used to construct the primary memory address. If no match occurs,

11 the tabe search proceeds, eventuay repacing one of the seected transation buffer entries with its data, based on a east recenty used bit. The second optimization is the use of resoved address registers in the hardware. These registers are used in the CPU to hod virtua page, physica page, and byte offset information whie a page is being processed. As ong as references are made to the addressed page (e.g., during the sequentia search of eements of an array), the hardware need not search the transation buffer for consecutive accesses. 8.4 Profies and Authority 8.4 Profies and Authority The System/38 hardware provides a mechanism for ensuring privacy and separation of data and for sharing information between users. The basic unit of computation, from which protection stems, is the process. Each user process is defined by a Process Contro Space object that contains its state. When a user ogs onto the system, a new process is created; a user profie object is associated with that process based on the user s name. The user profie contains: the user s name, the user s password, any specia authorization or privieges the user possesses, the maximum priority, the maximum storage usage, an initia program to run upon og-in (if any), a ist of objects that the user owns, and a ist of non-owned objects that the user is authorized to access, and the permitted authorities. A authority to perform operations on objects is rooted in the user profie. When an object is created, it is created with an attribute stating whether the object is permanent or temporary. The profie associated with the process issuing the CREATE operation on a permanent object becomes the owner of the object. An owner has a rights to the object and can perform any operations, incuding deetion. Temporary objects receive no protection and have no owner. They are destroyed when the system is booted. The owner of an object can grant various types of access to other user profies in the system. There are a number of authorities, or access rights, that a process can have with respect to an object. The authorities define what object operations the 147

12 The IBM System138 process can perform. The authorities aso define what operations can be performed on pointers for the object. Object authorities are divided into three categories: object contro authority gives the possessor contro of the object s existence (for exampe, the right to deete or transfer ownership), object management authority permits the hoder to change addressabiity (for exampe, to rename the object or grant authority to other profies), and operationa management authority incudes basic access rights to the contents of the object, such as retrieve, insert, deete, and update entry priviege. The authority information for each object is thus profie-based. Each user has a profie that indicates what objects are owned and what access is permitted to other objects. If a user wishes to aow access for an owned object to another user, the owner grants authority for the object to the sharer s profie. To execute a GRANT AuTHoRrTY instruction, a user must own an object or have object management rights. A user cannot grant an authority that the user does not possess. Tabe 8-4 ists some of the profie/authority management instructions supported by the Systemi38. These instructions aow a propery authorized user to grant access privieges to other users, to examine what objects are authorized to him or her, and to see what authorizations have been given to other users for owned objects. In addition to specific object authority granted to specific profies, each object can have an associated pubic authorization. The object s owner grants pubic authority with the GRANT AUTHORITY instruction by omitting the profie parameter. The pubic authority is stored in the object s header and aows any user to access the object in the permitted modes. When an attempt is made to access an object, the pubic authority is checked first. If the access is not permitted by the object s pubic authority, the user s profie is then examined Authority/Pointer Resoution Thus far, the System38 protection mechanism has been described from the perspective of the profie object. The profie provides a standard Access Contro List mechanism. The owner of an object can expicity permit other profies to have access to that object and can ater revoke that access.

13 CREATE USER PROFILE buids a new user profie (this operation is privieged) DESTROY USER PROFILE deetes a profie GRANT AUTHORITY grants specified authorities for an object to a specified user profie MATERIALIZE AUTHORIZED OBJECTS returns ist of a owned objects or authorized objects MATERIALIZE AUTHORIZED USERS returns a ist of owning or authorized users for a specified object RETRACT AUTHORITY revokes or modifies authority for an object from a specified user profie 8.4 Profies and Authority TEST AUTHORITY tests if specified authorities are granted to the current process for a specified object TRANSFER OWNERSHIP transfers ownership of an object to another profie Tab/e 8-4: System38 Authority Management Instructions The abiity to revoke object access is an important part of the System38 design; this feature has not been provided in any of the previousy examined systems. Revocation is, in fact, a difficut probem in capabiity systems and is generay expensive to impement in terms of addressing overhead. The IBM System38 design aows an object s owner to decide whether revocation is needed for the object. The System/38 provides two pointer formats: one for which access can be revoked and another for which access cannot be revoked. An object s owner can decide which type of pointer to use for each object in each instance depending on the reative importance of revocation and addressing efficiency. In order to access an object in the System38 a process must possess a pointer for that object. Pointers can be stored in two formats: unauthorized and authorized. An unauthorized pointer contains an object s unique identifier but does not contain authorizations (i.e., access rights) to the object. When an unauthorized pointer is used to access an object, the hardware checks the profie of the executing process to verify that the requested operation is permitted. Without this check, revoca- 149

14 The IBM System138 tion of authority woud be impossibe. An unauthorized pointer, then, cannot be used in the way that traditiona capabiities can be used. Additiona overhead is added to pointer usage because of the profie check. In cases where revocation is not required or higher performance is needed, access rights can be stored in a pointer, creating an authorized pointer. An authorized pointer acts as a capabiity, and reference to an object with an authorized pointer does not require a profie ookup. The RESOLVE SYSTEM POINTER instruction is used to create authorized pointers. An authorized pointer can ony be created by a user whose profie has object management authority for the object; the created pointer cannot have rights not avaiabe to the creating profie. Once constructed, an authorized pointer maintains authority to access an object for the ife of that object. The pointer can be stored and passed to other processes. Because the profie check is avoided with authorized pointer usage, authority cannot be revoked ater Programs/Procedures IBM uses the term program to refer to what is typicay caed a procedure or subroutine. A System38 program is an executabe system object. A program object is created by a CREATE PROGRAM instruction, which specifies a tempate containing System38 instructions and associated data structures. The CREATE PROGRAM instruction returns a system pointer aowing the program to be caed. As noted previousy, the System38 source anguage (i.e., the high-eve architecture interface shown in Figure S-) is reay an intermediate anguage produced by compiers. The effect of the CREATE PROGRAM instruction is to compie this intermediate anguage source into microcode that can be executed on the next owest eve of the machine. Source instructions, depending on their compexity, either compie directy into System38 vertica micro-instructions or into micro-procedure cas. The compied program is thus encapsuated in the program object, and the form of the micro-machine is hidden by the CREATE PROGRAM instruction. Once encapsuated, the format of a program object cannot be exammed. Thus, the System38 high-eve architecture is never directy executed. It is a specification for a anguage that a System38 impementations support; however, that anguage is transated

15 into a proprietary vertica micro-anguage before execution. The format of the encapsuated program in this micro-anguage cannot be examined and can be different on different System38 impementations. 8.5 Programs/Procedures The Instruction Stream The program tempate presented to the CREATE PROGRAM instruction consists of three parts: a program consisting of a sequence of instructions, an Object Definition Tabe (ODT), and user data. Each instruction consists of a number of 2-byte fieds incuding an operation code, an optiona operation code extender, and one to four operands. The operands can specify iteras, eements in space objects, pointers to system objects, and so on. The information about operand addressing and characteristics is stored in the Object Definition Tabe incuded in the tempate. The ODT is a dictionary that describes operands for the instruction stream. Each instruction operand contains an index into the Object Definition Tabe. The ODT actuay consists of two parts: a vector of fured-ength (4-byte) eements caed the Object Directory Vector (ODV), and a vector of variabe-ength entries caed the ODT Enty String (OES). An operand is either competey described by its 4-byte ODV entry, or the ODV entry has a partia description and a pointer into the OES, where the remaining description is found. Most commony occurring cases are handed by the fured-ength ODV itsef. Severa ODV entries can point to the same OES entry. The ODT can contain information such as operand type (e.g., fixed-ength decima string), size, ocation, aocation (static or dynamic), initia vaue, and so on. Figure 8-5 shows an exampe of an insrruction with three operands. The operands index ODT information defining their type and ocation. Each instruction operand consists of one or more 2-byte fieds. The first 2-byte fied contains a 3-bit mode fied and a 13-bit ODV index. The mode fied indicates what type of addressing is required and what additiona 2-byte fieds (caed secondary operands) foow in the instruction stream to describe the operand competey. For exampe, a string operand may require three 2-byte fieds to describe a base, index, and ength. 151

16 The IBM System138 Opcode Operands Opcode Operands -- Instruction - I I I I I I I Stream - Object Definition Tabe COD Ti 1 1 Binary (2) ISpacepointer( ( Figure 8-5 System/38 Exampe High-eve Instruction Since the ODT competey describes each operand, the scaar opcodes are generic. For exampe, there is ony one ADD NUMERIC instruction that operates on a numeric data types. The machine interprets the ODT entry to decide how the operation shoud be performed and what conversions are required. The Object Mapping Tabe (OMT) is the fina data structure that is part of the encapsuated program (athough not incuded in the initia tempate). It contains 6-byte mapping entries for each entry in the ODV that maps to a space Program Activation and Invocation A program, then, is a system object that represents a separatey compied unit of execution (typicay known as a procedure). Programs are caed by the CALL instruction. There are actuay two parts to the initiation of a program on the System/38: activation and invocation. Before a program can be invoked (caed), it must be activated. Activation of the program causes static storage for the program to be aocated and initiaized. Aso, any goba variabes in program static storage are made addressabe. A process data structure caed the Process Static Storage Area (PSSA) contains an activation entry for each activated program in the process. The activation entry contains status information, a count of the number of invocations using the activation, the

17 size of static storage, and the storage itsef. The first entry in the PSSA contains headers for the chain of activation entries and a free space chain. invocation occurs as the resut of a transfer of contro to the program. At invocation time, program automatic (that is, dynamic) storage is aocated and initiaized in a process data structure caed the Process Automatic Storage Area (PASA). Each invocation entry contains status information, a pointer to the previous invocation entry, a pointer to the program, and the automatic storage. After the invocation entry is aocated and initiaized, contro is transferred to the program at its entry point. Activation can occur impicity or expicity. If invocation is requested of a program that has not been activated, activation is done automaticay by the hardware. 8.5 Programs/Procedures Protected Procedures The IBM System38 provides a mechanism for creating protected subsystems. As on previous systems, a protected subsystem mechanism must aow programs to execute in an ampified protection environment. That is, some programs must be abe to access objects not avaiabe to their caer. Since the System38 profie object defines a domain of protection, protected subsystems are provided through profie-based faciities caed profie adoption and profie propagation. The authority of each System38 process is determined by its profie. When a process cas a program, that program generay gains access to the process s profne and, therefore, to the process objects. However, it is possibe to construct System38 programs that can access additiona objects not avaiabe to the caer. When a program is created, the program s owner can specify that the program retain access to the owneu s profie, as we as its caer s profie. This feature, caed profie adoption, aows a caed program to access objects not avaiabe to the caer and can be used to construct a protected subsystem. Athough the genera caing mechanism aows a caed program access to its caer s profie, a caing process can aso restrict this abiity. When a program is created, the program s owner can specify whether its profie shoud be propagated to programs on cas. Thus, a program can aso see that its owner s profie is protected from access by programs further down the ca chain. 153

18 The IBM System Specia Privieges It is worth noting that there are some specia privieges in the System38 authorization system. In addition to objectbased authorities stored in a user profie, there may be other permitted authorities that are not connected with any particuar object. For exampe, the abiity to create user profies, diagnose the hardware, or create objects representing physica I/O devices can be controed by authorizations in a user profie. Aso, the abiity to dump and oad objects to removabe storage is protected, as we as the abiity to execute operations to modify or service system hardware attributes. Finay, some objects, such as user proies and device descriptions, receive specia protection and can ony be addressed through a specia machine context (directory) Discussion The IBM System38 is a compex architecture constructed from severa eves of hardware, microcode, and software. Because of its commercia orientation and the fact that it is avaiabe from IBM, the System38 is probaby destined to become, at east in the immediate future, the most pervasive object architecture. The most interesting feature of the Systemi38, from the viewpoint of capabiity systems, is its use of tagging. Capabiities and data can be freey mixed in segments with no oss of integrity. The abiity to mix data and capabiities generay permits more natura data structuring than the C-ist approach. A singe tag bit associated with each 32-bit word indicates whether or not the word is part of a capabiity. This tag bit is hidden from the programmer and accessibe ony to the microcode. To be used for addressing, a pointer must be aigned on a 16-byte boundary and have a four tag bits set. The aignment requirement prohibits the user from specifying four consecutive words with tags set that ie within two contiguous capabiities. The integrity of a capabiity system must be ensured on secondary storage as we as in primary memory, and the pointer tags must be saved on secondary storage. On the System/38, each disk page is 520 bytes ong and stores a 5 12-byte data page and an 8-byte header. The 8-byte header for each bock contains the virtua address for the page, an indication of whether or not the page contains any pointers, and if so, which 16-byte quadword contains the first pointer in the page. Each

19 page can contain, at most, 32 pointers; therefore, ony 32 bits 8.7 Discussion are required to specify whether each quadword contains a pointer. If a page contains pointers, the tag bits are stored within some unused bytes in the first 16-byte pointer on the page. When a page is written to disk, the hardware automaticay writes the disk bock header. When a page is read into primary memory, the header is automaticay removed and the tags are reconstructed. The System38 architecture provides a arge singe-eve address space. The detais of memory management, I/O, and so on are hidden from the programmer. There is no need for a traditiona fie system. A objects can be decared permanent when created, can be stored for ong periods of time, and can be addressed at any time as if they were in primary memory. Addressing is independent of the object s memory residency characteristics. One probem with schemes that remove the abstraction of secondary storage is in transaction systems or reiabe data base operations. In some instances, the programmer may wish to ensure that the atest copy of a segment or object is checkpointed onto ong-term storage. The one-eve memory scheme has removed the abiity to express the thought of writing the segment to disk. To sove this, CPF aows an object attribute that states how frequenty data is to be backed up for a particuar object. The System 38 permits revocation by adding an access contro ist mechanism to the capabiity addressing mechanism. Two types of pointers, authorized and unauth&zed, can be used depending on whether or not revocation is required. Authorized pointers are traditiona capabiities because they contain access rights and can be freey copied. Passing an authorized pointer passes both the addressing rights and privieges. The abiity to resove a pointer to oad the access rights is controed by an authorized pointer authorization. Ony suitaby privieged profies can create an authorized pointer. In contrast, an unauthorized pointer is not a capabiity in the traditiona sense. The same unauthorized pointer can permit different types of access when used by different processes. This is because the authorization rights are fetched from the process s profie when a reference is made. This extra step in pointer address evauation permits expicit contro over authority and combines the advantages of standard capabiity systems and access contro ists. The user can specify (and determine at any time) what other profues are aowed access to the user s objects. If ony unauthorized pointers have been distrib- 155

20 The IBM System138 uted, access can be revoked by removing authorization from other profies. Unauthorized pointers permit revocation but add compexity to the handing of pointers. For exampe, to pass a pointer to another process, the possessor of the pointer must be aware of whether that pointer is authorized or unauthorized. Unauthorized pointers, unike capabiities, are not context independent. If the pointer is unauthorized, passing it to another process wi not permit object access uness permission has been granted to the other process s profie. Aso, unauthorized pointers cannot easiy be used to buid and share data structures. For exampe, if a user wishes to buid a tree structure of segments and pass the tree or subtrees to other processes, the authorization scheme requires that authorization for each segment be granted separatey to each profie invoved. The structuring of System/38 authorizations permits cose contro of pointers. Given the division of authority into object contro, management, and access, it is possibe for one user to be abe to affect the propagation of addresses but not be abe to access object data. Another user may be abe to read and write but not propagate pointers. The arge size of the System38 address space simpifies many probems. Segment identifiers are arge enough that they are never reused. This aows use of the segment ID as a unique name for an object. Since the ID is never reused, there is no probem with danging references. An attempt to access a deeted object simpy causes an exception. Large IDS aso simpify the impementation of the one-eve memory system. There is no separation of ong-term unique ID and address. The unique ID is the virtua address used to access a specific object, segment, or byte. There is no need for separate inform and outform capabiities or for transforming capabiities in memory when a segment is removed from memory. 156 Athough the System38 instruction stream and Object Definition Tabe are never used for direct execution, this interface has some interesting features. The ODT provides a form of tagging somewhat different from the tagged architectures examined earier. Each data eement is tagged; however, the tag is part of the operand, not part of the eement. This aows for severa different views of the same data eement; different instructions can treat the same word as different data types. Operation codes can be generic, and conversion, truncation, etc. can be performed based on type information in the ODT. The information stored in the ODT and I-stream may not be ex-