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.