.TITLE ^^MSX - A\\ ^SECURITY - ^HARDENED ^DISTRIBUTED ^O^S
.SPACING 1
.PAPER SIZE 80,58
.FLAGS CAPITALIZE
\\
.CENTER
^^MSX - A\\ ^SECURITY ^HARDENED ^DISTRIBUTED ^OPERATING ^SYSTEM
.SKIP 3
.CENTER
BY
.SKIP 3
.CENTER
^GLENN ^C. ^EVERHART
.PAGE
.CENTER
<INTRODUCTION
.PARAGRAPH
^IN RECENT YEARS, IT HAS BECOME CLEAR THAT A VARIETY OF GOVERNMENT
AND COMMERCIAL APPLICATIONS REQUIRE COMPUTING POWER WHICH CAN
SURVIVE LOSS OF SOME RESOURCES AND PERMIT RECONFIGURATION TO
CONTINUE TO EXECUTE APPLICATIONS CODE. ^IT HAS ALSO BECOME
CLEAR THAT MANY APPLICATIONS NEED TO BE ABLE TO PROCESS DATA OF
DIFFERING DEGREES OF SENSITIVITY WITHOUT VIOLATING DISCLOSURE
POLICIES OR LAWS. ^FOR THESE REASONS, AN EFFORT WAS MADE TO CONSTRUCT
A TRIAL OPERATING SYSTEM WHICH WOULD PROVIDE THE DESIRED
RECONFIGURABLE, FAIL-SOFT BEHAVIOR ON A COLLECTION OF LOOSELY TO
MODERATELY COUPLED MINICOMPUTERS, WHILE ENFORCING THE <DOD SECURITY
POLICY, A POLICY WHICH PROVIDES HIERARCHIES OF ACCESS CLEARANCES WITHIN
SPECIAL COMPARTMENTS AND WHICH HAS RECEIVED CONSIDERABLE ATTENTION
IN DEVELOPMENT OF SECURE SINGLE-COMPUTER KERNELS. ^THIS REPORT
DESCRIBES THE RESULTING SYSTEM, CALLED <MSX (FOR ^MULTI- ^SYSTEM
E^XECUTIVE).
.PARAGRAPH
^CENTRAL TO DISTRIBUTING A COMPUTING JOB IS THE NOTION OF HOW PROBLEMS
ARE TO BE DECOMPOSED. ^HERE THE CONCEPT OF A "TASK" IS USED, MEANING
THE SMALLEST EXECUTABLE UNIT OF CODE KNOWN TO THE SYSTEM. ^APPLICATIONS
ARE COMPOSED OF SETS OF ONE OR MORE TASKS, EACH TASK RUNNING ON ONE
<CPU AND GLOBALLY NAMED, WHICH COMMUNICATE WITH EACH OTHER. ^BECAUSE
OF THE AVAILABILITY OF A DEVELOPMENT MACHINE, THE <DEC <PDP11 WAS
CHOSEN AS THE TARGET PROCESSOR, AND <MSX WAS CODED (FOR HISTORICAL
REASONS) IN ITS ASSEMBLY LANGUAGE.
^HOWEVER, THE PRINCIPLES OF THE SYSTEM ARE LANGUAGE INDEPENDENT, AND
IT COULD BE RE-IMPLEMENTED IN A SYSTEM IMPLEMENTATION LANGUAGE
SHOULD IT BECOME DESIRABLE TO DO SO. ^IT PROVIDES A PROGRAM
ENVIRONMENT SUPPORTING DYNAMICALLY LOCATED TASKS AND INTERTASK
COMMUNICATIONS IN WHICH ONE CAN DEVELOP APPLICATIONS FOR A MULTILEVEL
SECURE ENVIRONMENT AND STUDY, ON A PER APPLIACTION BASIS, THE INTERACTIONS
OF FAULT RECOVERY AND SECURITY.
.PARAGRAPH
<MSX IS DESIGNED TO PERMIT CONNECTION OF A MODERATE (255 MAXIMUM BUT
MORE TYPICALLY 25 OR LESS) NUMBER OF PROCESSORS, EACH EXECUTING A
VARIABLE NUMBER OF TASKS. ^THE CONNECTION WILL NORMALLY BE BY INTER-
PROCESSOR LINKS BUT MAY BE PARTIAL SHARED MEMORY. ^IT WAS DETERMINED
THAT THE VARIOUS TASK COMMUNICATION AND SYNCHRONIZATION FUNCTIONS OF
THE SYSTEM WOULD REQUIRE 20 TO 25% OF THE TABLE ENTRIES IN THE SYSTEM'S
^TASK ^LIST ENTRIES, EVEN FOR TASKS RESIDENT ON OTHER <CPU\S, SO THE
SYSTEM WAS DESIGNED TO SUPPORT GLOBALLY NAMED TASKS AND USE THE SAME
TABLE FORMAT REGARDLESS OF A TASK'S LOCATION. ^THIS ALSO SIMPLIFIED
ALLOWING SHARED ^SYSTEM ^TASK ^LIST MEMORY. ^BECAUSE GLOBAL NAMING
REQUIRES USE OF MORE ADDRESS SPACE IN EACH <CPU'S <MSX KERNEL, THE
<MSX SYSTEM WAS DESIGNED TO SUPPORT THE <PDP11'S MEMORY MAPPING
HARDWARE AND ALLOCATE SEPARATE ADDRESS SPACES FOR THE <MSX KERNEL
AND FOR EACH TASK. ^THUS, EACH <MSX TASK MAY HAVE UP TO THE FULL
64<KB ADDRESS SPACE PERMITTED IN A 16 BIT ARCHITECTURE.

.SKIP 3
.TEST PAGE 20
.CENTER
^BASIC ^SYSTEM ^FEATURES
.PARAGRAPH
<MSX IS A PREEMPTIVE, DISTRIBUTED, UNWAITED, SECURITY-CONSCIOUS,
MULTIPROGRAMMING, MULTIPROCESSOR,
HOMOGENEOUS OPERATING EXECUTIVE SUPPORTING HIERARCHICALLY STRUCTURED
PROGRAMS, LIMITED DYNAMIC LOAD BALANCING,
AND ERROR RECOVERY PROTOCOLS, PRIMARILY
IN SUPPORT OF REAL TIME APPLICATIONS.
^THE FOREGOING STATEMENT GIVES
THE BASIC DESIGN CHOICES THAT HAVE BEEN MADE. ^THE RATIONALES FOR
THESE DECISIONS WILL BE GIVEN.
.P
<MSX ATTEMPTS TO PROVIDE ITS "REAL TIME" RESPONSE BY ARBITRATING
WHICH OF ITS TASKS IS TO BE RUN ANY TIME IT IS SIGNALLED BY SOME
EVENT THAT THE CONTEXT MIGHT NO LONGER BE THE HIGHEST PRIORITY
TASK TO RUN. ^THIS MAY INVOLVE SAVING THE CONTEXT OF WHATEVER
PROGRAM IT IS THEN RUNNING ON A GIVEN <CPU AND STARTING ANOTHER.
^THUS, IT IS A PRE-EMPTIVE SCHEDULER.
^IT WAS FELT THAT NOT PREEMPTING RUNNING TASKS WOULD MAKE IT
NECESSARY FOR PROCESSES RUNNING UNDER THE EXEC TO BE LIMITED TO
SOME FINITE RUNTIME IN ORDER TO PROVIDE TIMELY RESPONSE TO
OUTSIDE EVENTS. ^THUS, PREEMPTION WAS CHOSEN AS THE SCHEDULING
PHILOSOPHY, EVEN THOUGH IT MAKES IT NECESSARY FOR <MSX TO MAINTAIN
SEPARATE CONTEXTS FOR EACH PROCESS AND THUS SOMEWHAT INCREASES
TASK SWITCHING TIME. ^IT TURNED OUT THAT THE EXISTENCE OF THESE
STATES MADE IT EASIER TO "MARK TASKS FOR ABORT" IN MAINTENANCE OF
TASK HIERARCHIES THAN IT MIGHT HAVE BEEN OTHERWISE, SO THERE HAVE
BEEN BENEFITS THAT WHICH WERE NOT OBVIOUS INITIALLY.
^EACH PROCESSOR MAY HAVE
SEVERAL PROGRAMS ACTIVE AT ANY MOMENT (MULTIPROGRAMMED), AND
THERE MAY BE SEVERAL PROCESSORS. ^THE SYSTEM EXECUTES ON <PDP11
PROCESSORS ONLY, THOUGH IT WILL SUPPORT ANY BUT THE SMALLEST
MODELS OF <PDP11. ^THE NORMAL WAY USER PROGRAMS (CALLED "TASKS"
HERE) INTERACT WITH THE SYSTEM IS TO EXECUTE <DIRECTIVES TO
PERFORM VARIOUS SERVICES.
^ONE OF THE KEY CHOICES IN DESIGN WAS TO ALLOW RETURN TO THE USER
TASK AS SOON AS POSSIBLE AFTER A DIRECTIVE WAS SPECIFIED, RATHER
THAN FORCING THE APPLICATION TO WAIT UNTIL ALL CONSEQUENT ACTIONS
(E.G. MESSAGE RECEPTION) TOOK PLACE. ^METHODS WERE PROVIDED TO
ALLOW THE APPLICATION TO WAIT IF IT NEEDED TO, BUT THE DOMINANT
PHILOSOPHY IS THAT AFTER A TASK REQUESTS A SERVICE, IT GETS
CONTROL BACK IMMEDIATELY, PERHAPS WITH A FLAG TELLING HIM THAT
THE SERVICE CANNOT BE STARTED NOW IF THAT IS TRUE, AND THE TASK
CAN WAIT IF IT MUST AND RETRY. ^THE MAIN REASON FOR NOT HAVING MORE
SYSTEM RETRIES IS TO KEEP THE SCHEDULER SIMPLE BY HAVING ONLY ONE
STATE PER TASK RATHER THAN A <FIFO QUEUE OF FUTURE DESIRED STATES.
^THE ALTERNATIVE WOULD APPLY IF ONE WERE TO SAY A TASK WILL NOT
REGAIN CONTROL UNTIL A SERVICE IS COMPLETE AND THERE MAY BE RETRIES
DONE TO ENSURE RELIABLE COMPLETIONS EVEN IN THE PRESENCE OF ERRORS.
^THE POSSIBILITY OF ERRORS ARISES DUE TO THE DISTRIBUTED NATURE OF
THE SYSTEM WHERE, FOR INSTANCE, ONE MAY ATTEMPT TO SEND DATA TO
A TASK THAT HAS NOT YET STARTED.
.P
^THE <MSX SYSTEM IS SECURITY CONSCIOUS AND HAS BEEN DESIGNED TO
HANDLE USERS AT DIFFERENT LEVELS OF MILITARY CLASSIFICATION,
SO THAT EVERY DEVICE AND TASK HAS A CLASSIFICATION AND A SPECIAL
CATEGORY LIST (<MSX HAS BUILT-IN CHECKING ROUTINES THAT TAKE INTO
ACCOUNT THE FULL <DOD SECURITY MODEL INCLUDING SPECIAL CATEGORIES)
AND NO COMMUNICATION (INCLUDING IMPLICIT "COVERT CHANNEL" COMMUNICATION)
MAY OCCUR UNLESS THE <MLS RULES ARE FOLLOWED OR UNLESS THE TASK HAS
THE PRIVILEGE TO DISREGARD SOME OR ALL OF THOSE RULES. ^THE
SYSTEM ALSO REGULATES WHETHER ^I/^O MAY APPEAR ASYNCHRONOUS, AND
WILL HANDLE COVERT CHANNELS, WHERE THEY ARE UNAVOIDABLE, BY LIMITING
THEIR BANDWIDTH TO 1 BIT PER SECOND IF THE SYSTEM HAS BEEN BUILT
WITH A CLOCK. ^THE INTENT HAS BEEN TO MAKE IT POSSIBLE TO USE
<MSX AS A SECURE KERNEL, BUT NO FORMAL VERIFICATION HAS BEEN DONE.
^THE SYSTEM IS OF SUCH A SCALE THAT THIS SHOULD BE POSSIBLE TO
SOME LEVEL, BUT BY MANUAL TECHNIQUES ONLY.
.P
<MSX ATTEMPTS SOME LOAD BALANCING AND SUPPORT OF CONFIGURATIONS WHERE
HARDWARE SUDDENLY FAILS BY DETERMINING AT TASK STARTUP TIME WHERE
THE TASK MUST RUN. ^USERS MAY NOT EVEN SPECIFY WHICH <CPU A TASK
RUNS ON, NOR DOES IT MATTER TO USER PROGRAMS. ^A ROUTINE, WHICH
MAY BE MODIFIED FOR EACH APPLICATION, DETERMINES <CPU ALLOCATION
POLICY AND EACH <CPU PERFORMS ALLOCATIONS AT REQUEST TIME,
GIVEN A GLOBALLY MAINTAINED ACTIVITY COUNT WHICH LOADS THE CURRENTLY
LEAST-ACTIVE <CPU FIRST.
^THIS DOES NOT ADDRESS WIDELY VARYING LOADS THAT MIGHT MAKE IT
DESIRABLE TO MOVE A TASK TO ANOTHER <CPU ONCE IT HAS STARTED,
BUT IT WAS FELT THAT FOR A GENERAL INTERCONNECTION VIA A NET
OF SOME SORT, THE EXTRA TRAFFIC GENERATED BY SUCH LOADS WOULD
NOT BE DESIRABLE. ^THE METHOD OF CHOOSING A <CPU IS DESIGNED TO
ADAPT TO A DEGREE. ^ITS IDEA IS THAT WHEN A REQUEST IS MADE TO
START AN INACTIVE TASK, THE <CPU FIGURES OUT WHICH <CPU
SHOULD RUN THE TASK AND SENDS OUT MESSAGES TO ALL THE SYSTEM THAT
TELL WHICH <CPU IS TO START THE TASK. ^IN PRINCIPLE, THE DESTINATION
<CPU MAY DECIDE IT IS TOO BUSY AND SEND OUT ANOTHER SUCH BROADCAST
TO START THE TASK ELSEWHERE. ^THERE IS AN INDICATION TO THE
ROUTING ROUTINE WHETHER THE ARBITRATION IS THE FIRST ONE OR NOT
TO AID IN THIS. ^THE PRESENT VERSION DOES NOT DO ANY RE-ARBITRATION
FOR SIMPLICITY, BUT THE SYSTEM IS SET UP TO HANDLE IT SHOULD THE
ARBITRATION ROUTINE BE REDONE. ^BECAUSE THE SAME METHOD OF DETERMINING
<CPU IS USED IN ALL <CPU\S, THE PLACEMENT WILL EVENTUALLY CONVERGE
ON A LOCATION FOR A TASK. (^IN PRACTICE ONE WOULD LIMIT THIS TO
SOME MAXIMUM NUMBER OF ITERATIONS FOR PERFORMANCE, AND IN THE CASE
OF THE PRESENT <MSX THAT LIMIT IS 1.) ^BECAUSE THE CONSULTATION IS
AT ARM'S LENGTH, THE SYSTEM WILL FUNCTION CORRECTLY WITHOUT ALL
OF ITS UNITS BEING OPERATIONAL. ^THERE ARE ALSO MESSAGES SENT EVERY
TIME A TASK EXITS, SO THE <CPU\S ON THE SYSTEM CAN MAINTAIN THEIR
TABLES OF WHAT IS ACTIVE WHERE. ^THERE IS ALSO PROVISION FOR TWO
<CPU\S STARTING THE SAME TASK IN TWO PLACES; THE RESULT IS THAT BOTH
ARE ABORTED AND THE REQUESTORS NOTIFIED OF A "NET ERROR" WHICH WOULD
GENERALLY RESULT IN A DELAY AND RETRY. NOTICE THAT REMOVING A <CPU
FROM SUCH A SYSTEM IS RELATIVELY EASY; ONE NEED ONLY MARK THE
<CPU AS EXTREMELY BUSY SO NO TASKS WILL BE STARTED THERE, AND FLAG
THE COMMUNICATIONS PROCESSES NOT TO ATTEMPT TO SEND TO THAT <CPU.
^TASKS ACTIVE THERE MUST BE MARKED AS ABORTED (TO BE DONE BY A
WATCHDOG TASK) SO THEY MAY BE RESTARTED ELSEWHERE.
.P
^THE SYSTEM ALLOWS TASKS TO BE STRUCTURED IN HIERARCHIES FOR ERROR
RECOVERY AS DESCRIBED BELOW. ^THIS MAKES IT SIMPLE TO RECOVER
FROM ERRORS THAT CRASH TASKS AND TO CLEAN UP A SET OF TASKS.
^THE ABORTING OF A PARENT TASK WILL ABORT ALL CHILDREN AS WELL,
AND A PARENT IS NOTIFIED OF THE ABORT OR EXIT OF ANY OF ITS CHILDREN
AUTOMATICALLY. ^ALSO, A SERVER MAY BE NOTIFIED OF ALL EXITS OCCURRING
ANYWHERE IN THE SYSTEM TO ALLOW GENERATION OF FINAL INPUTS TO
TASKS AWAITING INPUT. ^NO ATTEMPT TO AUTOMATICALLY RESTART
TASKS IS DONE SINCE THE SYSTEM CANNOT KNOW WHETHER THAT IS THE
RIGHT THING TO DO ITSELF. (^IMAGINE A TASK THAT IS WRITING TAPE;
IF IT CRASHES, IT MIGHT BE BETTER FOR ITS PARENT TO REPOSITION THE
TAPE PRIOR TO RE-REQUESTING THE TASK.)
.P
<MSX IS ORIENTED TO REALTIME WORK, BUT IT SHOULD BE NOTED THAT THE
CHECKING REQUIRED FOR DISTRIBUTED PROCESSING CONSUMES TIME AND
MAKES THE RESULTING SYSTEM A FACTOR OF 2 TO 3 MORE COMPLEX AND
SLOW THAN A CORRESPONDING SINGLE - PROCESSOR SYSTEM. ^THIS IS
UNAVOIDABLE WHERE PROCESS LOCATION IS TO BE MADE INVISIBLE
TO PROCESSES, A DESIRABLE FEATURE WHICH PREVENTS AN APPLICATION
FROM DEPENDING ON THAT LOCATION AND POSSIBLY BEING UNWORKABLE
ON A REDUCED SYSTEM.

.SKIP 3
.TEST PAGE 20
.CENTER
^SYSTEM ^DESCRIPTION
.PARAGRAPH
^EACH <CPU IN THE <MSX SYSTEM CONTAINS A COPY OF THE <MSX KERNEL AND
ITS ^TASK ^LIST (KNOWN AS THE ^SYSTEM ^TASK ^LIST OR <STL), AND
EXECUTES TASKS IN LOCAL MEMORY, IN <USER MODE. <MSX DOES NOT ENVISION
TOTALLY SHARED MEMORY. ^TASKS ARE INITIATED BY LOCAL ARBITRATION
AND POSSIBLE REMOTE STARTUP TO REDUCE COMMUNICATION TRAFFIC. ^THAT
IS, ANY <CPU MAY REQUEST THAT ANY TASK KNOWN TO THE SYSTEM BE
STARTED UP. ^A ROUTINE IN THE <MSX KERNEL (WHICH MAY BE MODIFIED
FOR DIFFERENT APPLICATIONS) THEN ARBITRATES, WITHIN THE
REQUESTING <CPU, WHICH <CPU IN THE SYSTEM SHOULD EXECUTE THE TASK
BASED ON ITS INFORMATION OF WHAT IS RUNNING WHERE. <MSX THEN
GENERATES MESSAGES TO ALL <CPU\S INDICATING WHICH TASK IS TO START
WHERE (PLUS SOME SECURITY INFORMATION BASED ON THE CLEARANCE OF
THE REQUESTOR). ^THESE MESSAGES ARE USED BY EACH <CPU TO UPDATE
THE LOCAL INFORMATION ABOUT CURRENT TASK STATUSES, AND THE <CPU
WHICH WAS REQUESTED TO RUN THE TASK STARTS IT UP. ^FAILURES OR
COLLISIONS LEAD TO TASKS EXITING, WHICH LEADS TO OTHER BROADCASTS
OR MESSAGE SEQUENCES TO INFORM THE SYSTEM THE TASK IS NOT
EXECUTING AND WHY. ^IN PRINCIPLE, THE <CPU WHICH WAS TOLD TO RUN
THE TASK MAY RE-ARBITRATE, BUT <MSX DOES NOT DO THIS. <MSX CONTAINS
LOGIC TO HANDLE COLLISIONS OR STARTUP OF EXTRA COPIES OF THE SAME
TASK BY FORCING EXIT ON BOTH. ^THE <MSX KERNEL ASSUMES <FIFO
ORDERING OF MESSAGES, BUT WITHIN THIS CONSTRAINT CAN HANDLE ANY
DESIRED NET TOPOLOGY.
.PARAGRAPH
^THE TASK REQUESTOR HAS NO CONTROL OVER WHERE A TASK WILL BE STARTED
WHEN HE REQUESTS IT; THIS IS DONE BY THE POLICY MODULE, AND
GENERALLY THE POLICY MODULE WILL ALLOW A TASK TO START IN ANY OF
SEVERAL PLACES. ^THUS, USER CODE CANNOT CONTAIN OTHER DEPENDENCIES
ON TASK LOCATION, AND CAN EXECUTE EVEN AFTER A SYSTEM RECONFIGURATION.
^TASKS COMMUNICATE BY SENDING MESSAGES OR SEMAPHORES. ^THESE ARE
DELIVERED BY <MSX REGARDLESS OF THE RELATIVE LOCATIONS OF THE SENDER
OR RECEIVER TASKS. (^EACH <CPU HAS INFORMATION ABOUT WHERE EACH
TASK IS EXECUTING.) ^THE TASK DOES NOT NEED TO KNOW ABOUT THE
LOCATION OF ANY TASK TO COMMUNICATE WITH IT. (^HOWEVER, WHERE
TASKS ARE PART OF A HIERARCHY (AND AT THE SAME CLEARANCE), THE
POLICY MODULE MAY ALLOW ALLOCATION OF SHARED MEMORY OWNED BY THE
ROOT TASK OF THE HIERARCHY.)
^THE SYSTEM PROVIDES AN ACKNOWLEDGEMENT WHEN THE DESTINATION TASK
RECEIVES ANY MESSAGE SENT BY THE SENDER TASK, AND IMPLEMENTS AN
"ENCAPSULATED LIBRARY" FACILITY TO PERMIT VERIFIED CODE TO BE CALLED
WITH GREATER PRIVILEGES THAN A TASK NORMALLY HAS TO PERMIT
CONSTRUCTION OF FURTHER PROTOCOLS FOR MESSAGE HANDLING. (^THE
SECURITY ASPECTS OF THIS FORCE SOME MODIFICATIONS WHERE MESSAGES
CROSS CLEARANCE LEVELS, SO THAT THE SENDER THEN WAITS INSTEAD
OF RECEIVING AN ACKNOWLEDGEMENT. ^SEE BELOW FOR MORE DETAIL.)

.SKIP 3
.TEST PAGE 20
.CENTER
^ERROR ^RECOVERY
.PARAGRAPH
^THE SYSTEM CAN INITIATE TASKS (UP TO LIMITS DICTATED BY AVAILABLE
MEMORY) ON ANY CONNECTED CONFIGURATION OF PROCESSORS, SINCE EACH
PROCESSOR CAN RUN MULTIPLE TASKS. ^HOWEVER, DYNAMIC ERROR RECOVERY
IS POSSIBLE ONLY VIA SOME ADDITIONAL FEATURES. ^WHERE AN ENTIRE <CPU
FAILS, ERROR DETECTION IS DONE BY ARRANGING A "WATCHDOG" TASK IN
EACH <CPU TO SEND MESSAGES TO THE OTHERS ON THE NET PERIODICALLY
WHEN THAT <CPU IS RUNNING. ^WHEN NO MESSAGE IS RECEIVED, THE OTHER
WATCHDOGS MARK ALL TASKS IN THE FAILED <CPU AS ABORTED.
^SOME ATTEMPT TO CHECK SYSTEM CONSISTENCY VIA "WATCHDOG" PROCESSES
EXCHANGING PICTURES OF THEIR STATES WITH NEIGHBORING <CPU\S IS
ENVISIONED BUT THESE HAVE NOT BEEN WRITTEN NOW.
.PARAGRAPH
^ONCE A TASK FAILS, EITHER DUE TO A <CPU ERROR OR TO OTHER CAUSES,
<MSX ATTEMPTS TO RECOVER. <MSX CANNOT KNOW A PRIORI THAT IT IS
PERMISSIBLE TO SIMPLY RESTART THE TASK (ELSEWHERE, IF THE <CPU
FAILED). ^A TASK WHICH HAS INCREMENTED DATA IN A GLOBAL AREA, FOR
INSTANCE, SHOULD <NOT BE RESTARTED. ^THEREFORE, <MSX SIMPLY PROVIDES
THE USER TASK WITH PRIMITIVES FOR RECOVERY. ^A TASK MAY SPECIFY
AN ENTRY TO BE CALLED (ONCE ONLY) WHEN IT IS FORCED TO EXIT
AND THIS ENTRY WILL BE CALLED, PERMITTING THE TASK TO CLEAN UP
ANY OUTSTANDING EXTERNAL TRANSACTIONS BEFORE IT FINALLY EXITS.
.PARAGRAPH
^WHERE A PROBLEM IS BEING SOLVED BY A SET OF TASKS, <MSX PROVIDES
MEANS FOR AN ORDERLY RESTART BY IMPLEMENTING TASK HIERARCHIES.
^WHEN A TASK CALLS ANOTHER TASK, THE CALLER'S NAME IS RECORDED
IN THE CALLED TASK'S <STL ENTRY, AND THE CALLED TASK'S NAME IS
RECORDED IN THE CALLER TASK'S <STL ENTRY. ^THEN, WHEN A TASK
EXITS (FOR WHATEVER REASON), ALL TASKS IT REQUESTED ARE ABORTED,
AND ITS CALLER IS NOTIFIED AND SENT AN EXIT STATUS TO PERMIT IT
TO DISCRIMINATE ABNORMAL EXITS FROM NORMAL ONES. ^THE CALLER MAY
RECEIVE THIS INFORMATION VIA A SEMAPHORE, OR BY BEING ENTERED AT
A POINT OF HIS CHOOSING WHEN A CALLED TASK EXITS, OR BOTH. ^IN THIS
WAY, THE CALLER MAY RESTART CALLED TASKS IF NEED BE, OR PERFORM
NEEDED CLEANUPS IF NOT. (^NOTE THAT HIERARCHIES DO NOT CROSS
CLASSIFICATION LINES; THE COMMUNICATION INHERENT HERE IS TOO GREAT
TO PERMIT TASKS TO DIFFER IN CLASSIFICATION IN ONE HIERARCHY.)
.PARAGRAPH
^TASKS PERFORM ^I/^O TO DEVICES ATTACHED TO THEIR <CPU\S ONLY,
OR USE SPECIAL DEVICE CONTROL TASKS FORCED BY THE POLICY MODULE TO
RUN WHERE THE DEVICES ARE AND PERFORM ^I/^O BY SENDING MESSAGES
TO THESE TASKS. ^SUCH TASKS ARE OF COURSE SECURITY RELEVANT
AND NORMALLY MUST BE VERIFIED NOT TO BREAK THE RULES. ^ON
MASS STORAGE DEVICES, THE DEVICE CONTROL TASK WOULD NORMALLY BE
THE ONE WHICH IMPLEMENTS A FILE SYSTEM, WHICH IS LEFT OUT OF
THE KERNEL.
.SKIP 3

.TEST PAGE 20
.CENTER
<SECURITY <CONSIDERATIONS
.PARAGRAPH
^WE NOW WILL ADDRESS THE <DOD SECURITY POLICY CONSIDERATIONS
HANDLED BY <MSX IN GREATER DETAIL. ^THERE IS EXTENSIVE TREATMENT OF
THESE CONSIDERATIONS IN <MSX, BUT ITS DISCUSSION HAS BEEN DEFERRED
IN ORDER TO EXPLAIN THE DISTRIBUTED FUNCTIONALITY.
.PARAGRAPH
^THE ENVIRONMENT DESCRIBED SO FAR ASSUMES THAT TASKS ARE AT THE SAME
CLEARANCE, SO THAT NOTHING THEY DO PRESENTS A SECURITY ISSUE. ^THE
MILITARY SECURITY MODEL, HOWEVER, ALLOWS LEVELS OF CLEARANCE
AND WITHIN THE LEVELS, SPECIAL COMPARTMENTS. ^ALL <MSX TASKS AND
DEVICES HAVE A CLEARANCE LEVEL (RANGING FROM 0 TO 127, WITH THE
ASSOCIATION BETWEEN THAT LEVEL AND FORMAL CLASSIFICATIONS (<C,
^S, ^TS, AND ^U) LEFT TO THE APPLICATION. ^EACH <MSX OBJECT ALSO
HAS A LIST OF UP TO 15 SPECIAL COMPARTMENTS, EACH 1 BYTE LONG.
^THESE INCLUDE THE "PUBLIC" COMPARTMENT, BUT IF ANY OTHERS ARE
INCLUDED, THEN A READER MAY NOT ACCESS INFORMATION UNLESS HIS
COMPARTMENT LIST INCLUDES ALL COMPARTMENTS IN THE OTHER OBJECT'S
LIST, AND A WRITER MAY NOT WRITE TO AN OBJECT UNLESS ALL
COMPARTMENTS IN HIS LIST ARE CONTAINED IN THE OBJECT'S LIST
(AND, OF COURSE, UNLESS DATA IS GOING FROM LOW TO THE SAME OR
HIGHER CLASSIFICATION LEVELS). ^THIS REPRESENTS THE TOTAL
SECURITY POLICY, WHICH WILL NORMALLY BE ENFORCED.
^TASKS MAY HAVE PRIVILEGES TO VIOLATE SPECIAL COMPARTMENTS,
TO VIOLATE SECURITY LEVEL CHECKS, OR TO VIOLATE THE "INTEGRITY"
PROPERTY (WHICH CORRESPONDS TO WRITING TO AN OBJECT TO WHICH
ONE LACKS READ PRIVILEGES). ^THESE PRIVILEGES ARE DIFFERENT
FOR MESSAGES AND DEVICE ^I/^O, SINCE IT IS LIKELY ONE WILL WANT
TO BE ABLE TO SEND MESSAGES TO MORE HIGHLY CLEARED TASKS OR
USERS, BUT UNLIKELY ONE WILL WANT TO ALLOW ^I/^O TO ANY BUT
A DEVICE AT THE SAME LEVEL (OR LOWER) OF CLEARANCE.
.PARAGRAPH
<MSX CAUSES ALL TASKS TO EXECUTE IN <USER MODE, WITH
NO MEMORY OVERLAP WITH THE EXECUTIVE, OTHER TASKS, OR THE
^I/^O DEVICE ADDRESS SPACE. (^THIS MAY BE VIOLATED WHERE
EITHER THE TASKS ARE MADE A PERMANENT PART OF THE EXTENDED
KERNEL - AS THE LOADER OR WATCHDOG TASKS MUST BE - OR
WHERE TASKS ARE AT IDENTICAL LEVELS AND ONE SPAWNS OTHERS,
BUT SPACE IS NOT SHARED IF THERE IS ANY SECURITY ISSUE
POSSIBLE.) ^A TASK IS ABLE TO PASS CONTROL TO <MSX THROUGH
ONLY ONE INSTRUCTION (OTHER TRAPS EITHER CAUSE THE TASK TO
BE ABORTED OR TO REGAIN CONTROL AT A NEW ADDRESS WITH THE
OLD ^PROCESSOR ^STATUS ^WORD), AND THERE ARE ONLY 32 POSSIBLE
<MSX DIRECTIVES. ^SYSTEM CHECKOUT CONSISTS OF TESTING THOSE
DIRECTIVES' SECURITY IMPLICATIONS. ^NOT ALL DIRECTIVES WILL
NORMALLY BE PERMITTED TO UNTRUSTED TASKS. <MSX HAS A MASK
FOR EACH TASK TELLING WHAT DIRECTIVES THAT TASK MAY EXECUTE.
^A TASK ISSUING A NON-PERMITTED DIRECTIVE SIMPLY SEES IT
RETURN IMMEDIATELY WITH NO ACTION TAKEN. ^THERE ARE A FEW
DIRECTIVES A TASK MAY ALWAYS ISSUE (SUCH AS <EXIT, ^WAIT
FOR ^NEXT ^TASKLIST ^SCAN, AND ^WAIT FOR ^NONZERO ^LOCAL
^SEMAPHORE). ^OTHER SECURITY-RELEVANT DIRECTIVES ARE
CHECKED OR SIMPLY NEVER PERMITTED TO UNTRUSTED CODE.
^SPECIFIC CHECKS ARE DONE IN MESSAGE AND SEMAPHORE DIRECTIVES
AND IN WAITS THAT MAY COMPLETE ON EITHER A LOCAL EVENT OR
ANOTHER TASK'S EXIT. (^THE LATTER IS NOT PERMITTED ACROSS
SECURITY LEVELS.) ^I/^O REQUESTS ARE ALSO CHECKED.

.PARAGRAPH
^TASK CLEARANCES ARE SET UP BY CHOOSING THE MINIMUM OF THE
TASK'S PERMANENT "DEFAULT CLEARANCE" AND THE REQUESTOR'S
CLEARANCES. ^THIS PERMITS A TASK TO BE SPECIFIED AS, SAY,
USABLE UP TO <SECRET BUT NOT BEYOND. ^BECAUSE THE SIGNALLING
OF TASK HIERARCHIES WOULD OTHERWISE VIOLATE SECURITY
POLICY, TASK HIERARCHIES MAY NOT CROSS ANY SECURITY
BOUNDARIES. ^TASKS REQUESTED FOR A HIERARCHY WHICH ARE
NOT PERMITTED (BY THEIR DEFAULT CLEARANCES) TO BE MADE
IDENTICAL IN CLEARANCE WITH THEIR CALLER WILL BE STARTED,
BUT AT THEIR DEFAULT CLEARANCE, AND THEY WILL NOT BE
PLACED IN A TASK HIERARCHY WITH THEIR CALLER (SO NO NOTICES
WILL PASS IN EITHER DIRECTION ON TASK EXITS). ^ANY "GATEWAY"
TASK PERMITTED TO ALTER ITS CLASSIFICATION MUST BE A PART
OF THE TRUSTED SYSTEM AND WILL NORMALLY BE ASSEMBLED IN WITH
<MSX. ^IT SHOULD BE NOTED THAT ABORTING A TASK WILL NOT
CROSS CLASSIFICATION BOUNDARIES EITHER, UNLESS THE TASK
ISSUING THE ABORT REQUEST IS TRUSTED AND HAS THE "IGNORE
MULTILEVEL SECURITY" PRIVILEGE.
^ONCE A TASK HAS A SECURITY CLEARANCE (ABOVE ^UNCLASSIFIED),
IT MAY NOT HAVE ITS CLEARANCE CHANGED. ^THIS WOULD OTHERWISE
ALLOW A TASK TO BE RUN AT HIGH CLASSIFICATION, SAVE DATA,
THEN DISGORGE IT TO A LOWER-CLASSIFIED SPAWNER IF DESIRED.
^RATHER, THESE CLEARANCES ARE PERMANENT WHILE THE TASK IS
IN MEMORY. ^TO MINIMIZE THE ADVERSE PERFORMANCE IMPACT,
<MSX WILL REMOVE TASKS FROM MEMORY ONCE THEY EXIT IF THE
SECURITY FEATURES HAVE BEEN SELECTED (OTHERWISE LEAVING
TASKS IN MEMORY WHENEVER POSSIBLE TO AVOID DOWNLOADING
TIME PENALTIES).
.PARAGRAPH
^I/^O ACCESSES ARE CHECKED ON A PER-DEVICE BASIS (MAINLY
BECAUSE THE KERNEL MUST KNOW ABOUT ^I/^O DEVICES, BUT THE
AMOUNT OF CODE NEEDED TO HANDLE FILES IN A SECURE WAY WOULD
BE UNREASONABLY LARGE, AND IMPOSSIBLE TO VERIFY, FOR
A KERNEL). ^EACH DEVICE HAS A CLASSIFICATION LEVEL AND
COMPARTMENT LIST, AND SECURITY IS TESTED AT EACH TRANSFER
REQUEST. ^ALL TASKS ARE GIVEN A FULL 32^K WORD ADDRESS SPACE
(PERMITTING SOME ADDRESSES TO REFER TO THE SAME PHYSICAL
MEMORY MORE THAN ONCE WHERE THE TASK DOES NOT NEED THAT
MUCH SPACE), BUT THE DEVICE LEVEL CODE ENSURES THAT ALL ^I/^O
REQUESTS REMAIN ENTIRELY WITHIN THE PHYSICAL SPACE OF
THE TASK, EVEN IF THE DEVICE IS NOT A <DMA DEVICE. ^ACCESS
TO DEVICES IS CONTROLLED BY DIFFERENT CLASSIFICATION PRIVILEGES
THAN MESSAGES. ^SINCE NOTIFICATION OF ^I/^O COMPLETION CAN
BE USED FOR COVERT COMMUNICATION, AND SINCE ^I/^O INTO
MEMORY USED FOR DIRECTIVES AFTER THE ^I/^O INITIATES MAY BE
USED TO ATTEMPT TO CORRUPT <MSX, TASKS HAVE A PRIVILEGE THAT
TELLS WHETHER ^I/^O IS SYNCHRONOUS. ^IF IT IS NOT, THEN
ANY ^I/^O CROSSING SECURITY BOUNDARIES CAUSES TASKS TO WAIT
UNTIL IT COMPLETES, BUT CONTROL RETURNS AS SOON AS THE REQUEST
IS QUEUED WHERE NO SECURITY WALLS ARE CROSSED. ^IF ^I/^O
IS SYNCHRONOUS, THE TASK NEVER REGAINS CONTROL UNTIL THE ^I/^O
HAS COMPLETED IN ANY CASE.
^DATA FROM EACH ^I/^O REQUEST IS COPIED OUT OF THE TASK'S SPACE
PRIOR TO USE, SO AN ^I/^O REQUEST CANNOT CORRUPT ITSELF, BUT
THERE MAY BE EXOTIC WAYS TO CORRUPT <MSX, UNLESS ^I/^O IS
SYNCHRONOUS TO PREVENT ANY CALLS TO <MSX UNTIL THE ^I/^O IS
DONE. ^THE DECISION IS LEFT TO THE APPLICATION, SINCE THE
PERFORMANCE PENALTY OF SYNCHRONOUS ^I/^O MAY BE TOO GREAT TO
PERMIT.

.PARAGRAPH
^COVERT CHANNELS OF COMMUNICATION ARE HARDER TO BLOCK THAN DIRECT
ONES, BUT MEASURES ARE TAKEN TO REDUCE THEIR BANDWIDTH WHERE THE
SYSTEMS CONTAIN CLOCKS.
^IN THIS CASE, MESSAGES OR ^I/^O REQUESTS THAT CROSS SECURITY
BOUNDARIES FORCE A TASK TO AWAIT ^I/^O COMPLETION OR MESSAGE
RECEIPT. ^SINCE THE RECEIVER'S WILLINGNESS TO RECEIVE IMMEDIATELY
COULD COMMUNICATE BACK TO THE SENDER, THESE WAITS ARE EXTENDED TO
THE NEXT CLOCK TICK (CURRENTLY ONCE A SECOND, BUT VARIABLE), THUS
REDUCING THE BANDWIDTH OF SUCH CHANNELS TO 1 BIT PER SECOND. ^ANY
REQUEST FAILING DUE TO SYSTEM NODE EXHAUSTION (WHICH NORMALLY
SHOULD BE PREVENTED BY BUILDING <MSX WITH A BIGGER NODE POOL) WILL
CAUSE THE REQUESTOR TO WAIT ALSO. ^THUS, MODULATING SYSTEM RESOURCES
PROVIDES ONLY LOW BANDWIDTH COMMUNICATION. ^EXHAUSTION OF MESSAGE
NODES IS IRRELEVANT TO SECURITY SINCE THESE AREAS ARE ALLOCATED SEPARATELY
FOR EACH TASK. ^NO SYSTEM INFORMATION IS KEPT IN USER SPACE, AND
ALL ARGUMENTS TO <MSX DIRECTIVES ARE VALIDITY CHECKED. ^THIS PREVENTS
ERRONEOUS DIRECTIVE ARGUMENTS FROM CORRUPTING <MSX. ^TASK CLASSIFICATIONS
ARE PROPAGATED BY INTER-<CPU MESSAGES (ON NON-SHARED-MEMORY SYSTEMS)
AND SECURITY POLICY IS TESTED AT BOTH MESSAGE SEND AND RECEIVE ENDS
OF THE TRANSMISSION.
^IF THE <CPU ALLOCATION ROUTINE IS SET UP TO ENFORCE <CPU SEPARATION,
<MSX CAN EASILY ACCOMMODATE HAVING TASKS OF ONLY ONE SECURITY
LEVEL (AND PERHAPS ONE SET OF SPECIAL COMPARTMENTS) PER <CPU, FURTHER
REDUCING DANGER OF INTERTASK CROSSTALK VIOLATING SECURITY. ^IF THERE
ARE ENOUGH <CPU\S TO DO IT, THIS IS THE PREFERRED METHOD FOR
REDUCING DANGER OF COVERT COMMUNICATIONS AND GIVING SECURITY ISOLATION.
^SUCH AN ARCHITECTURE WOULD BE USED IN A REALISTIC HIGH-PERFORMANCE
SYSTEM.
^IT IS EXPECTED THAT IN A SECURE SYSTEM, INTER-
<CPU MESSAGES ARE SEQUENCE NUMBERED AND ENCRYPTED TO ENSURE THAT
TAPPING THOSE LINKS CANNOT CAUSE TROUBLE. ^THESE TECHNIQUES ARE WELL
KNOWN AND WILL NOT BE FURTHER DISCUSSED.
.PARAGRAPH
^IN CONCLUSION, <MSX <MAY BE A SECURE SYSTEM IN THE SENSE OF NOT
PERMITTING UNAUTHORIZED DISCLOSURE OF INFORMATION. ^HOWEVER, BECAUSE
IT WAS WRITTEN IN ASSEMBLY LANGUAGE, IT MUST BE HAND CHECKED. <MSX
CONSISTS OF ABOUT 6000 INSTRUCTIONS, AND WAS DESIGNED AND IMPLEMENTED
BY 1 PERSON. ^THE SECURITY RELEVANT PARTS OF THE SYSTEM ARE A
RELATIVELY SMALL PART OF THE WHOLE (THE "DENIAL OF SERVICE" ISSUE
HAVING BEEN LARGELY IGNORED AS A CONSIDERATION BECAUSE THE DESIGN
IS FOR AN APPLICATION ENGINE, NOT A GENERAL SERVICE), AND A SYSTEM
OF THIS COMPLEXITY SHOULD BE POSSIBLE TO VERIFY BY HAND. ^UNTIL
THIS IS DONE, HOWEVER, <MSX CAN ONLY BE CALLED "HARDENED", AND
NOT YET "TRUSTED".

.SKIP 3
.TEST PAGE 20
.CENTER
^DEVELOPMENT ^ENVIRONMENT
.PARAGRAPH
^IN DEVELOPING A NEW SECURTY KERNEL, THE CLASSICAL APPROACH TO
CREATING A DEVELOPMENT ENVIRONMENT HAS BEEN TO EMULATE AN EXISTING
OPERATING SYSTEM (E.G., <UNIX (TM), <VM/370, <MULTICS) UNDER THE
KERNEL. <MSX TAKES A DIFFERENT APPROACH THAT HAS PROVEN SIMPLE AND
EFFECTIVE. ^IT CAN BE ASSEMBLED TO RUN EITHER AS A REAL, STAND-ALONE
OPERATING SYSTEM, OR AS AN EMULATION OF ITSELF AS A TASK UNDER THE
<DEC <RSX11^M OR <IAS OPERATING SYSTEMS. ^THE EMULATED <MSX PROVIDES
A PROGRAM INTERFACE TO ITS TASKS IDENTICAL TO THAT OF THE STAND-ALONE
VERSION (AT SOURCE LEVEL; MACROS EXPAND DIFFERENTLY FOR THE TWO AND
ADDRESSING IS SLIGHTLY DIFFERENT). ^WHEN <MSX RUNS UNDER <IAS OR <RSX,
HOWEVER, <MSX EMULATES AN ENTIRE <CPU IN WHAT <IAS OR <RSX CONSIDER
A SINGLE TASK. ^THUS, MULTIPLE COPIES OF THE <MSX TASK, CONFIGURED
TO USE <RSX INTERTASK COMMUNICATIONS, MAY BE USED TO EMULATE AN
ENTIRE DISTRIBUTED SYSTEM ON A SINGLE PHYSICAL <CPU, TO GAIN
UNDERSTANDING OF SCHEDULING ON THE NETWORK WITHOUT HAVING TO BUILD
(OR BUY) LARGE AMOUNTS OF HARDWARE. ^THE ENVIRONMENT PROVIDED UNDER
<RSX OR <IAS IS EXCELLENT FOR PROGRAM DEVELOPMENT, AND WITH THE
VARIETY OF USER WRITTEN TOOLS AVAILABLE FREE ON SUCH A SYSTEM,
IT IS AS POWERFUL AS CAN BE FOUND ANYWHERE. ^DEVELOPMENT EFFORTS
FOR <MSX SYSTEMS HAVE THESE TOOLS AVAILABLE, BUT THERE IS NO NEED
TO TURN <MSX INTO A GENERAL TIMESHARING SYSTEM; IT CAN REMAIN A SMALL,
FAST APPLICATIONS ENGINE. (^EVEN SO, <MSX HAS SUFFICIENT FACILITIES
TO ACCEPT AN EMULATOR FOR THE <RT11 OPERATING SYSTEM AND ITS
UTILITIES SIMILAR TO THE ONE NOW EXISTING FOR <IAS, IN CASE SOME
DEVELOPMENT FACILITIES MUST BE INCLUDED.)

.SKIP 3
.TEST PAGE 20
.CENTER
^REQUIRED ^TRUSTED ^PROCESSES
.PARAGRAPH
<MSX WILL REQUIRE SEVERAL MORE TASKS WHICH MUST BE TRUSTED. ^THESE
INCLUDE THE TERMINAL HANDLER TASK, THE TASK LOADER, THE FILE SYSTEM
HANDLER (BOTTOM LEVEL AT LEAST), AND THE WATCHDOG TASKS.
^IT MAY BE THE FILE SYSTEM NEED NOT BE TRUSTED, BUT ALL THE OTHERS
DO JOBS THAT ARE SENSITIVE.
.PARAGRAPH
^THE TERMINAL HANDLER MUST SET THE USER'S CLASSIFICATIONS AS THE RESULT
OF A DIALOGUE (PERHAPS RENEWED AT ODD INTERVALS) WITH THE USER, AND
START UP, OR ACT AS, A CONSOLE DISPATCHER TO ACT AS THE ROOT OF
ANY OF HIS TASK HIERARCHIES. ^THIS TASK MUST PERIODICALLY RENEW
THE DIALOGUE TO ENSURE THE USER IS REALLY WHO THE SYSTEM EXPECTS,
AND MUST BE ABLE TO CHANGE THE TERMINAL'S DEVICE CLASSIFICATIONS
TO REFLECT THAT DIALOGUE. ^SINCE <MSX WILL REJECT CLASSIFIED OUTPUT
TO AN UNCLASSIFIED DEVICE, THIS WILL PREVENT ANY OUTPUT FROM BEING
SENT WHERE THE USER HAS LEFT A TERMINAL AND ANOTHER COMES IN. ^THE
PRIVILEGE TO ALTER CLEARANCES MAKES THE TERMINAL HANDLER SECURITY
SENSITIVE.
.PARAGRAPH
^THE TASK LOADER'S JOB IS TO SET UP TASK TABLES AND LOAD A TASK INTO
MEMORY PREVIOUSLY ALLOCATED BY <MSX, AND MARK IT PRESENT. ^ONE LOADER
WOULD EXIST PER <CPU, AND IT MUST BE ABLE TO CHANGE ITS ADDRESS SPACE
DYNAMICALLY. ^THE LOADER IS SPECIFIED PRESENTLY, AND ITS INPUT QUEUE
IS DEFINED, BUT IT IS NOT WRITTEN. ^IT IS EXPECTED IT WOULD BE ASSEMBLED
WITH THE <MSX KERNEL EVEN THOUGH IT RUNS AS A TASK, AND IT MUST CHECK
THAT NO TASK IT LOADS HAS "DANGEROUS" DIRECTIVE PRIVILEGES. ^THE PRESENT
DESIGN CONCEPT FOR <MSX IS THAT ALL SECURITY-RELEVANT CODE FOR <MSX
MUST BE MADE RESIDENT AND NOT USER-MODIFIABLE, SO LOADED CODE
MUST NOT HAVE ANY CAPABILITIES THAT COULD BE USED TO VIOLATE SECURE
OPERATION. (^THE FACT THAT TASKS ARE PERMANENTLY PRESENT WHERE
SECURITY RELEVANT ALSO ALLOWS THEM TO BE REFERRED TO BY NUMBER
RATHER THAN NAME, WHICH IS AN UNFORGEABLE MECHANISM.) ^PRIOR TO
LOADING, A TASK'S MESSAGE AREA AND <STL ENTRY ARE ALLOCATED, SO THE
LOADER DOES NOT HAVE TO LOAD THEM, AND MESSAGES MAY BE QUEUED TO
THE TASK IMMEDIATELY IF ROOM EXISTS.
^THE LOADER ALSO HAS THE RESPONSIBILITY TO CLEAR ALL TASK MEMORY,
WHICH WILL GENERALLY BE DONE BY MAKING TASK IMAGES MULTIPLES OF
4^K LONG AND LETTING THE TASK LOADING ^I/^O DO IT WHERE THE
LOAD IS FROM DISK, THOUGH IT MAY HAVE TO BE OTHERWISE FOR TASKS
LOADED REMOTELY.
.PARAGRAPH
^WATCHDOG TASKS MUST BE ABLE TO MARK TASKS FOR ABORT WHERE THEY ARE
IN A FAILED <CPU. ^THUS, THEY MUST ACCESS KERNEL DATA AND FOR THIS
REASON MUST BE TRUSTED. ^AS TASKS, THEY HAVE THE INTERTASK MESSAGE
FACILITY AVAILABLE, BUT AS PARTS OF THE <MSX SYSTEM, THEY ACCESS THE
<STL AND <CPU USAGE TABLES MAINTAINED BY THE KERNEL.
^THE WATCHDOG TASKS ARE EXPECTED TO PASS COPIES OF TASK ACTIVITY
TABLES AND <CPU ACTIVITY MEASURES ALSO, TO KEEP UP-TO-DATE
ROUTING INFORMATION IN THE SYSTEM AND TO ENSURE THAT ANY PROTOCOL
BREAKDOWNS IN INTER-<CPU MESSAGES ARE OF SHORT DURATION. ^THEY
ARE THE MAIN LINE OF DEFENSE AGAINST HARDWARE FAILURES AND THE
MEANS OF CROSS - <CPU CONTROL BECAUSE THEY TAKE THE ROLE OF TASKS
AS WELL AS PARTS OF THE SYSTEM. ^THEY MAY BE DECOUPLED ONLY WHERE
COMMUNICATIONS IS QUITE RELIABLE AND PROCESSORS MAY BE ASSUMED
NOT TO FAIL. ^HOWEVER, THEY ARE NOT REQUIRED FOR SYSTEM DEVELOPMENT
AND ARE ACCORDINGLY NOT WRITTEN AT THE MOMENT.
.PARAGRAPH
^THE FILE SYSTEM, WHERE IT DOES NOT CROSS SECURITY BOUNDARIES, NEED
NOT BE SECURITY RELEVANT. ^HOWEVER, IF A DATABASE THAT CROSSES
CLASSIFICATION BOUNDARIES IS DESIRED, ONE WOULD USE A FILE SYSTEM
PER CLASSIFICATION LEVEL AND ARRANGE LOWER LEVELS' UPDATES TO BE
PASSED TO HIGHER LEVELS, AS IN WORK AT <SDC AND <MITRE. ^THE
HIGHER LEVELS MUST THEN USE EVENT COUNTS (USING READ-ONLY ACCESS
TO LOWER LEVEL DATA) TO ENSURE THAT THEIR UPDATES ARE BASED ON A
CONSISTENT PICTURE OF LOWER LEVELS OF CLEARANCE IN THE DATA BASE.
^THIS CAN BECOME UNWIELDY WHERE MANY SPECIAL COMPARTMENTS ARE
INVOLVED, AND THE PROBLEM HAS NOT BEEN FURTHER ADDRESSED.

.SKIP 3
.TEST PAGE 20
.CENTER
^CURRENT <MSX ^STATUS
.PARAGRAPH
<MSX AS BEEN DEVELOPED AND TESTED IN A PRIMARILY EMULATED 3 OR 4 <CPU
NETWORK, USING A GLOBAL BUS TOPOLOGY (FOR SIMPLICITY) AS AN APPLICATIONS
ENGINE AND A STUDY VEHICLE. ^AS SUCH, IT PROVIDES A MEANS TO DEVELOP
REAL, DISTRIBUTED APPLICATIONS WHILE AFFORDING A SMALL AND UNDERSTANDABLE
APPROACH TO ADDRESSING SECURITY ISSUES. ^IT HAS REACHED THE POINT OF
USEFULNESS NOW, AND FUTURE DEVELOPMENTS WILL FOCUS ON SYSTEMS FOR
LARGER MACHINES, TO BE DONE IN A MACHINE-INDEPENDENT SYSTEMS IMPLEMENTATION
LANGUAGE. <MSX WILL CONTINUE AS A SIMULATOR AND APPLICATIONS SYSTEM,
HOWEVER.
^THE CURRENT SYSTEM HAS BEEN WELL CHECKED OUT IN EMULATION MODE, AND
THE SECURITY CODE HAS BEEN EXERCISED, THOUGH ALL POSSIBLE COMBINATIONS
OF LEVELS AND SPECIAL CATEGORIES HAVE NOT BEEN TRIED, AND NOT ALL
THE POSSIBLE TRANSITIONS HAVE BEEN INVESTIGATED.
.PARAGRAPH
^THE <MSX SYSTEM HAS SHOWN THAT GLOBAL NAMING IS SOMEWHAT SPACE INEFFICIENT
AND GENERATES SOME APPLICATION DEVELOPMENT DIFFICULTIES. ^WHILE TASKS
REALLY NEED TO BE KNOWN IN <MSX ONLY WITHIN THE DOMAIN OF <CPU\S IN
WHICH THEY WILL EXECUTE OR COMMUNICATE, THEY TEND TO BE EVERYWHERE
DEFINED. ^THUS, SECOND COPIES OF A TASK MUST HAVE DIFFERENT NAMES, WHICH
WOULD BE EASIER IF THE PATH TO A TASK (SAY, IN A HIERARCHY) WERE
MADE PART OF ITS NAME, AND IF KERNEL SPACE USED FOR TASK TABLES COULD BE
USED ONLY WHERE THE TASK REALLY DID NEED TO BE KNOWN IN THAT <CPU.
^THE SIMPLEST IMPLEMENTATION WOULD HAVE TO RESTRICT THE <CPU DOMAIN
OF A HIERARCHY (LIKELY ANYWAY WHERE HIERARCHIES MAY SHARE MEMORY)
BUT COULD THEN RESTRICT NAMES' USE SO THAT A MESSAGE TO TASK ^X WOULD
MEAN "THE TASK ^X THAT IS IN MY FAMILY".

.PARAGRAPH
^ANY LARGER-CONFIGURATION DESCENDANT OF <MSX WILL REQUIRE PRIMITIVES FOR
HANDLING MEMORY PAGING IN A SECURE FASHION, AND SYSTEMS OF MORE GENERAL
CONNECTIONS MAY HAVE TO CONSIDER ALLOCATING SWITCHING RESOURCES AND SEVERAL
PROCESSORS PER TASK. ^AGAIN, TO SIMPLIFY GLOBAL NAMING, A RESOURCE ALLOCATION
SCHEME THAT ALLOCATES RESOURCES OR DOMAINS TO AN ENTIRE TASK HIERARCHY
IN WHICH A DISPATCHER WOULD FORWARD ALL MESSAGES AMONG MEMBERS AND IN WHICH
THE EXECUTIVE WOULD KNOW ONLY DISPATCHER NAMES MIGHT PROVIDE A SOLUTION.
^THIS IS A DESIGN CONSIDERATION FOR LATER SYSTEMS; <MSX WILL NEVER HAVE
THIS FUNCTIONALITY. ^THE PRESENT <MSX IMPLEMENTATION TREATS THE NUMBER OF
TASKS IN A <CPU AS THE ONLY MEASURE OF <CPU ACTIVITY, AND DOES NOT
PROVIDE ANY MEANS FOR CO-LOCATING TASKS IN A <CPU. ^THIS HAS PREVENTED SOME
NETWORK ISSUES FROM ARISING. ^HOWEVER, IT HAS BECOME CLEAR THAT THE
TASK ALLOCATION MUST BE TERMINATED ARBITRARILY AT SOME POINT. ^WHERE
A <CPU IS ALLOWED TO RE-ARBITRATE TASK LOCATION, THE TASK MAY WIND UP
SPENDING LONG TIMES "BEING ACTIVATED" AS OTHER TRAFFIC CAUSES THE
MESSAGES TO CROSS THAT WOULD BRING THE SYSTEM INTO EQUILIBRIUM. ^CURRENTLY
NO RE-ARBITRATION IS DONE; THE SYSTEM NEVER GETS FAR OUT OF BALANCE
(1 TASK MORE OR LESS THAN OPTIMUM AT WORST, AND THAT RARELY) WITH PURE
LOCAL ARBITRATION AND A GLOBAL BUS TOPOLOGY. ^THIS SITUATION WOULD
PROBABLY CHANGE WITH A NET OF GREATER INTERPROCESSOR "DISTANCE"
AND IT WOULD BE DESIRABLE TO PERMIT SOME RE-ARBITRATION.

.SKIP 3
.TEST PAGE 20
.CENTER
<CONCLUSION
.PARAGRAPH
<MSX IS AN ATTEMPT TO MOVE IN THE DIRECTION OF HAVING A SECURE SYSTEM
RUNNING ON NUMEROUS <CPU\S, PREFERABLY WITH EACH <CPU RUNNING
APPLICATIONS AT A SINGLE CLEARANCE. ^THIS SEEMS A MORE PLAUSIBLE
APPROACH TO A SECURE COMPUTER SYSTEM THAN ONE BASED ON A VERY LARGE
SINGLE PROCESSOR WHERE
SECURITY ISSUES ARE COMPLICATED BY THE NEED TO PROVIDE THE LEVEL OF
SERVICE ONE EXPECTS OF A LARGE <CPU WHILE AT THE SAME TIME KEEPING MANY
USERS FROM CROSSTALK. (^A SYSTEM BASED ON NUMEROUS LARGE PROCESSORS
IS EQUALLY PLAUSIBLE.) 
<MSX PROVIDES INSIGHT INTO THE PROBLEMS OF TASK STARTUP, EXITING,
AND COMMUNICATIONS. ^BECAUSE IT CAN RUN AS AN EMULATION, IT ALLOWS
TESTS OF APPLICATIONS PRIOR TO DEVELOPMENT OF HARDWARE. ^ITS TASK
NAMING IS LESS EFFICIENT THAN MIGHT HAVE BEEN DESIRED, AND
IT NEEDS TO HAVE SOME MEANS WHEREBY A WATCHDOG TASK CAN RE-ROUTE
COMMUNICATION WITHOUT REVERSING ANY MESSAGE ORDERING, SINCE THE
SYSTEM AND THE TASKS WILL EXPECT <FIFO ORDERING.
^EVEN WITH THESE LIMITATIONS, HOWEVER, <MSX HAS BEEN A VALUABLE TOOL
FOR INVESTIGATING THIS CLASS OF COMPUTING PROBLEMS.