MULTICS TECHNICAL BULLETIN MTB-630
To: MTB Distribution
From: Richard Fakoury
Date: July 28, 1983
Subject: Dipper T&D on Multics
This MTB describes the Dipper T&D interface on Multics. It
discuss the communication that takes place between the user
running Tolts on Multics and the Maintenance Channel Adapter (
MCA ) which is the hardware module that actually does the
testing. This paper will discuss the MCA in its role of T&D
processor and how it fits into the general T&D scheme of things
in the Multics environment. It will attempt to make some
correlation to the way things are currently done and the way they
will be done in Dipper. This paper will also discuss some of the
security issues that have been raised and offers possible
solutions to these issues. This MTB will describe a test session
and attempt to highlight areas of interest as the test session
progresses.
Comments on this MTB may be made:
via Forum:
>udd>m>clj>mtgs>DIPPER_Development (nio)
via Multics Mail:
Fakoury.Tandd on System M
via telephone:
Richard Fakoury
HVN: 357-6545
DDD: 602-862-6545
_________________________________________________________________
Multics Project internal working documentation. Not to be
reproduced or distributed outside the Multics Project.
CONTENTS
Page
1.0 Background . . . . . . . . . . . . . . . . . . 1
2.0 Dipper User Interface . . . . . . . . . . . . . 2
3.0 A Basic Session . . . . . . . . . . . . . . . . 4
3.1 MCA Attachment . . . . . . . . . . . . . . . 4
3.2 MCA Communication . . . . . . . . . . . . . 5
3.3 Command Line Validation . . . . . . . . . . 5
3.4 Device Allocation . . . . . . . . . . . . . 6
3.5 Begin Testing . . . . . . . . . . . . . . . 6
3.6 Load Test Overlay . . . . . . . . . . . . . 6
3.7 Test completion . . . . . . . . . . . . . . 7
3.7.1 Normal Termination . . . . . . . . . . 7
3.7.2 User Requested Termination . . . . . . 7
3.7.3 Subsystem Fault . . . . . . . . . . . . 8
4.0 Security . . . . . . . . . . . . . . . . . . . 9
Multics Dipper T&D MTB-630
1.0 BACKGROUND
Dipper is the result of a dramatic change in large systems design
and packaging approach to controllers, device interfaces, and I/O
central subsystems. These changes were caused by a number of
factors and requirements that affects Honeywell's marketability
in the future. One of these requirements is that the I/O module
( IMU ), the IOM replacement, be capable of diagnosing problems
internally down to a board level. This must be achievable in
both an online and offline environment and the user interface
must be the same for both. To accomplish these requirements, it
was decided to include a micro processor in the design of the
IMU. This micro processor is the Maintenance Channel Adapter (
MCA ). The MCA is a dedicated maintenance processor within the
IMU, which drives a serial maintenance interface connected to
each of the Dipper subsystem components. It has a number of
tasks which include:
1. It is used to maintain a subsystem configuration which will
reflect the current state of the subsystem components.
2. It will boot the system as is now done by the IOM boot
channel.
3. It is used in the maintenance environment to run and control
tests and diagnostics for all of the Dipper components.
Some of these functions are replacements for existing
functionalities and some are new and unique. This paper will
discuss the MCA in its role of T&D processor and how it fits into
the general T&D scheme of things in the Multics environment. It
will attempt to make some correlation to the way things are
currently done and the way they will be done in Dipper.
Dipper on Multics will resemble in many ways the current mode of
operation. There are some areas where the current and Dipper
diverge but the basic precepts will remain the same. This will
be an attempt to document the interface between Multics and the
MCA as perceived by the writer at the time of writing and is
subject to change as the development cycle continues.
MTB-630 Multics Dipper T&D
2.0 DIPPER USER INTERFACE
The most notable user difference is in the command line to
initiate testing. Previously a test request was initiated by
entering ' test PICCDD ' where P = type of test to run, I = IOM,
CC = channel number, and DD = device number. For Dipper, this
was replaced by " a more user friendly interface " where the user
enters up to an 80 character command line which is identical to
the offline environment. The test line will be of the following
format:
test < target > via < path > using < technique > [options]
Where target consists of one of the following:
1. IMU - used to run diagnostics on the IMU central.
2. PS - port select to designate the port select function of
the IMU.
3. PA X - select port adapter ' X '.
4. IPC XX - integrated peripheral controller designated by ' XX
'.
5. PUNCH X - run diagnostics on a card punch device type ' X '.
6. INTERFACE - run diagnostics on the IMU internal bus.
7. HELP - request assistance with format.
Where path is one of the following:
1. IMU X - designates which IMU subsystem ' X ' to use.
2. IMU X IPC XX - designates the IMU subsystem ' X ' and the
IPC ' XX '.
3. IMU X IPC XX PORT XX - designates the complete path to a
unit record device.
4. HELP - request help with format.
Multics Dipper T&D MTB-630
The technique field specifies the type of diagnostic to run.
These include:
1. DIAG - a technique to comprehensively test the target using
a variety of tests methods.
2. DISP - invokes the Native Fault Tests ( NFT ) maintenance
panel functions.
3. DPM - ( Diagnostic Procedure Module ) a manually coded
diagnostic tool that uses the shift register paths as a test
vehicle.
4. QRY - a technique to invoke microprocessor based maintenance
panel functions.
5. NFT - use only NFT testing.
6. SELF - the MCA runs internal tests.
7. HELP - assist in formatting.
MTB-630 Multics Dipper T&D
3.0 A BASIC SESSION
The session begins with the user either logging in under the
Tolts project or invoking Tolts by calling ' bound_tolts_$tolts_
'. Either way the user enters the Tolts environment at the same
place. It is here the user's access to system gates and data
segments is verified. If for any reason the user has
insufficient access, Tolts will terminate with an error message.
If the person is logged in under the tolts_overseer_ he is logged
out. After these checks, the user has at least passed a
rudimentary security check, and should be allowed to proceed.
These gates and data segments that are checked are:
1. >sl1>phcs_
2. >sl1>tandd_
3. >sc1>opr_query_data
4. >sc1>cdt
5. >sc1>rcp>tandd.acs
Next the user is prompted for what type of exec he wishes to
invoke. In this discussion, he will select Molts as this is the
only subexec that will run the MCA tests.
3.1 MCA Attachment
Molts will be loaded as is done now and brought into execution.
The first thing Molts does is request input from the user as to
what activity is to be performed by printing ' ??? ' on the
user's terminal. The user will then reply with ' test nioI '
(where ' I ' is an IMU number). If ' I ' is not given, Molts
will terminate the request.
Molts will verify the accessibility of the MCA by attempting to
allocate the MCA though Tolts. When Tolts receives the request
to attach the MCA, a validity check will be made against the
configuration deck. If the requested IMU number corresponds to
valid Dipper subsystem, a request will be made of the operator
via an opr_query_ request requesting permission to run an MCA
test. If granted, Tolts will then do an rcp_priv_$attach of the
MCA.
3.2 MCA Communication
When the MCA is attached to the requesting process, Molts will
load and put into execution the MCA Driver (MCAD), which will do
Multics Dipper T&D MTB-630
the actual communicating with the MCA. Communication with the
MCA is accomplished via three idcws. These idcws are:
1. write text - idcw command (B0 - B5) = 13 with B22 (c bit)
set. This idcw is the only one that can be used to start a
test session and must be chained to an idcw type 03.
2. write data - idcw command = 15 with B22 set. This idcw is
used to transfer data to the MCA and must be chained to an
idcw type 03.
3. request MCA response - idcw command = 03 and B22 reset.
This idcw requests a response from the MCA.
3.3 Command Line Validation
MCAD will request from the user a command line with a prompt of '
enter nio request ', which will be sent as data to the MCA using
an idcw 15. The MCA exec will recognize the data as a test
request and request that the Maintenance Executive be loaded into
the MCA overlay area where it will be placed in execution. MCAD
will perform a MME CATA followed by a MME DATA to get the
Maintenance Executive from the deckfile. MCAD will send
Maintenance Executive via channel 3 to the MCA using an idcw with
a command of 15.
The Maintenance Executive will parse and attempt to validate the
test request. If the request is invalid for any number of
reasons, ie. format, invalid device, or a field with ' help '
request inserted. The Maintenance Executive will attempt to
assist the user in formatting a valid test request by responding
to the outstanding read with the appropriate action that it
requires MCAD to take. This could be a write/read to the user
terminal, reading a help file from the deckfile, or whatever else
that is required to obtain a valid test request. When a test
request is determined by the Maintenance Executive to be valid,
the Maintenance Executive will "echo" the test request back to
MCAD, with the message header block containing a code that MCAD
will recognize as a valid test request is available. The user
will then be queried by MCAD as to the correctness of the test
request by reprinting the test request followed by the question
"Correct (y or n)". If the response is ' n ' , then MCAD will
terminate the test request and wrapup. If the reply is ' y ',
MCAD will reply with a negative response to the Maintenance
Executive which will cause the Maintenance Executive to wrapup.
The reason this is done is to allow the MCA to handle the
upcoming request to read the configuration deck initiated by
Molts.
MTB-630 Multics Dipper T&D
3.4 Device Allocation
MCAD will perform an as yet unnamed MME that will pass to Molts
the valid test request. Molts will then read the MCA
configuration deck using an idcw 15 to determine what devices are
required to execute the test request and then request Tolts to
allocate the devices for testing. Each device requested will be
validated against the Multics configuration deck and the
associated devices will be attached using rcp_priv_$attach as it
is done today. If all requested devices can not be attached,
Molts will close out the request and wrapup. If all devices are
attached, Molts will notify MCAD of the successful attachments.
3.5 Begin Testing
MCAD will send the command line to the MCA using an idcw of 13
(write text command). This is the only time during the
maintenance session that the idcw 13 will be used. All other
idcw requests will utilize the idcw 15 chained to an idcw 03.
This will allow ioi an opportunity to also read the MCA
configuration and validate the test request. If the request is
valid, it will be sent to the MCA where the MCA Executive will
detect the presents of a ' test ' request and request that the
Maintenance Executive be loaded and placed into execution as
previously described. The MCA Executive will then pass the
command request to the Maintenance Executive which will
revalidate it as a valid request and echo this back to MCAD who
will then reply with an affirmative response to the Maintenance
Executive.
3.6 Load Test Overlay
The Maintenance Executive will then interpret the command line
and request that the appropriate Test Driver be sent to the MCA,
where it will be loaded in the overlay area overlaying the
Maintenance Executive. The Test Driver will then request that
each test case be loaded and executed individually. Each test
case will be sent using an idcw 15 which will send the test case
to the MCA followed by an idcw 03 which will keep the IO
outstanding to the host and provide a means for the MCA ( Test
Driver ) to reply with the results of the test. When a
particular test is completed, the Test Driver will request that
the Maintenance Executive be loaded into the overlay area and
placed back into execution. The Maintenance Executive will
determine the mode it is running, ie. if only one test or
multiple test mode.
Multics Dipper T&D MTB-630
3.7 Test completion
Testing will continue until one of three events occur. These
events are:
1. normal test termination.
2. user elected termination.
3. subsystem fault.
3.7.1 NORMAL TERMINATION
Normal termination will occur when the Maintenance Executive
determines that all test that are scheduled to run have been run
to completion. The Maintenance Executive will then do some
housekeeping and wrapup by sending a normal terminate to MCAD and
returning control to the MCA Executive. MCAD seeing the normal
terminate will also wrapup to Molts, who will then read the MCA
configuration to determine the state of the hardware that was
tested. This state is reflected to Tolts when Molts does a MME
RELEASE. Tolts will then verify the users access to
>sc1>rcp>mca_mp.acs. If the user does not have sufficient
access, Tolts will do a normal rcp_$detach. Multics will verify
the state of the resource by reading the MCA configuration. If
the flag ' F/W load required ' in the MCA configuration is set
Multics can have MCA reload the firmware. If the user has
sufficient access, Tolts will query the user if firmware should
be reloaded. If the user replies "yes", Tolts will do a normal
rcp_$detach as above and the sequence is the same. If, however,
the user replies "no", Tolts will do a
rcp_$detach_no_firmware_load. RCP will verify user access and
release the resource and notify the system operator that the
resource has been released with no firmware reload.
3.7.2 USER REQUESTED TERMINATION
The user will request termination by depressing the break key,
which will cause a prompt of ' ??? ' to be printed on the user
terminal. The user will then input a ' test neio ' request which
will then be passed to Molt where it will be interrupted as a
termination request. Molts will notify MCAD that it has a
termination request which will be passed to the overlay module
currently running in the MCA. If the Maintenance Executive is
not in operation at this time, it will be reloaded and put into
execution after the module that was currently running cleans up.
The remaining sequence is the same as for a normal termination.
MTB-630 Multics Dipper T&D
3.7.3 SUBSYSTEM FAULT
If a subsystem fault occurs while T&D is in operation, the
overlay in operation is terminated and a status is returned to
MCAD stating abnormal termination system fault. The fault
handling overlay will then be loaded into the overlay area and
placed into execution by the MCA. MCAD will then cleanup as
previously stated.
Multics Dipper T&D MTB-630
4.0 SECURITY
There has been a lot of discussion on permitting Tolts to run T&D
through the MCA. The major complaint has been the feeling that
security has been compromised by allowing the MCA run the test.
It is felt that Multics loses control once it passes the MCA a
command line. I am of the opinion that although the actual test
pages that are run in the MCA do not meet the all levels of the
Multics design specifications, it is not much different than what
is done today when running with the MPC. The only guarantee that
these devices perform as specified is that all operating systems
run the same firmware and test pages and therefore are thoroughly
exposed. Also on Multics, access can be restricted to the MCA
and its associated test pages to any degree that a site elects.
I will attempt to discuss some of the ideas I have concerning
this matter.
1. Access to the MCA can be controlled by Multics as disks are
controlled now. The device can be attached by rcp at boot
time and for a user to use the MCA, the system operator
would be required to use the set_device_usage command to
allow a user to attach it.
2. Access to the MCA can also be controlled by an acs seg in
>sc1>rcp which will be checked by rcp during attachment.
3. The firmware, which is read from a diskette attached to the
MCA should only be loaded by Multics. This will ensure that
only firmware that was used by the MCA, initially at
bootload will be reloaded. Multics will be able to verify
the state of the resource in question as well as the
validity of the firmware diskette. Having Multics
controlling the firmware reload will place the final state
of the device back into the Multics security kernel.