Trailing-Edge - PDP-10 Archives - BB-H311D-RM - documentation/execute-only.memos
There are 5 other files named execute-only.memos in the archive. Click here to see a list.

!   !   !   !   !   !   !   !
! d ! i ! g ! i ! t ! a ! l !  i n t e r o f f i c e  m e m o r a n d u m
!   !   !   !   !   !   !   !

To:     TOPS-20 Monitor Memo List


                                        From:   Tom Porcher

                                        Dept:   LCG Software Engineering

                                        Loc:    MR1-2/E37   Ext: 231-6877

                                        Date:   1-Feb-78

                                        PDM:    TCP-78-001-00-S

Subject:  Execute-Only Files on TOPS-20

This  is  the  latest,  revised,  version  of   my   specification   for
execute-only files on TOPS-20.  Of particular interest to most people is
Section 2, specifically 2.3 and 2.5.

Execute-only files will be  implemented  in  Release  4  of  TOPS-20  as
described in this specification.
To: TOPS-20 Monitor Memo List                                     Page 2
Subject:  Execute-Only Files on TOPS-20

                           Specification for:

                     Execute-Only Files on TOPS-20


This memo is intended to describe the changes necessary  to  TOPS-20  to
provide an execute-only file capability on TOPS-20.


2.1  Definition

The basic definition of an execute-only  file  is  one  that  cannot  be
copied or read in a normal manner, but can be run as a program.

In order to provide this capability, the following constraints  must  be
placed on a file to be called an execute-only file:

     1.  The file must be protected  with  EXECUTE  access  allowed  but
         without READ access allowed.

     2.  The  file  cannot  be  read  or  written  using  any   of   the
         file-oriented   monitor  calls  (i.e.   SIN,  SOUT,  BIN,  PMAP
         referencing a file, etc.).  The  TOPS-20  file  system  already
         provides  this  protection  through the use of OPENF and access

     3.  The file can be mapped into a process (via GET),  but  only  in
         its entirety and only into a virgin process.

         A process so created will be called an execute-only process.

An execute-only process must be restricted in the following ways:

     1.  No  other  process  can  read  anything  from  an  execute-only
         process' address space or accumulators.

     2.  No other  process  can  change  any  part  of  an  execute-only
         process'  context  in  such  a way as to cause the execute-only
         process   to   reveal   any   part   of   its   address   space

Some other related definitions:
To: TOPS-20 Monitor Memo List                                     Page 3

     1.  A "virgin process" is one that has  just  been  created  (using
         CFORK)  but  no operations which change its context or map into
         the process have been performed on the process.

     2.  The "context" of the process includes its  address  space,  PC,
         AC's, interrupt system, traps, etc.

2.2  Non-definitions

The following attributes sometimes associated with execute-only are  not
being  implemented.   Some  of  these features are descibed in detail in
section 4.

     1.  Hardware concealment of process pages.  The KL10  hardware  has
         the  capability  to  conceal  pages within a process from other
         parts of the  same  process.   This  feature,  if  used,  would
         provide  the  additional feature that non-execute-only programs
         could load execute-only programs into their address space, such
         as an execute-only Object Time System.

     2.  Protection from meddling with the operation of a process.   The
         protection  provided  is  the  minimum protection required such
         that an execute-only process does not reveal its address  space
         unintentionally.  Additional protection would be required for a
         "no-meddle" capability.  This capability would  be  useful  for
         programs  that  want  to  assure the integrity of a database or
         programs that possess restricted capabilities.

     3.  Additional  capabilities  provided  by  file  attributes.    No
         additional   capabilities  will  be  provided  to  execute-only
         programs.  A file  attribute  could  be  added  which  provided
         additional capabilities to a process when it was executed.

     4.  Protection of  other  processes  mapped  from  an  execute-only
         process.   Thus  it  is  possible to examine pages in a process
         which is created by an execute-only process and which has pages
         mapped from the execute-only process.

     5.  Protection  of  programs  from  programming  errors.    If   an
         execute-only  program  reveals itself in any way, regardless of
         whether  it  was  intentional  or  a  programming   error,   no
         protection will be provided.  It is assumed that the programmer
         understands that his program will be execute-only and will code
To: TOPS-20 Monitor Memo List                                     Page 4

2.3  User Implications

A program will be execute-only for particular users based  on  its  file
protection.   If  a user tries to RUN a file and can't READ it, but does
have EXECUTE access, a process will be created as usual.  The file  will
be  mapped into this "virgin" process, circumventing the READ protection
on the file.  This process will then be an "execute-only" process.  This
process cannot be manipulated (examined, written, or mapped in any way).

Some of the characteristics that a TOPS-20 user would  see  relating  to
execute-only files and processes:

     1.  Users may select a file to be execute only by allowing  EXECUTE
         but  not  READ access to the file.  This can be done by setting
         the protection field for the desired  class  of  users  (owner,
         group  or world) to FP%EX+FP%DIR, or 12 octal.  For example, to
         make a file execute-only for everybody except the owner of  the
         file, set the protection to 771212 octal.

         The SET  FILE  PROTECTION  command  can  be  used  to  set  the
         protection,  or  the  ;P  attribute  can be applied to the file
         specification in the SAVE or CSAVE command.

     2.  Most programs (.EXE files) can be protected execute-only.  Some

         1.  Any independent program run by the EXEC.

         2.  A saved image of a FORTRAN, COBOL, or BASIC program.   Note
             that it is up to the compilers to produce code which GETs a
             certified version of the Object Time System (i.e.  NOT from
             the user's directory) for the selected language.

         Some programs which cannot be execute only:

         1.  Any Object Time System (OTS).

         2.  The TOPS-10 Compatability Package (PA1050).

         3.  The Record Management System (RMS).

         4.  Any program to be run by the TOPS-10 UUOs RUN or GETSEG.

         5.  Any program which needs  to  be  started  at  any  location
             except its entry vector (START or REENTER address).

         6.  Any program with undefined entry points (not 0 or 1 in  the

         7.  Any program that uses TOPS-10 style "CCL starts"  (starting
             at the start address plus one).
To: TOPS-20 Monitor Memo List                                     Page 5

         8.  A    compiler    or    linker    invoked    through     the
             COMPILE/LOAD/EXECUTE/DEBUG commands (because of CCL start).

         PAGE-ACCESS,  SET  ADDRESS-BREAK  commands  will  not  work for
         execute-only programs.

     4.  The CONTINUE  command  will  not  work  after  an  execute-only
         process is halted.

     5.  The START command cannot be used with a start address  argument
         for an execute-only process.

     6.  the INFORMATION (ABOUT) VERSION command  will  not  return  the
         version of an execute-only program.

     7.  A program which is execute-only  must  be  written  to  protect
         itself.   The  program  should  not  map itself out to inferior
         processes.  The program should not  GET  and  execute  programs
         into its address space for which it has no control.  Generally,
         the programmer should take some care in protecting itself if it
         is to be execute-only.

2.4  Technical Implications

There are some general implications of this definition:

     1.  The JSYSes which allow access to other process'  address  space
         must  be  restricted for execute-only processes.  This prevents
         direct copying of the execute-only file from the address space.

     2.  The JSYSes which change a process' context must  be  restricted
         for  execute-only processes.  This prevents a malicious process
         from changing the context of an execute-only process in such  a
         way as to reveal itself.  An obvious example of this is mapping
         a routine into the execute-only process which then  writes  the
         entire  address  space  out to a file.  Less obvious is causing
         the execute-only process to start at  a  random  address  which
         (unintentionally) does the same thing.

     3.  An execute-only process  can  be  started  only  at  its  entry
         vector.   This  prevents  starting the program at unpredictable

     4.  A process which is created by an execute-only process with  the
         same address space (using CFORK) must also become execute-only.
         This prevents another process from copying the file through the
         address  space  of  the  process  created  by  the execute-only
         process.  This allows an execute-only process to  create  lower
         processes which map its address space.
To: TOPS-20 Monitor Memo List                                     Page 6

     5.  A GET of an execute-only  file  will  work  only  to  a  virgin
         process.   This  prevents  the  context  of  the  process  from
         starting out on the wrong foot;  i.e.   with  code  already  in
         memory  to  dump the address space to a file or with pages from
         the process already mapped to another process.

     6.  GET will work only on the entire execute-only file.  This is to
         prevent the malicious user from starting only part of a program
         which may have the effect of revealing itself.

     7.  GET must be able to  get  an  execute-only  file  without  READ
         access.   READ  access is required to read or map the file into
         the process' address  space;   thus  GET  must  circumvent  the
         existing file access checking.

     8.  GET must have special  access  to  PMAP  into  an  execute-only
         process.   In  order  to  prevent  access to a process which is
         currently GETting an execute-only file,  the  process  must  be
         marked as execute-only.  However, the process executing the GET
         must be allowed access to the execute-only process so as to use
         PMAP from the file into the execute-only process.

     9.  Monitor-executed  GETs  of  PA1050  and  RMS  for  execute-only
         processes must be restricted to physical SYS:.  This prevents a
         user version of "PA1050" from being loaded into an execute-only
         process,  which  merely  copies the address space out to a file
         when a UUO is executed.  Likewise with RMS and RMS functions.

2.5  Restrictions And Drawbacks

     1.  Only entire files may be protected - there is  no  page-by-page
         access control.

     2.  Only disk-resident files can be considered execute-only.

     3.  GET will only work on an entire execute-only file.

     4.  An execute-only process cannot map  any  part  of  its  address
         space  into  another  process, with the exception of creating a
         copy with CFORK.

     5.  PA1050,  RMS  and  any  other  Object-Time  Systems  cannot  be
         execute-only.  This is due to the fact that they must be mapped
         into a non-virgin address space.

     6.  The TOPS-10 UUOs RUN and GETSEG will not work  on  execute-only
         files.   As  above,  these UUOs require mapping into non-virgin
         address space.
To: TOPS-20 Monitor Memo List                                     Page 7

     7.  PA1050 and RMS must exist on  physical  (system  logical  name)
         SYS:   for  execute-only  programs.   These  versions should be
         certified to protect the process' address space into which they
         will be mapped and to which they will have access.

     8.  A user cannot use his own version of PA1050  and  RMS  with  an
         execute-only program.

     9.  Having WHEEL capability enabled will allow READ  access;   thus
         execute-only  processes  will not be created by WHEELs and will
         not be protected from other processes within that job.   It  is
         assumed  that  a  WHEEL process is responsible for its actions.
         To perform a  GET  and  create  an  execute-only  process,  the
         program should disable WHEEL and re-enable it after the GET, if

    10.  The version of an execute-only process cannot be read since  it
         is  in the entry vector.  Thus INFORMATION (ABOUT) VERSION will
         not return the program version if the program is execute-only.

    11.  TOPS-10 style  "CCL  starts"  (starting  at  the  normal  start
         address  plus  one)  will not work.  This affects any compilers
         and   linkers   which   are   currently    invoked    by    the

    12.  The  SET  NO  UUO-SIMULATION  command  cannot  be   used   when
         execute-only  programs  are  to be run.  This is because SET NO
         UUO-SIMULATION changes the Compatability Package entry vector.

    13.  The version of an execute-only program cannot be read, since it
         is stored only in the program's address space.

    14.  Inferiors of an execute-only process  which  has  pages  mapped
         from their superior will not be protected.  Thus the programmer
         must be careful not to reveal itself through its inferior.

    15.  There will be no JSYS  to  explicitly  indicate  that  a  given
         process  is  an  execute-only  process.   Note  that RFACS will
         always fail for an execute-only process and can be used to  get
         this information, if someone actually can find a use for it.
To: TOPS-20 Monitor Memo List                                     Page 8


3.1  Control Structure

Three additional bits of process status will control the manipulation of
execute-only  processes.   These  bits  will be in the SYSFK area in the
job's Job Storage Block (JSB).  This part  of  the  JSB  is  indexed  by
job-relative  fork  number (JRFN), one word per process in the job.  The
new bits are defined as follows:

     1.  SFVGN - This is a "virgin" process.  This bit is set  by  CFORK
         when  a  new process is created without any mapping and without
         starting  the  process.   SFVGN   is   cleared   whenever   any
         context-changing JSYS addressing the process is executed.  Note
         that all JSYSes  and  JSYS  functions  which  are  illegal  for
         execute-only processes will clear this bit.

     2.  SFEXO - This is an execute-only process.  This bit is set  when
         either  a GET of an execute-only file occurs to this process or
         CFORK creates a process which  maps  an  execute-only  process.
         SFEXO is cleared only by CFORK when creating a new process.

     3.  SFGXO - This process is doing an execute-only GET.  This bit is
         set  in  the  process  executing  a GET of an execute-only file
         during the GET process so that PMAP will allow the file  to  be
         mapped into the execute-only process.

3.2  General Subroutines

3.2.1  CHKNXS - Check If Not Execute-only Or SELF - Routine CHKNXS  will
be  added to the general process-testing routines in the process module.
This routine will return if the process specified in T1 is  either  SELF
or  not an execute-only process.  Otherwise, an illegal instruction trap
will occur, returning the error mnemonic FRKHX8 - "Illegal to manipulate
an execute-only process".

If the specified process  is  not  execute-only,  it  will  be  declared
non-virgin by clearing the virgin process bit SFVGN.

The process structure must be locked when this call is made.

        T1/     Job-relative fork number to be tested
        +1:     Always
To: TOPS-20 Monitor Memo List                                     Page 9

3.3  Not-so-general Subroutines

3.3.1  SETEXO - Make Process Execute-only - This routine  in  FORK  will
cause  the  selected  process to become execute-only.  If the process is
not virgin, then this will not succeed.

This routine is needed by GET and CFORK.

        T1/     Job-relative fork number to become execute-only
        +1:     Process is not virgin and cannot be made execute-only
        +2:     Process is now execute-only

3.3.2  SETGXO/CLRGXO - Enable/Disable Execute-only GET Status - These
routines  set  and clear the execute-only GET bit (SFGXO) in the current
process.  These routines are called by GET to allow it to  map  into  an
execute-only process.

        +1:     Always

3.3.3  SREADF - Set READ Access And Restricted-access - This routine  in
IO  will  set  the READ access bit (READF) and the restricted-access bit
(FRKF) in the status word for the  selected  JFN.   Also,  the  previous
state of the FRKF flag will be returned.

This routine will only be called from GET.  This routine is required  to
allow GET to use BIN, SIN, PMAP, etc.  to a file opened only for execute

        T1/     JFN
        +1:     Always
        T2/     Previous state of FRKF in LH,
                process for FRKF in RH
To: TOPS-20 Monitor Memo List                                    Page 10

3.3.4  CREADF - Clear READ Access And Restricted Access - This   routine
un-does what SREADF did.

        T1/     JFN
        T2/     Previous state of FRKF in LH,
                process for FRKF in RH
        +1:     Always

3.4  New Error Mnemonics

3.4.1  FRKHX8 - Illegal to manipulate an execute-only process

3.5  JSYS Changes

3.5.1  Restricted JSYSes - The following JSYSes or JSYS functions  which
either  change  a process' context or allow access to a process' address
space will be restricted for execute-only processes.  For each of  these
JSYSes  or  functions,  a  call to routine CHKNXS will be added.  If the
process is execute-only and not SELF, then an illegal  instruction  trap
will  occur  for  the  executing  process.   The error mnemonic FRKHX8 -
"Illegal to manipulate an execute-only process" will be returned.

The JSYSes marked with an asterisk ("*") require special  considerations
and are described in detail below.

     1.  CFORK - *

     2.  SFORK

     3.  SPACS

     4.  PMAP - *

     5.  RFACS

     6.  SFACS

     7.  SFRKV - vector locations other than 0 or 1

     8.  SIR

     9.  EIR

    10.  DIR
To: TOPS-20 Monitor Memo List                                    Page 11

    11.  AIC

    12.  IIC

    13.  DIC

    14.  SIRCM

    15.  STIW

    16.  GET - *

    17.  SAVE

    18.  SSAVE

    19.  SEVEC

    20.  SCVEC

    21.  SDVEC

    22.  ADBRK - functions .ABSET, .ABCLR

    23.  TFORK -  functions  .TFSET,  .TFRAL,  .TFRTP,  .TFUUO,  .TFSJU,

    24.  UTFRK

    25.  SETER

    26.  CRJOB - *

3.5.2  Special Case Restrictions -  CFORK - 

CFORK creates a virgin process if CR%ST (start process) and CR%MAP (give
process  same  map  as creating process) are not set.  Note that loading
parameters in the ACs using CR%ACS  does  not  make  this  a  non-virgin
process.   Setting  CR%ST  and  either  CR%ACS or CR%MAP would allow the
process to execute code  so  therefore  makes  the  process  non-virgin.
Setting CR%ST without CR%MAP or CR%ACS seems rather useless.

CFORK creates an execute-only process if  bit  CR%MAP  is  set  and  the
creating  process  is  an  execute-only  process.   This is the only way
(besides GET) to create an execute-only process.
To: TOPS-20 Monitor Memo List                                    Page 12

It is illegal to specify an execute-only process as either the source or
the destination in a PMAP call unless it is SELF.

If the executing process is doing a GET of an execute-only  file  (SFGXO
set), then the process may map pages into any execute-only process.  GET - 

A GET call which addresses an execute-only process is illegal unless the
process is SELF.

If the JFN specified in the GET call refers to a file for which the user
only  has  execute  access,  then the process specified must be a virgin
process.   GET  must  overcome  two  protection  features  to   GET   an
execute-only file:

     1.  Reading the file without READ access (and not  allowing  others
         access at the same time).

     2.  Mapping pages from the file into an execute-only process.

In order to allow the GET to succeed, the following steps are performed:

     1.  Perform OPENF on the file for READ and EXECUTE (as always).

     2.  If the OPENF succeeds, then proceed as usual (at step 13) since
         the file is not execute-only access.

     3.  If the  OPENF  for  READ  and  EXECUTE  fails  and  either  the
         specified  process is not virgin or GT%ADR (address limits) was
         specified, return the error from the OPENF.

     4.  Perform OPENF for only EXECUTE access.

     5.  If this OPENF fails, return the error from the OPENF.

     6.  Lock the process structure.

     7.  Set the execute-only bit (SFEXO) in the destination process  by
         calling  SETEXO.  If the destination process is not virgin, the
         execute-only bit will not be set and:

         1.  Unlock the process structure.

         2.  Close the file (but don't release the JFN).

         3.  Restart at step 1, returning the OPENF error this time.
To: TOPS-20 Monitor Memo List                                    Page 13

     8.  Unlock the process structure.

     9.  Remember that this will be an execute-only GET.

    10.  Disable interrupts within this process  (NOINT).   This  is  to
         protect  the  use of READ access to the file and the use of the
         execute-only GET bit (SFGXO).

    11.  Set READ access and restricted-access in the JFN status for the
         selected JFN by calling SREADF.

    12.  Set the execute-only GET bit (SFGXO) in the  executing  process
         by calling SETGXO.

    13.  Perform the normal operations required to GET the file into the

    14.  If any errors occur, proceed as below but return error.

    15.  If this was an execute-only GET:

         1.  Clear the READ access  and  restricted-access  in  the  JFN
             status by calling CREADF.

         2.  Clear the execute-only GET bit  (SFGXO)  in  the  executing
             process by calling CLRGXO.

         3.  Enable process interrupts (OKINT).

    16.  Close the file (if possible) using CLOSF.  Note that  if  pages
         are  mapped  from  the file, it will not be closed, but will be
         left open with only EXECUTE access.  CRJOB - 

When CRJOB creates a new job, it also  creates  the  top-level  process.
CRJOB  will  always  create  a  virgin  process.   Thus, an execute-only
program can be RUN as the top-level fork.

3.5.3  JSYSes Not Affected - 
To: TOPS-20 Monitor Memo List                                    Page 14
IMPLEMENTATION  Context-changing JSYSes - The  following  JSYSes   affect   the
context  of  a process.  However, their effect cannot cause a process to
reveal its address space.

     1.  SPLFK

     2.  EPCAP

     3.  CLZFF

     4.  SCTTY

     5.  SPJFN

     6.  HFORK

     7.  KFORK

     8.  RFORK

     9.  FFORK

    10.  PRARG

Note that all the  file  JSYSes  can  also  change  the  context  of  an
execute-only process!  Other JSYSes - The following JSYSes reference  other  processes
but  neither reveal the process' address space nor change the context of
the process.

     1.  GETER

     2.  ERSTR

     3.  RUNTM

     4.  GTRPI

     5.  GTRPW

     6.  RIR

     7.  SKPIR

     8.  RCM

     9.  RWM

    10.  RIRCM
To: TOPS-20 Monitor Memo List                                    Page 15

    11.  RTIW

    12.  RPCAP

    13.  WFORK

    14.  RFSTS

    15.  RFRKH

    16.  GFRKS

    17.  RMAP

    18.  RPACS

    19.  GEVEC

    20.  GCVEC

    21.  GDVEC

    22.  RTFRK  Privileged JSYSes - The follow JSYSes reference  processes  but
are  privileged.   These  JSYSes will not be restricted for execute-only

     1.  SPRIW

     2.  MSFRK

3.6  Other Monitor Changes

3.6.1  Monitor-executed GETs Of PA1050 And RMS - 

The monitor must assure that only a certified copy of PA1050 or  RMS  is
loaded  for  execute-only  processes.  This certified copy is assumed to
exist on physical (system logical  name)  SYS:.   When  an  execute-only
process  requests  PA1050  or  RMS,  the monitor will set GJ%PHY for the
To: TOPS-20 Monitor Memo List                                    Page 16

3.6.2  Use Of Restricted-access JFNs - 

Currently, the restricted-access JFN bit (GJ%ACC) in the GTJFN call only
restricts  the  JFN  from  inferiors of the owning process.  The routine
CHKJFN would have to be  modified  to  restrict  the  JFN  to  a  single
process.   The  JFN could only be accessed after the process was KFORKed

This change is required for the execute-only GET code.

3.7  EXEC Changes

Some changes are required to the TOPS-20 Command Processor (EXEC).

3.7.1  Illegal Instruction Processing - Currently the  EXEC  prints  the
offending  instruction if an illegal instruction trap should occur.  The
EXEC should not print the instruction if it  can't  access  the  process
(because it is execute-only).

3.7.2  EXAMINE/DEPOSIT Commands - These commands should neatly print the
error  string  if  the  process  access  JSYSes  should trap because the
selected process is execute-only.

3.7.3  TOPS-10 Compatable START/REENTER/DDT Commands - These    commands
cannot call PA1050 if the process is execute-only, as they currently do.

3.7.4  RDMAIL - The EXEC's  interface  to  RDMAIL  implies  that  RDMAIL
cannot be execute-only.

3.7.5  INFORMATION (ABOUT) VERSION Command - The    version    of     an
execute-only  process cannot be read.  The EXEC should just not print it
if the process is execute-only.

should be neat about the error string also.
To: TOPS-20 Monitor Memo List                                    Page 17


Below are descriptions of some  features  related  to  execute-only  not
planned for implementation but available for comment.

4.1  Hardware Page Concealment

4.1.1  Definition - 

Page concealment is a feature of the KI10  and  KL10  hardware  allowing
part  of  an  address space to be concealed from the rest of the address
space.  Pages marked as  concealed  can  only  be  transferred  into  at
locations containing a PORTAL (JRST 1,) instruction.

Using page concealment would have to be used  in  conjunction  with  the
execute-only  implementation  described above.  This is because it seems
useless to protect a part of an  address  space  from  the  rest  of  it
without also protecting it from other processes via the JSYSes.

The following additional features would be gained from this:

     1.  It would be  possible  to  GET  an  execute-only  file  into  a
         non-virgin  address space, marking it as concealed.  This would
         be the case of a non-execute-only program using an execute-only

     2.  The TOPS-10 UUO's GETSEG and RUN  would  work  on  execute-only

The following restrictions would apply:

     1.  No execute-only program can GET  another  execute-only  program
         into  its address space.  This restriction affects execute-only
         programs desiring to use execute-only OTSes.

     2.  Only one execute-only segment  can  exist  PER  JOB.   This  is
         because any process running concealed can map any other process
         running concealed through indirect map pointers.  To  eliminate
         this  restriction  would require significant changes to the way
         KL paging works in the hardware.

     3.  This type  of  concealment  would  only  be  available  on  the
         processors that support it;  i.e.  the KI10 and KL10.  The KS10
         does not support page concealment.
To: TOPS-20 Monitor Memo List                                    Page 18

4.1.2  Possible Implementation - 

Inplementation would include the following:

     1.  All pages created (by whatever means) will be marked as Public.

     2.  GET of an execute-only program would set the Concealed  bit  in
         each page that was loaded from the file.

     3.  SFORK and SFRKV would enter in Public  mode  so  as  to  requre
         concealed pages to have PORTALs.

4.2  Meddle Protection

4.2.1  Definition - 

Basiclly, meddle protection implies that a program  so  protected  would
always  be  able  to  run to completion in an orderly fashion.  Programs
which would need this type  of  protection  would  be,  for  example,  a
database manager which wants to keep its database consistent.

This implies that the only way a meddle-proof fork could be killed is by
the  fork  halting under its own control (or by panic channel interrupts
not enabled for).

4.2.2  Possible Implementation - 

Part of the burden must be placed on the user program to be  intelligent
enough  to  handle  all  existing traps.  Also the user must protect his
program as execute-only if the user also wants that protection.

Some of the changes required would be:

     1.  A new file attribute would indicate meddle-proof-ness.

     2.  A  method  of  setting  the  meddle-proof  attribute  would  be

     3.  GET would check the meddle-proof status when it loads the file,
         and set a per-process status bit accordingly.

     4.  All JSYSes which  affect  the  interrupt  system  would  become
         restricted.   These include SIR, EIR, DIR, AIC, IIC, DIC, STIW,

     5.  All JSYSes which freeze a process must  be  restricted.   These
         include ADBRK, TFORK, UTFORK, FFORK, RFORK.
To: TOPS-20 Monitor Memo List                                    Page 19

     6.  JSYSes which change capabilities  must  be  restricted.   These
         include EPCAP.

     7.  JSYSes which change the  fork  structure  must  be  restricted.
         These include SPLFK.

     8.  JSYSes which stop or reset a fork must  be  restricted.   These
         include  KFORK, HFORK, RESET.  These JSYSes would be legal only
         if the meddle-proof fork was  halted.   Possibly  these  should
         cause an interrupt in the meddle-proof fork.

     9.  The EXEC must be changed to do something more  reasonable  with
         the new errors from these JSYSes.

4.3  Process Capabilities From Files

4.3.1  Definition - This feature would allow a file to give a particular
process  more  capabilities  than it normally would have.  This would be
useful, for example, for an operator to run a DUMPER which had full file
access capability, which the operator would not have.

4.3.2  Possible Implementation - 

As with  meddle-proof-ness  above,  the  user  program  must  take  some
responsibility  for  protection  of the additional capabilities granted.
This includes using the execute-only and meddle-proof features described

Some of the changes that would be required would be:

     1.  Add a file attribute called Additional Capabilities.

     2.  Add a method of setting this attribute.  Only a user  with  the
         requested  capabilities could give them to any particular file.
         Thus a user with insufficient capabilities could not  copy  the
         file without decreasing the capabilities it provides.

     3.  GET would OR the existing capabilities of the process with  the
         Additional  Capabilities  that a file provides for the process.
         This would only occur for virgin processes.


!   !   !   !   !   !   !   !
! d ! i ! g ! i ! t ! a ! l !  i n t e r o f f i c e  m e m o r a n d u m
!   !   !   !   !   !   !   !

To:     TOPS-20 Meeting Attendees


                                        From:   Tom Porcher

                                        Dept:   LCG Software Engineering

                                        Loc:    MR1-2/E37   Ext: 231-6877

                                        Date:   17-Jan-78

                                        PDM:    TCP-78-002-00-S

Subject:  Restricted Access and Execute-Only 


This memo is an addendum to the  specification  "Execute-Only  Files  on
TOPS-20",  written  by me and dated 13-Jan-77.  If you haven't read that
spec, I suggest that you do before you read this.

I mentioned the capability of restricting a JFN to a particular process,
needed in order to perform a GET of an execute-only file.  I intended to
use the control excercised by GTJFN with  GJ%ACC,  and  not  OPENF  with
OF%RTD as the spec said.

The documentation  for  these  functions  and  related  JSYSes  is  very
unclear.   I  would like to point out where the documentation is unclear
and what additional functionality is required  to  support  execute-only
files on TOPS-20.

1.1  Existing Related Functions

Just to clarify what exists and its  relation  to  what  is  needed  for
execute-only, let's see how things work now.

1.1.1  GTJFN With GJ%ACC - Setting GJ%ACC in the  GTJFN  call  restricts
the  JFN  from use by any of the inferiors of the process performing the
GTJFN.   This  will  be  called  "restricted  JFN  access".   Note  that
superiors  still  have  access to the JFN and another process can always
access the same file by using a different JFN.  Also,  GTSTS  (get  file
status) always works regardless of whether a JFN is restricted or not.
To: TOPS-20 Meeting Attendees                                     Page 2

This function is well documented in the  TOPS-20  Monitor  Calls  manual
under GTJFN.

1.1.2  OPENF With OF%RTD - This restricts the file which  is  opened  to
the  JFN  which  it  is currently opened on.  Thus, no other process can
open another  JFN  on  the  file  in  question.   This  will  be  called
"restricted file access".  However, another process can use the same JFN
to access the file (unless it is restricted using GJ%ACC above).

This function is not clearly documented.  It in fact mentions  "process"
where OF%RTD is not related to any process.

1.1.3  CLZFF With CZ%UNR - Setting CZ%UNR (unrestrict JFNs) in the CLZFF
(close  process'  files)  call  removes only the JFN access restrictions
implied by setting GJ%ACC.  This call may be executed  by  any  superior
process to the process which got the JFN with GTJFN and set GJ%ACC.

This function is documented very poorly.  It is not clear  whether  this
function removes what GJ%ACC did or what OF%RTD did, or both.

1.1.4  GTSTS (GS%FRK Bit) - This bit means that  this  is  a  restricted
access  JFN,  i.e.   GJ%ACC  was set in the GTJFN call for the JFN whose
status was requested.

The documentation of this bit is wrong, or at least very  dubious:   "If
the  file  is  open,  it  is  open for restricted access".  This implies
restricted file access, provided by OF%RTD in OPENF.

1.1.5  STSTS (GS%FRK Bit) - Setting this bit in the STSTS  call  has  no
effect.   Clearing  this bit in the STSTS call will clear restricted JFN
access, provided by GJ%ACC in the GTJFN call.  This, like all the  other
file  JSYSes,  requires  the  executing  process  to  be superior to the
process who set GJ%ACC if it is a restricted access JFN.

The documentation of the GS%FRK bit is, as with GTSTS, wrong.  Also  the
documentation  does  not  indicate that you can only clear (and not set)
any of the bits which you can modify (GS%ERR, GS%HLT, GS%FRK).

1.2  Functions Required By Execute-only

The GET code for an execute-only file has to have the execute-only  file
open  for  READ.   However, it is mandatory that no other processes have
access to this JFN while the file is open for READ, since they would  be
able to steal the execute-only program.
To: TOPS-20 Meeting Attendees                                     Page 3

Thus, restricted JFN access is required, but the  restrictions  must  be
stronger  than those currently provided by GTJFN (GJ%ACC).  The JFN must
be restricted for use only by the process performing the GET.  Note that
the following additional capabilities would be required for execute-only

     1.  JFN usage restricted to a single process (no superiors).

     2.  JFN usage restricted to the process performing the OPENF or GET
         (not the one performing the GTJFN).

This could be implemented by either:

     1.  modifying the way restricted JFN access works now or

     2.  adding a new OPENF function or

     3.  adding a monitor-internal restriction mechanism to be used only
         by GET.

1.3  Functions Required By Meddle-proof-ness

In order to implement meddle-proof-ness (which is not  yet  planned),  a
facility  to  restrict  JFN usage to a single process is required.  Note
that this is similar to the requirements of  GET  above,  but  does  not
require the OPENFing process to be the owning process.