Multics Technical Bulletin                                MTB-713
MR11 Config Mgmt

To:       Distribution

From:     Benson I. Margulies

Date:     05/17/85

Subject:  MR11 Configuration Management


     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


     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.


     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.


     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

     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

     *    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

     *    There are  design issues where  she is not  sure of the
          correct  solution,  or  where   others  are  likely  to

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.


     To submit an MCR for consideration, a contributor must first
obtain  the approval  of two  individuals:  the  sponsor and  the

     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.


     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.


     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.


     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

     *    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

     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


     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

     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.


     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


| 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.


The SAP should carry a disclaimer like the above for all of the rN_io_