iAPX 286 Operating System Writers Guide 1983

More documents

Recommendations

Info

EXTENDED PROTECTIONanother procedure. To detect parameter errors at the earliest opportunity, the operating system shouldexamine pointer parameters with the VERR, VERW, LAR, and LSL instructions.The strategy for scrutinizing a pointer parameter includes• Using ARPL as described previously to ensure that the RPL field of the pointer parameter containsthe calling procedure's privilege level.• Using VERR or VERW to ensure that the indicated segment is accessible at the calling procedure'sprivilege level. VERR also determines whether the indicated segment is readable; an execute-onlysegment, for example, is not readable. VERW also determines whether the segment is writable;only a writable data segment passes this test.• Using LAR and LSL to make sure that the offset portion of the pointer parameter actually pointsto a location within the boundaries of the segment. LAR makes the access-rights byte of the indicateddescriptor available, so you can determine whether the segment is an expand-down data segment.LSL makes the segment-limit field of the descriptor available. If the segment is an expand-downdata segment, the offset portion of the pointer parameter must be greater than or equal to thesegment limit; otherwise the offset must be strictly less than the limit.Refer to the appropriate language reference manual for details concerning the use of these instructions.This strategy for parameter validation is somewhat more costly than using the ARPL instruction alone,as described in the previous section. Therefore, you may wish to limit use of this strategy to thoseoperating system procedures that can be .called by less privileged, applications procedures.USAGE PRIVILEGE LEVELGenerally, operating system primitives that act on operating system objects (such as the semaphoresand mailboxes discussed in Chapter 5) have call gates at PL 3. Without further protection, proceduresat any privilege level in a task can use those objects for which descriptors exist in the LDT. Suchfreedom violates the principle behind privilege levels, however. Consider these two cases:• A database-management system that runs at PL 2 creates a mailbox for passing recovery informationto a separate task that is responsible for writing recovery information to a magnetic tape. Atask at PL 3 accidently uses the wrong selector in a call to the operating system and sends anunrelated message to that mailbox. Later, when using the audit tape to reconstuct the database, thedatabase system reads the strange record and fails.• Procedures of the same database system use a shared data segment so that they can access commondatabase parameters regardless of what task they run in. To synchronize their access to the commondata, they define and use a semaphore. A less privileged task uses a wrong selector in a call to theoperating system and signals this semaphore prematurely, permitting the shared data to be incorrectlychanged. The database system fails when it next tries to use the incorrect data.These examples illustrate the need for additional protection over the use of operating-system objects,such as semaphores and mailboxes.By associating a usage privilege level (UPL) with objects, the operating system can provide protectionanalogous to that provided by hardware for access to segments. By means of a privilege-level parameterto the creation procedure, the task that creates an object defines the maximum (numerical) privilegelevel that can use the object. The UPL can be stored either in the data structures that define the objector (if indirect naming is used) with the name of the object. In the procedures that operate on the object,the operating system can check whether the calling procedure's privilege level exceeds the UPL of theobject. The calling procedure's privilege level is readily.available on the stack, as figure 13-1 illustrates.13-4 121960-001
EXTENDED PROTECTIONSEND PRIVILEGE LEVELMoving or deleting the descriptor for a segment or the name of an object may have even more drasticeffects on other tasks than using the code or structures in the segment or object. Consider the effect ofdeleting or mailing away a descriptor for a global data segment (for example, a translation table)shared by all tasks in the system. A task that assumes the existence of the global segment will causean exception when it references the deleted descriptor slot. This points out the need for control overthe right to send or delete a descriptor.One way of implementing such control is to associate with each descriptor (including alias descriptors)a send privilege level (SPL). Procedures that move or delete descriptors (such as SEND_MESSAGEand DELETE-ALIAS) interpret the SPL and ensure that the calling procedure cannot delete (send)a descriptor from the GDT or its LDT unless CPL
Page 2 and 3:
LITERATUREIn addition to the produc
Page 4 and 5:
Intel Corporation makes no warranty
Page 6 and 7:
PREFACEExternal LiteratureMany aspe
Page 8:
Table of ContentsCHAPTER 1PageINTRO
Page 11 and 12:
TABLE OF CONTENTSCHAPTER 9PageVIRTU
Page 13 and 14:
TABLE OF CONTENTSLIST OF FIGURESFig
Page 15:
Introduction to Protected 1Multitas
Page 18 and 19:
INTRODUCTION TO PROTECTED MULTITASK
Page 20 and 21:
inter INTRODUCTION TO PROTECTED MUL
Page 22 and 23:
111'eI INTRODUCTION TO PROTECTED MU
Page 24 and 25:
Page 26 and 27:
Page 29:
Using Hardware2Protection Features
Page 32 and 33:
USING HARDWARE PROTECTION,FEATURESs
Page 34 and 35:
interUSING HARDWARE PROTECTION FEAT
Page 36 and 37:
USING HARDWARE PROTECTION FEATURES(
Page 38 and 39:
USING HARDWARE PROTECTION FEATURES
Page 40 and 41:
USING HARDWARE PROTECTION FEATUREST
Page 42 and 43:
USING HARDWARE PROTECTION FEATURESo
Page 44 and 45:
USING HARDWARE PROTECTION FEATURESL
Page 46 and 47:
USING HARDWARE PROTECTION FEATUREST
Page 48 and 49:
USING HARDWARE PROTECTION FEATURESE
Page 50 and 51:
inl:el~USING HARDWARE PROTECTION FE
Page 52 and 53:
IntelUSING HARDWARE PROTECTION FEAT
Page 54 and 55:
IntelU~ING HARDWARE PROTECTION FEAT
Page 56 and 57:
lSLDTFORMATRt;;SERV~~"O~iA~~.~ijij
Page 59 and 60:
CHAPTER 3REAL MEMORY MANAGEMENTIn d
Page 61 and 62:
REAL MEMORY MANAGEMENTIALLOCATEGATE
Page 63 and 64:
interREAL MEMORY MANAGEMENTBEFOREAF
Page 65 and 66:
REAL MEMORY MANAGEMENTGLOBAL DESCRI
Page 67 and 68:
REAL MEMORY MANAGEMENTTable 3-1. Ac
Page 69 and 70:
REAL MEMORY MANAGEMENTBEFOREI "FREE
Page 71 and 72:
REAL MEMORY MANAGEMENTBEFOREI "FREE
Page 73 and 74:
REAL MEMORY MANAGEMENTPL/M-286 COMP
Page 75 and 76:
Page 77 and 78:
Page 79:
Page 82 and 83:
IIIIIIIIIIIIIIIIIIIIII
Page 84 and 85:
II I telTASK MANAGEMENTCPUTASK REGI
Page 86 and 87:
TASK MANAGEMENTIf the proc~sser, wh
Page 88 and 89:
TASK MANAGEMENTUsually, termination
Page 90 and 91:
TASK MANAGEMENTTASK XTSS TSS TSS TS
Page 92 and 93:
TASK MANAGEMENTSCHEDULING POLICIEST
Page 94 and 95:
TASK MANAGEMENTThe example in figur
Page 96 and 97:
TASK MANAGEMENTREADY QUEUESBY PRIOR
Page 98 and 99:
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
Page 101 and 102:
CHAPTER 5DATA SHARING, ALIASING, AN
Page 103 and 104:
DATA SHARING, ALIASING, AND SYNCHRO
Page 105 and 106:
interDATA SHARING, ALIASING, AND SV
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117:
Page 121 and 122:
CHAPTER 6SIGNALS AND INTERRUPTSInte
Page 123 and 124:
interSIGNALS AND INTERRUPTSlOTGOTTS
Page 125 and 126:
SIGNALS AND INTERRUPTSTable 6-1. In
Page 127 and 128:
SIGNALS AND INTERRUPTSSend interrup
Page 129 and 130:
SIGNALS AND INTERRUPTSprocedure suc
Page 131:
Handling Exception Conditions 7
Page 134 and 135:
HANDLING EXCEPTION CONDITIONSError
Page 136 and 137:
HANDLING EXCEPTION CONDITIONSAn exc
Page 138 and 139:
HANDLING EXCEPTION CONDITIONSA few
Page 140 and 141:
HANDLING EXCEPTION CONDITIONSAn ins
Page 143 and 144:
CHAPTER 8INPUT /OUTPUTMany of the c
Page 145 and 146:
INPUT /OUTPUTYou can still take adv
Page 147 and 148:
INPUT /OUTPUT• Only the operating
Page 149:
INPUT /OUTPUTtask the I/0 procedure
Page 153 and 154:
CHAPTER 9VIRTUAL MEMORYThe memory l
Page 155 and 156:
VIRTUAL MEMORYthose segments that a
Page 157 and 158:
VIRTUAL MEMORY• Return the RAM sp
Page 159 and 160:
VIRTUAL MEMORYReplacementThe operat
Page 161 and 162:
System Initialization10
Page 163 and 164:
CHAPTER 10SYSTEM INITIALIZATIONThe
Page 165 and 166:
SYSTEM INITIALIZATIONStarting the f
Page 167 and 168:
iAPX286 "ACRO ASSEMBLERLOCOBJEnter
Page 169 and 170:
iAPX286 MACRO ASSEMBLEtEnter Protec
Page 171 and 172: iAPX286 MACRO ASSEMBLER·· Enter ~
Page 173 and 174: iAPX286 'UCRO USE148LER Ente,. P,.o
Page 175 and 176: iAPX286 MACRO ASSEMBLEREnt9~ P~otec
Page 177: iAPX286 MACRO ASSEMBLE~ INITIAL TAS
Page 181 and 182: CHAPTER 11BINDING AND LOADINGBindin
Page 183 and 184: BINDING AND LOADINGNamingThe names
Page 185 and 186: BINDING AND LOADING$ COMPACT (NUCLE
Page 187 and 188: interBINDING AND LOADINGsystem-IDiA
Page 189 and 190: BIND.ING AND LOADINGConverting a Pr
Page 191 and 192: BINDING AND LOADINGThe OMF of each
Page 193 and 194: interBINDING AND LOADINGsystem-IDiA
Page 195 and 196: BINDING AND LOADINGPL/M-2B6 COMPILE
Page 197 and 198: BINDING AND LOADI.NGPL/M-286 COMPIL
Page 199 and 200: BINDING AND LOADINGPL/M-286 COMPILE
Page 201 and 202: BINDING AND LOADINGPL/M-2B6 COMPILE
Page 203 and 204: BINDING AND LOAD.INGPL/M-286 COMPIL
Page 205 and 206: interBINDING AND LOADINGPL/M-286 CO
Page 207 and 208: BINDING AND LOADINGPL/M-286 COMPILE
Page 209: Numerics Processor Extension 12
Page 212 and 213: NUMERICS PROCESSOR EXTENSIONMath Pr
Page 214 and 215: interNUMERICS PROCESSOR EXTENSION
Page 217: Extended Protection13
Page 220 and 221: EXTENDED PROTECTIONIndirect NamingT
Page 225: Glossary
Page 228 and 229: GLOSSARYbootloadable module: a modu
Page 230 and 231: GLOSSARYexception: a processor-dete
Page 232 and 233: GLOSSARYintersegment reference: a r
Page 234 and 235: GLOSSARYoutward call: the attempt t
Page 236 and 237: GLOSSARYscheduling state: one of se
Page 238 and 239: GLOSSARYvirtual address: an address
Page 240 and 241: INDEXES register, 2-17, 2-18, 2-21,
Page 242 and 243: INDEXpresent bit, 2-2, 2-3, 2-9, 5-
Page 245 and 246: interu.s. SALES OFFICESALAIWIA IlEQ
Page 247 and 248: interu.s. DISTRIBUTORSNEW YORK (C"n
Page 249 and 250: intJINTEL INTERNATIONAL SALES OFFIC
show all

iAPX 286 Operating System Writers Guide 1983

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?