Multics Technical Bulletin MTB-713 MR11 Config Mgmt To: Distribution From: Benson I. Margulies Date: 05/17/85 Subject: MR11 Configuration Management 1 1 ABSTRACT Configuration Management is the management of changes to systems. For Multics, Configuration Management is the way that we propose, review, implement, and track software changes. This paper briefly characterizes our existing procedures. Comments should be sent to the author: via Multics Mail: Margulies at either System-M, MIT, or CISL-SERVICE. via Forum: >udd>m>mtgs>B2 on System-M via telephone: (HVN) 492-9333, or (617) 492-9333 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project without the consent of the author or the author's management. MTB-713 Multics Technical Bulletin MR11 Config Mgmt 2 INTRODUCTION This document describes the software configuration management procedures the govern Multics software development. The responsibility for the enforcement of these procedures resides with the unit managers, who sign MSCR forms. 3 CHANGE INITIATION Changes to Multics begin with individual members of the development community (contributors). Contributors change the system because: * They have an idea for an improvement to the system. * They respond to a requirement formally presented through management channels. * They respond to a reported bug. 4 CHANGE DESCRIPTION No change may be included in the system under these procedures unless approved by peer review. To present a proposed change for peer review, a contributor must describe it in a document. The form of the description required depends on the size of the change. If the change is large, she first must prepare a Multics Technical Bulletin (MTB), a detailed description of her proposed design. After the MTB has been reviewed (see below), she must prepare a Multics Change Request (MCR) to formally request technical approval of her change. If the change is small, she may skip the MTB, and start with the MCR. In either case, she is required to describe: * Any new or changed user interfaces to the system. * Any new or changed internal interfaces that are usable outside of their particular area of the system. * Any significant new or changed: - data structures - design philosophies, in particular security policies In short, she must provide enough information for her technical peers to intelligently evaluate her proposal. In particular, note that she must provide a complete description of Multics Technical Bulletin MTB-713 MR11 Config Mgmt any changes to interfaces that are described in published documentation. This description is used by the Documentation Unit to prepare user documentation. She need not provide a complete and detailed description of her proposed implementation unless the area of the system is one so crucial that prior technical review to that level is required. This requirement is established on a case-by-case basis by the peer review system. 4.1 Describing a Change With an MTB Contributors write MTB's to describe large or complicated system changes. In particular, a contributor will write an MTB when she thinks that the change meets any of the following criteria: * The change will change the central design philosophy, data structures, or security policy of the system or one of its subsystems. * The change will add a new subsystem to the system.(1) * The documentation required will be more than several pages. * There are design issues where she is not sure of the correct solution, or where others are likely to disagree.(2) 4.2 Describing a Change With an MCR An MCR is a brief specification of a change to the system. Contributors prepare MCR's by filling out a standard form which describes the change.(3) Contributors write MCRs for changes that are not large enough to meet the criteria given above for MTB's, and to request final approval of the installation of changes described in MTB's. _________________________________________________________________ (1) By "subsystem," we usually mean a significant body of code that can be provides a set of related functions, and has a clear modularization that separates it from the rest of the system. Page control, RCPRM, and the directory salvager are all examples of subsystems. (2) Examples of MTB's can be found in the on-line library. (3) See Attachment 1 for an example. MTB-713 Multics Technical Bulletin MR11 Config Mgmt 2.3 Technical Change Review All change proposals are reviewed by the entire development community. The focal point of technical review is the "MCR Board". This board, which is described in more detail below, reviews both large (MTB) and small (MCR) proposals. Note, though, that the Board does not directly examine MTB's. Instead, the author of the MTB conducts a "design review" in which a small group of other knowledgable contributors examine the proposal in detail. When the design review is complete the MTB is updated to reflect its results and presented to the MCR Board. 4.1 Design Review To conduct a design review, a contributor must find several others who are knowledgable in the area. Each of these people reads the proposal, and comments on its content. The contributor must resolve all questions, complaints, and suggestions. Ordinarily, she will seek a consensus of the reviewers. When no consensus is available, she must make her own decision. When the design review is complete, the contributor must make its results available to the community. This facilitates the next step in the review process. If the design review resulted in any significant changes to the proposal, she must revise the MTB to reflect the changes. If there were significant disputes, and especially if there were issues on which no consensus was reached, she must prepare an additional MTB that describes the disputes and their resolution, if any. Once these steps are complete, she may proceed to MCR Board review of her proposal by preparing an MCR that offers her original MTB and the design review results MTB, if any, for review. 4.2 The MCR Board The MCR Board considers MCR's (and associated MTB's) submitted by contributors. 4.2.1 SUBMITTING AN MCR To submit an MCR for consideration, a contributor must first obtain the approval of two individuals: the sponsor and the manager. The sponsor of an MCR is a contributor who is willing to take for its correct format. The sponsor must check that the MCR is complete. For TCB-related MCR's, the sponsor also takes responsibility for its technical plausibility. The sponsor must Multics Technical Bulletin MTB-713 MR11 Config Mgmt be a contributor with some detailed knowledge of the area of the system involved. The manager listed on an MCR is the individual's unit manager. The manager puts her name on the MCR to indicate that she has checked the MCR for correct form, has insured that the submittor has indeed chosen an appropriate sponsor, and that she has committed the necessary development resources to implement the change. 4.2.2 REVIEW OF MCR'S MCR's are initially reviewed by the General MCR Board (GMCRB), which consists of all of the contributors in the Multics development organization who are willing to take the time. GMCRB members discuss the MCR amongst themselves. The discussion process may include friendly amendments. If no problems with the MCR surface during the GMCRB review, the MCR passes. If an MCR proves controversial, it is referred to the Executive MCR Board (EMCRB). This much smaller group has the final technical say. 5 IMPLEMENTATION When the MCR Board has approved an MCR, the contributor proceeds to implement the change. Ideally, no implementation precedes the review process. In fact, some implementation is often required to discover a feasible or optimal design to propose. The crucial requirement is that a contributor is obligated to implement the design as approved by the review process. If she has implemented in advance of approval, and the final, approved, design is different, she must change the implementation to conform to it. The implementation must conform to coding standards. There are two sources of standards. The first is the Multics Programming standards SDN (AN-82), which provides some guidelines for writing efficient, readable Multics PL/I programs. The second is a body of unwritten requirements, which includes guidelines for ALM programs and programs that run in special environments. The TCB is such a special environment, and the rules for gate parameter handling are amongst the unwritten programming standards. In general, a programmer must make her program look like other programs in the same subsystem. If she does not, she must have a good reason. MTB-713 Multics Technical Bulletin MR11 Config Mgmt The implementation process includes testing and limited exposure. Contributors may expose code by running it on the CISL Multics system, or in the experimental libraries on MIT, CISL, ACTC, or System-M. 6 AUDIT When the implementation is complete, the contributor proceeds with audit. An audit is a independent verification that the implementation meets its requirements. Amongst the requirements are these: * It must conform to the approved design. * It must conform to coding standards. Since not all the coding standards are formal, written, requirements, some negotiation may occur between the auditor and the implementer. * It must have been adequately tested. * It must have no bugs visible to the auditor's eye. An audit is performed by one or more other contributors, called auditors. An auditor must be a contributor who is technically knowledgeable in the area changed. The implementer must provide the auditor with: * A copy of the MCR(s) and MTB(s) (if any) that describe this change. * A set of "installation forms" which specify the modules changed and describe how these changes are to be installed in the system libraries. * A listing of each new or changed module. * A computer generated comparison between the version of the module currently installed in the system libraries, if any, and the new version. The Multics tools for this purpose (compare_ascii and compare_pl1) show additions, deletions, and changes on a line-by-line basis. The contributor changes the code as needed to correct deficiencies found by the auditor. The changed code is re-tested as needed. The auditor may check to see that the deficiencies have been corrected. Once the audit changes have been made, no further changes are made to the code as part of this change. Multics Technical Bulletin MTB-713 MR11 Config Mgmt 7 INSTALLATION IN THE SYSTEM LIBRARIES Multics Administrative Bulletins MAB-56 and 57 document the standards and procedures for installations. What follows is a brief summary. 7.1 Submission The contributor makes her change part of the system libraries by submitting it to the installers. She prepares a set of installation forms, which detail the names of the changed modules. The installation forms are accompanied by the approved MCR or MCR's, and are signed by the submitter, the auditor, and the submitters manager. If the change requires changes to user documentation, she gives draft documentation of the necessary changes to the designated liason of the Documentation Unit, and receives in return her signature. When the forms are complete, and carry all required signatures, they are sent to the installers. 7.2 Installation First, the installers make the final checks on the submission. They verify the presence of the appropriate MCR's and signatures. Second, the installers check for completeness. They use library crossreference tools to verify that all the modules affected by the installation are in fact included. Third, the installers recompile all sources to insure that they install clean object modules. Fourth, the installers run tests for major changes. The Multics Hardware Acceptance Tests (MHAT) run a wide variety of Multics applications, and validate the results. Finally, they install the changed modules in the system libraries, and file the installation forms permanently. 7.3 Emergency Procedures Contributors use emergency procedures to supply solutions to critical problems that effect the exposure sites or the field. MTB-713 Multics Technical Bulletin MR11 Config Mgmt There are two procedures. Emergency Change Requests (MECR's), described in MAB-57, are used to submit emergency changes to the exposure sites. Critical Fixes are used to make emergency changes available to the field. A contributor prepares an emergency change in response to a report of a critical problem. She does as much testing as is possible, though the difficulty of reproducing one of these problems on the available test systems may preclude exhaustive tests. She recruits another contributor to perform a cursory audit. She then submits the change to her manager and to the emergency installation coordinator, who is one of the installers. The installers install the change on System-M, and enter it in a tracking database. If the problem effects the field, the contributor notifies the Critical Fix coordinator. The Critical Fix coordinator prepares source comparisons to the released version of the system, and makes them available to representatives of customer sites. Once the emergency change is installed, the contributor must make a normal design proposal for the change, as described above. The review process may require changes in the design. She must submit the code to a full audit, and resubmit the change as a normal installation. Only after all of these steps is the MECR considered "cleared." 7.4 Other Checks The installers make a monthly performance run to check the system performance implications of all installed changes. The performance run includes a wide variety of application programs, and often uncovers functional bugs. 8 EXPOSURE Multics system releases are exposed on three systems. System-M, the production system in Phoenix, AZ is a large, heavily loaded configuration with a diverse user community. Releases are exposed there for two months before shipment to customers. During the entire release development period, new software is exposed on the service machines of the CISL (Cambridge, MA) and ACTC (Calgary, AB) development centers. Multics Technical Bulletin MTB-713 MR11 Config Mgmt ATTACHMENT 1, A TYPICAL MCR _________________________________________________________________________ | Ver. 7 | | | 02/29/84 MULTICS CHANGE REQUEST | MCR______________ | |___________________________________________________|_____________________| | TITLE: Null the ACL of the gate r1_io_ | | | | AUTHOR: Benson I. Margulies <Margulies> | | SPONSOR: Greg Baryza MANAGER: Greg Baryzas | |_________________________________________________________________________| | CHARACTERISTICS | STATUS DATE | | Fixes Error Number(s): | Written: 03/06/85 | | PFS Item for Release: MR11 | Status: | | Targeted for Release: MR11 |_____________________| | Documented in MTB: 662 | CATEGORY | | Performance: same | Ring One | | New Non-pl1 Programs: no | | | Incompatible Change: yes | | | User Interface Change: no | | |___________________________________________________| | | DOCUMENTATION CHANGES | | | SRB Notice: yes | | |___________________________________________________|_____________________| | OBJECTIONS/COMMENTS: | | | | | |_________________________________________________________________________| SUMMARY: Remove cross_ring_io_ capabilities from the default TCB by nulling the ACL of the gate r1_io_. REASONS: We have discovered an inherent security flaw in the design of cross_ring_io_. Since there is no way to correct it, we must remove cross_ring_io_ from the TCB. IMPLICATIONS: Sites that have cross_ring_io_ applications in ring 1 will have to reset the ACL. SRB NOTICE: The default acl to the gate r1_io_ has been changed to null to *. This is because there is an inherent security flaw in the design of cross_ring_io_, such that it cannot be used to allow a non-trusted outer ring process to do I/O in the inner ring. We recommend against ANY use of cross_ring_io_. If you have existing applications, you should convert them to having a special purpose gate. DETAILED PROPOSAL: The SAP should carry a disclaimer like the above for all of the rN_io_ gates.