Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_3_19910112
-
stanford/5-swskit/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
CC:
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
1.0 INTRODUCTION
This memo is intended to describe the changes necessary to TOPS-20 to
provide an execute-only file capability on TOPS-20.
2.0 DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
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
checks.
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
unintentionally.
Some other related definitions:
To: TOPS-20 Monitor Memo List Page 3
DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
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
accordingly.
To: TOPS-20 Monitor Memo List Page 4
DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
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
exmaples:
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
vector).
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
DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
8. A compiler or linker invoked through the
COMPILE/LOAD/EXECUTE/DEBUG commands (because of CCL start).
3. The EXAMINE, DEPOSIT, MERGE, DDT, SET ENTRY-VECTOR, SET
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
locations.
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
DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
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
DEFINITION OF EXECUTE-ONLY FILES AND PROCESSES
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
required.
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
COMPILE/LOAD/EXECUTE/DEBUG commands.
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
IMPLEMENTATION
3.0 IMPLEMENTATION
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.
Call:
T1/ Job-relative fork number to be tested
CALL CHKNXS
Returns:
+1: Always
To: TOPS-20 Monitor Memo List Page 9
IMPLEMENTATION
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.
Call:
T1/ Job-relative fork number to become execute-only
CALL SETEXO
Returns:
+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.
Call:
CALL SETGXO/CLRGXO
Returns:
+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
access.
Call:
T1/ JFN
CALL SREADF
Returns:
+1: Always
T2/ Previous state of FRKF in LH,
process for FRKF in RH
To: TOPS-20 Monitor Memo List Page 10
IMPLEMENTATION
3.3.4 CREADF - Clear READ Access And Restricted Access - This routine
un-does what SREADF did.
Call:
T1/ JFN
T2/ Previous state of FRKF in LH,
process for FRKF in RH
CALL CREADF
Returns:
+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
IMPLEMENTATION
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,
.TFRUU
24. UTFRK
25. SETER
26. CRJOB - *
3.5.2 Special Case Restrictions -
3.5.2.1 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
IMPLEMENTATION
3.5.2.2 PMAP -
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.
3.5.2.3 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
IMPLEMENTATION
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
process.
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.
3.5.2.4 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
3.5.3.1 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!
3.5.3.2 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
IMPLEMENTATION
11. RTIW
12. RPCAP
13. WFORK
14. RFSTS
15. RFRKH
16. GFRKS
17. RMAP
18. RPACS
19. GEVEC
20. GCVEC
21. GDVEC
22. RTFRK
3.5.3.3 Privileged JSYSes - The follow JSYSes reference processes but
are privileged. These JSYSes will not be restricted for execute-only
processes:
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
GTJFN of SYS:xxx.EXE.
To: TOPS-20 Monitor Memo List Page 16
IMPLEMENTATION
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
or RESET.
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.
3.7.6 SET ADDRESS-BREAK, ENTRY-VECTOR, PAGE-ACCESS - These commands
should be neat about the error string also.
To: TOPS-20 Monitor Memo List Page 17
RELATED FEATURES
4.0 RELATED FEATURES
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
OTS.
2. The TOPS-10 UUO's GETSEG and RUN would work on execute-only
programs.
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
RELATED FEATURES
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
required.
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,
SIRCM.
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
RELATED FEATURES
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
above.
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.
[End of EXONLY.MEM]
+---------------------------+
! ! ! ! ! ! ! !
! 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
CC:
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
1.0 INTRODUCTION
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
INTRODUCTION
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
INTRODUCTION
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
GET:
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.
[End of RSTEXO.MEM]