80386 Protection Mode, Exams of Operating Systems

Lecture Notes (Syracuse University). 80386 Protection Mode: 8. When segment registers are modified, the processor automatically fetches the base address, ...

Typology: Exams

2021/2022

Uploaded on 09/07/2022

adnan_95
adnan_95 🇮🇶

4.3

(39)

918 documents

1 / 16

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Lecture Notes (Syracuse University) 80386 Protection Mode: 1
80386 Protection Mode
1 Introduction and Initial Discussion
For Teacher: Let us start with an analogy here: The projector in the classroom should be protected, and
only authorized users can turn on the projector in my class. I will perform the access control (because I
have the remote control). Whoever needs to turn on the projector during my class time needs to send me a
request, and I will check whether you are on the authorized user list. If yes, I will use the remote, push the
ON button, and send a signal to the projector; if not, the request will be denited.
Can I actually prevent unauthorized users from turnning on the projector?
What prevents them from bypassing me and directly send the signal to the projector (e.g. recording
the signal I sent to the projector)?
For Teacher: We can then proceed to ask students what prevents normal users from modifying the
/etc/passwd file.
Students may say “access control” in the operating system.
Why should we go through the access “controller”?
Why can’t we directly jump to the functions in the device driver, and access the disk through the
device driver?
Why can’t we write our own code (i.e. device driver) to directly access the raw disk?
Question 1 (Execution Emulation): Assume that to write to /etc/passwd file, the CPU instructions
(Machine codes) that get executed are c1,c2,. . .,cn. And also assume that the instructions related to access
control is a1,. . .,as. Now let’s construct a new program p0=c1,. . .,cn-a1, ..., as, and let run it directly
on CPU, can we succeed in writing to /etc/passwd file?
Answer: In 8086, you can do this. In 80386, you cannot!
Question 2 (Code Access): Assume that we know the address of the code for system calls write(),
which can write data to disks. There are two ways to call it:
1. Go through the system-call approach, which is subject to access control.
2. Directly jump to that code.
We know the first approach works, but can the second choice succeed? If not, what prevents a program from
jumping to that code?
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download 80386 Protection Mode and more Exams Operating Systems in PDF only on Docsity!

80386 Protection Mode

1 Introduction and Initial Discussion

For Teacher: Let us start with an analogy here: The projector in the classroom should be protected, and only authorized users can turn on the projector in my class. I will perform the access control (because I have the remote control). Whoever needs to turn on the projector during my class time needs to send me a request, and I will check whether you are on the authorized user list. If yes, I will use the remote, push the ON button, and send a signal to the projector; if not, the request will be denited.

  • Can I actually prevent unauthorized users from turnning on the projector?
  • What prevents them from bypassing me and directly send the signal to the projector (e.g. recording the signal I sent to the projector)?

For Teacher: We can then proceed to ask students what prevents normal users from modifying the /etc/passwd file.

  • Students may say “access control” in the operating system.
  • Why should we go through the access “controller”?
  • Why can’t we directly jump to the functions in the device driver, and access the disk through the device driver?
  • Why can’t we write our own code (i.e. device driver) to directly access the raw disk?

Question 1 (Execution Emulation): Assume that to write to /etc/passwd file, the CPU instructions (Machine codes) that get executed are c 1 , c 2 ,.. ., cn. And also assume that the instructions related to access control is a 1 ,.. ., as. Now let’s construct a new program p′^ = c 1 ,.. ., cn - a 1 , ..., as, and let run it directly on CPU, can we succeed in writing to /etc/passwd file?

Answer: In 8086, you can do this. In 80386, you cannot!

Question 2 (Code Access): Assume that we know the address of the code for system calls write(), which can write data to disks. There are two ways to call it:

  1. Go through the system-call approach, which is subject to access control.
  2. Directly jump to that code.

We know the first approach works, but can the second choice succeed? If not, what prevents a program from jumping to that code?

Answer: the hardware access control disallows it. There is a security policy to prevent the above direct jumping from happening, and the policy is enforced by hardware. We are interested in how such access control policy is defined and how hardware enforces the policy.

Question 3 (Data Access): We know that when we use open() to open a file, a file descriptor will be returned. This file descriptor is the index to the “capability” that is stored in the kernel. Assume that we know the address of this capability. What prevents us from directly modify the capability, and thus giving us additional permissions?

Answer: the access is disallowed. There is a security policy to prevent the above direct access of the kernal memory from user space, and the policy is enforced by hardware at each memory access. How does such an access control work?

Discussion: From the above questions and their answers, it seems certain kind of access control is protecting the systems. If you get chance to design such a protection scheme, how would you design an access control like this?

  • Four components of a security policy: subject, object, action, and rule.
  • Action: instructions.
  • Objects: things that need to be protected.
    • Memory: at what granularity, byte, word, or block? What are the disadvantages and advantages of your choices?
    • Registers
    • I/O Devices
  • What can be used as subject?
    • Can we use user ID or process ID as subjects? No we cannot use things that are defined in an operating system, because this access control is not part of an OS, it is underneath an OS. Processes and users are meaningful in an OS, but the underlying hardware does not know what those are.
    • In other words, how to give each instruction an identity?
  • How to design the rules (or policies)?
    • How to represent the policies?
    • Where to store the policies?
    • When to enforce the policies?
    • Access matrix: high cost, inflexible, etc.
  • Mandatory versus Discretionary Access Control
    • If MAC is used, system-wise mandatory access control polices are enforced.
    • If DAC is used, the owner of an object can set up security polices.

Level 3

Operating System Kernel

Applications

Operating System Services

Protection Rings

Level 0

Level 1 Level 2

Figure: Rings

  • Memory protection across ring boundaries: once we divide the memory into several rings, we can define security policies based on rings. For example, we can prevent code in ring 3 from accessing data in ring 0, etc. The question is that, when conducting access control, how CPU learns the ring labels of a subject and an object. - When CPU enforces the access control policies, it must know the ring label of both the subject and object in an efficient way. - CPL: Current Privilege Level, the label on subjects. ∗ CPL is stored in a register (Bits 0 and 1 of the CS and SS segment registers). ∗ CPL represents the privilege level of the currently executing program or procedure. ∗ Normally, the CPL is equal to the privilege level of the code segment from which instruc- tions are being fetched (there is one exception, and we will talk about later when we talk about conforming code segments). ∗ The processor changes the CPL when program control is transferred to a code segment with a different privilege level. - DPL: Descriptor Privilege Level, the label on objects. ∗ DPL is the privilege level of an object. When the currently executing code segment attempts to access an object, the DPL is compared with CPL. ∗ Where should DPL be stored? · Discussion: stored in each byte? Stored for each block (at the beginning of a block)? or somewhere else?
  • Memory protection within the same ring: Rings can achieve memory protection across ring bound- aries, but they cannot memory protection within the same ring. For example, when we develop an operating system for 80386, we would like user processes to run at ring 3, but we do not want one process to access another process’s memory (all within ring 3). Rings cannot achieve this kind of protection (memory isolation). We need another access control mechanism for this protection. - Let us divide memory into segments. Each process can take one or more segments. Whenever a process tries to access a memory, access control should be enforced to achieve memory isolation. - Discussion: What access control model do we use? ACL or Capability?
  • ACL Approach: we associate each segment with an access control list. Each memory access will go through this list. This is too time consuming, because the list might be long. The processor cannot afford to go through a long list for each memory access.
  • Capability Approach: each process is assigned a list of capability, each corresponding to one of its segments. There are two important issues in capability-based access control. First, where should the capabilities be stored? They cannot be forged by users. Privileged rings are good places for storing capabilities. Second, there are two common ways to implement capability- based access control: ∗ Capability List: the code does not need to explicitly show its capabilities when access a memory; instead, the processor searches the capability list of the process to find the one that is appropriate, if any. This approach has the same problem as the ACL approach: list might be too long. ∗ Index of Capabilities: when a code tries to access a memory, it should present a “ticket”, which is the index of the actual capability stored in a privileged ring. This way, the proces- sor only needs to check this specific capability. The performance is much better than the capbility list approach. This is similar to how the file descriptor is implemented.
  • 80386 chooses the capability as its access control model to achieve memory isolation; it uses the index approach.
  • Logical and Linear Address

Linear Address

Descriptor

Segment

15 0 Seg. Selector

Descriptor Table

Logical Address

Capability−Based Access Control (Selecting Segment)

Mandatory Access Control: (Privilege Check)

31 0 Offset

(^310)

Figure: Logincal Address to Linear Address Translation

  • Logical address: consist of segment selector and offset. The processor converts the logical address to linear address using the segment descriptor indicated by the segment selector.
  • Linear address: when the paging is disabled, the linear address is actually the physical address; when the paging is enabled, the linear address is converted to physical address through paging mechanisms.
  • Segment selectors are provided by segment registers: For example, in the following instruction, the segment selector is provided by the register DS, and the offset is 80 : MOV %DS:[80], %EAX.
  • Two access control mechanisms are used here:

8 Seg. Limit 19:

31 24 20 16 0

31 16 0 Segment Limit 15:

Access Rights

Base 31:24 P^ S^ Type^ Base 23:

Base Address 15:

DPL

Segment Descriptor

  • Base (32 bits): the base address of the segment.
  • Segment Limit (20 bits): the size of the segment. The processor will ensure that the offset of the address does not go beyond the segment limit.
  • Type (4 bits): specify the type of segment. The processor will enforce type rules. For example, no instruction may write into a data segment if it is not writable, no instruction may read an executable segment unless the readable flag is set, etc. ∗ Data Type: Read-Only, Read/Write, etc. ∗ Code Type: Execute-Only, Execute/Read
  • DPL (2 bits): Descriptor Privilege Level. It specifies the ring level of the segment. DPL is used in access control.
  • Segment Registers
  • Due to the address translation step, accessing data or code in memory involves two memory ac- cess, one for retrieving segment descriptor from the descriptor table, and the other for accessing the actual memory. To avoid consulting a descriptor table for each memory acess, 80386 caches information from descriptors in segment registers.
  • A segment register has a “visible” part and a “hidden” part. ∗ “Visible” part: segment selector. ∗ “Hidden” part: descriptor cache; it caches the descriptor indicated by the segment selector, including base address, limit, and access information. This cached information allows the processor to translate addresses without taking extra bus cycles.
  • Segment registers in 80386: CS (code segment), DS (data), SS (stack), ES, FS, and GS. By de- fault, for a code address, the processor uses the segment selector contained in CS, and therefore fetch the code from the code segment. For an data address, the processor by default uses the seg- ment selector contained in DS, and for a stack address, the processor uses the segment selector contained in SS. If one wants to use other segment registers, they can use them as a prefix: e.g. MOV EAX, FS:[0].
  • For a program to access a segment, the segment selector for the segment must have been loaded in one of the segment registers. The operations that load these registers are normal program instructions; they are of two classes: ∗ Direct load instructions: e.g. MOV, POP, LDS, LSS, LGS, LFS. ∗ Implied load instructions: e.g. far CALL and JMP. These instructions implicitly reference the CS register, and load it with a new value.

When segment registers are modified, the processor automatically fetches the base address, limit, type, and other information from a descriptor table and loads them into the “hidden” part of the segment register.

  • Loading a segment register under 80386 Protected Mode results in special checks and actions, to make sure the access control policies are satisfied. We will talk about the policies later.

3 The Mandatory Access Control on Data and Code Access

  • Privilege Check for Data Access (see Figure)
    • We temporarily ignore RPL.
    • Policy: CPL ≤ DPL of code segment.
    • A subject can only access data objects with the same or lower privilege levels.

Code−Segment Descriptor

CS Register

Segment Selector For Data Segment

CPL

RPL PrivilegeCheck

Data−Segment Descriptor

CS Register

Segment Selector

CPL

RPL PrivilegeCheck

DPL DPL C

(a) Privilege Check for Data Access (b) Privilege Check for Control Transfer Without Using a Gate

For Code Segment

Figure: Access Control

  • RPL: Request Privilege Level.
    • Potential Risk: At ring 0, code can access data at any ring level. This poses a risk when the code (say A) is invoked by some other code (say B) in a less privileged ring, and B passes a pointer to A. Normally, the pointer refers to a memory space that belongs to B (and of course A can also access). However, if B is malicious, B can pass a pointer of a memory that does not belong to B (B does not have privileges to access the memory). Because A is a privileged code, access control cannot prevent A from accessing the memory. This way, B can use A to corrupt the targeted memory in a privileged space.
    • Principle of Least Privilege: in the above case, it is really unnecessary to run A with the ring- privilege when accessing the pointed memory passed by B. According to the principle of least privilege, A should drop its privilege to B’s ring level when accessing the memory.
    • How does RPL works: ∗ Assume that A is in ring 0 and B is in ring 3, and the memory address’s selector is S. ∗ The last two bit of a selector is used for RPL. It means that when accessing this memory, the code’s privilege is droped to the RPL level. Therefore, if S’s RPL=3, when A tries to access the memory in ring 0 (i.e. DPL=0), the access will be denied. If S’s RPL is not dropped to 3 (instead it is set to 0 ), the access will succeed because A’s CPL is 0.

4 Call Gates

  • Supporting system calls: In an operating systems, all the privileged operations are carried out in the privileged rings, such as modifing kernal data structure, interacting with devices, etc. OS does not allow user programs to invoke them in an arbitrary way, such as jumping to the middle of a privileged operations. Instead, OS provides a number of interfaces to users programs, which can only invoke those provileged operations via the interfaces. These interfaces are often called system calls. Invoking system calls is quite different from invoking a normal function. In the latter case, the call is within the same ring; however in the former case, the call is from a less privileged ring to a prvileged ring. 80386’s ring protection does not allow a direct jump like this. Some special mechanism must be provided to allow the control transfer from a less privileged ring to a privileged ring.
  • How to invoke system calls?
    • Call Gate: Call gates allow a program to directly call system calls. However, since system calls are often in a privileged ring, calling them directly is not allowed because of the ring protection. The 80386 protection mode uses a call-gate concept to allow this kind of transfer. Call gates enable programs in a lower privileged ring to jump to designated places in a higher privileged ring.
    • Software Interrupt or Trap: In many operating systems, such as Linux and Minix, programs use int 0x80 to trap to the kernel. Namely, when a program wants to call a system call, it saves the system call number in the EAX register, and then execute int 0x80 to raise a software interrupt. Interrupts transfer control to the kernel, so the kernel can execute the intended system call based on the number stored in EAX. This approach is quite popular in OS designs.
    • SYSENTER/SYSEXIT: The Intel Pentium II processor introduces another new facility for faster system call invocation. The facility uses the instruction SYSENTER to enter the sys- tem call entry point at ring 0; it uses SYSEXIT to return back. Starting with version 2.5, Linux kernel introduced started taking advantage of this new system call facility.
  • The Call Gate concept.

Descriptor Table

Offset

Base

Base (^) Base

Offset Seg Selector Offset

Call−Gate

Descriptor

Descriptor

Code−Segment

Seg. Selector

Procedure Entry Point

Far Pointer to Call Gate

(Required but not used by processor)

Figure: Call Gate

  • The idea of Call Gate: 80386 does allow a program to jump to a more privilege ring, but a program cannot jump to an arbitrary place, it must go through Call Gates, which basically define the entry points for the privileged code. Corresponding security checks will be conducted at those entry points to decide whether the invoking code has sufficient right. These security checks are enforced by operating systems.
  • Like segment descriptors, call-gate entries (call-gate descriptors) are also stored in the GDT (or LDT) tables. Gates define an entry point of a procedure.
  • Call-Gate Descriptor contains the following information:

P

31 24 20 16 0

31 16 0

DPL

8

Offset in Segment 15:

0

Segment Selector

Offset in Segment 31: 1 1 0 0

Type 0 0 0

Parameter Count

4

Figure: Gate Descriptor ∗ Code segment to be accessed (segment selector) ∗ Entry point for a procedure in the specified code segment (offset in segment) ∗ Privilege level required for a caller trying to access the procedure (DPL) ∗ Parameter Count: if a stack switch occurs, it specifies the number of optional parameters to be copied between stacks. ∗ etc.

  • How to use call gates? ∗ Call xxxxxx or JMP xxxxxx ∗ xxxxxx specifies the call gate entry in the GDT (or LDT) table ∗ From the table, the entry point of the procedure will be obtained. ∗ DPL of the gate descriptor allows the CPU to decide wither the invocator can enter the gate.
  • Access Control Policy for Call Gates
  • CPL ≤ DPL of the call gate.
  • For CALL: DPL of the code segment ≤ CPL (only calls to the more privileged code segment are allowed).
  • For JMP: DPL of the code segment = CPL.
  • Q: why can’t we CALL a less privileged code segment using Gates? Still returning will be a problem, because returning will be from the less privileged code to the more privileged code, and it violates the mandatory access control.
  • Returning from a Called Procedure
  • The RET instruction can be used to perform a near return, a far return at the same privilege level, and a far return to a different privilege level

6 Page-Level Protection

  • Paging mechanism (the following figure is for 4-KByte pages)

3-

PROTECTED-MODE MEMORY MANAGEMENT

To select the various table entries, the linear address is divided into three sections:

  • Page-directory entry—Bits 22 through 31 provide an offset to an entry in the page directory. The selected entry provides the base physical address of a page table.
  • Page-table entry—Bits 12 through 21 of the linear address provide an offset to an entry in the selected page table. This entry provides the base physical address of a page in physical memory.
  • Page offset—Bits 0 through 11 provides an offset to a physical address in the page. Memory management software has the option of using one page directory for all programs and tasks, one page directory for each task, or some combination of the two.

3.6.2.2. LINEAR ADDRESS TRANSLATION (4-MBYTE PAGES)

Figure 3-12 shows how a page directory can be used to map linear addresses to 4-MByte pages. The entries in the page directory point to 4-MByte pages in physical memory. This paging method can be used to map up to 1024 pages into a 4-GByte linear address space.

Figure 3-12. Linear Address Translation (4-KByte Pages)

0 Directory Table^ Offset

Page Directory

Directory Entry

CR3 (PDBR)

Page Table

Page-Table Entry

4-KByte Page

Physical Address

31 2221 1211

Linear Address

32* 1024 PDE^ ∗^ 1024 PTE = 2^20 Pages

10

12

10

*32 bits aligned onto a 4-KByte boundary. Figure: Paging Mechanism

  • How does segmentation and paging work together?
    • Page-level protection can be used alone.
    • Page-level protection can be used together with the segmentation protection. In this case, the linear address produced by the sementation mechanism will be fed into the paging mechanism, and is eventually translated into physical address.
    • When paging is enabled, the 80386 first evaluates segment protection, then evaluates page pro- tection. If the processor detects a protection violation at either the segment or the page level, the requested operation cannot proceed; a protection exception occurs instead.

Lecture Notes (Syracuse University) 80386 Protection Mode: 14

3-

PROTECTED-MODE MEMORY MANAGEMENT

address space.

If paging is not used, the linear address space of the processor is mapped directly into the phys- ical address space of processor. The physical address space is defined as the range of addresses that the processor can generate on its address bus. Because multitasking computing systems commonly define a linear address space much larger than it is economically feasible to contain all at once in physical memory, some method of “virtualizing” the linear address space is needed. This virtualization of the linear address space is handled through the processor’s paging mechanism. Paging supports a “virtual memory” environment where a large linear address space is simulated with a small amount of physical memory (RAM and ROM) and some disk storage. When using paging, each segment is divided into pages (ordinarily 4 KBytes each in size), which are stored either in physical memory or on the disk. The operating system or executive maintains a page directory and a set of page tables to keep track of the pages. When a program (or task) attempts to access an address location in the linear address space, the processor uses the page directory

Figure 3-1. Segmentation and Paging

Global Descriptor Table (GDT)

Linear Address Space

Segment Segment Descriptor

Offset

Logical Address

Segment Base Address Page

Phy. Addr. Lin. Addr.

Segment Selector

Dir Table Offset

Linear Address

Page Table

Page Directory

Entry

Physical Space

Entry

(or Far Pointer)

Segmentation Paging

Address

Page

Figure: Segmentation and Paging

  • Page-level protection: restrict access to pages based on two privilege levels:
    • Supervisor mode (U/S flag is 0)(Most privileged) For the operating system or executive, other system software (such as device drivers), and protected system data (such as page tables).
    • User mode (U/S flag is 1)(Least privileged) For application code and data.
    • When the processor is in supervisor mode, it can access all pages; when in user mode, it can access only user-level pages.
  • The segment privilege levels map to the page privilege levels as follows:
    • If the processor is currently operating at a CPL of 0, 1, or 2, it is in supervisor mode;
    • If it is operating at a CPL of 3, it is in user mode.
  • Page Type (read/write protection)
    • The page-level protection mechanism recognizes two page types: ∗ Read-only access (R/W flag is 0). ∗ Read/write access (R/W flag is 1).
  1. If a program is copying data to a buffer located towards the end of a segment, is it possible to overflow the segment as the result of buffer overflow?
  2. How is the memory space of one process isolated from another process?
  3. Why can two different processes use the same address (e.g. 0xF8A60000) without worrying about overwriting each other’s data?
  4. Does the 80386 Protection mode use capability in its access control? Where is the capability used?
  5. How can operating systems restrict all I/O operations to be executed in the kernel only.
  6. Please describe the design process that we went through in the class when discussing the 80386 protection mode. What are the key design questions that we asked, and how did we resolve them?