iAPX 286 Operating System Writers Guide 1983

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