Answer the questions in red and hand them in before class.
• x86 protected-mode uses segmentation works as follows:
  • segment register (%cs,%ss,%ds,%es,%fs,%gs) holds segment selector
  • selector: 13 bits of index, 1 bit local vs global flag, 2-bit RPL (request privilege level)
  • selector indexes into global descriptor table (GDT) which is an array of segment descriptors
  • Each 64-bit segment descriptor holds 32-bit base, limit, type, protection
  • The translation h/w obtains linear address (la) from virtual address (va) as follows: la = va + base; assert(va < limit)
  • which segment register is being used is often implicit in the instruction
    • Those that modify %esp (e.g. pop/push) use %ss, those that modify %eip use %cs, others (mostly) use %ds
    • Some instructions take explicit "far" addresses:
      • ljmp $selector, $offset
  • GDT lives in memory, CPU's GDTR register points to base of GDT
  • lgdt instruction loads GDTR
  • program turns on protected mode by setting PE bit in CR0 register
  • The protection mechanisms of segmentation
    • instructions can only r/w/x memory reachable through seg regs (between base, base+limit)
    • Can any program change segment registers (e.g. mov 0 %ss)?
      • Yes. But the privilege level of the currently executing code must match that specified in the segment descriptor
      • Current privilege level (CPL) is in the low 2 bits of %cs (CPL=0 is privileged/kernel, CPL=3 is user)
    • Can any program re-load GDTR? no! it's a priviledged instruction
    • Can user program modify the GDT entries directly? It is in memory..

Download Lab3 and read source file bootasm.S

• Run Bochs with breakpoint "b 0x7c00" (Recall that BIOS loads the bootable disk-sector in memory and jumps to 0x7c00, see Lec 3).

  % bochs -q
  ========================================================================
                         Bochs x86 Emulator 2.2.6
                                             (6.828 distribution release 1)
  ========================================================================
  00000000000i[     ] reading configuration from .bochsrc
  Next at t=0
  0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b         ; ea5be000f0
  <bochs:1> b 0x7c00
  

• Type "c" to let bochs continue execution till it reachs address 0x7c00
• If you want to let bochs continue step by step, delete your previous breakpoint with "d 1" and type "n" to perform step-by-step execution
• Question-1: is 0x7c00 a physical address, a virtual address or a linear address? What mode is the computer in right now?
• Question-2: What entries are populated in the GDT by bootasm.S? (Hint: look at GDT after the lgdt instruction with "info gdt")
• Question-3: what is the immediate effect of setting CR0_PE_ON?
• The "ljmp $SEGSEL_BOOT_CODE, $protcseg" instruction has the effect of loading SEGSEL_BOOT_CODE into %cs (there's no explicit mov instruction to load %cs).
• Question-4: Why is SEGSEL_BOOT_CODE set to 8?
• Question-5: After all segment registers are loaded (either with SEGSEL_BOOT_CODE or SEGSEL_BOOT_DATA) and before paging is enabled, what's the relationship between virtual, linear and physical address? can the program r/w/x arbitary virtual/linear/physical address?

  After kernel is loaded, it initializes itself (see the start function in memos-kern.c)

• The kernel populates a different GDT than that used in bootstrapping (see segments_init).
• Question-6 What's the difference between SEGSEL_APP_CODE and SEGSEL_KERN_CODE?
• User programs will use SEGSEL_APP_CODE/SEGSEL_APP_DATA (see start_process and special_registers_init).
• Since %cs is loaded with SEGSEL_APP_CODE before executing user programs, what's the CPL of a running user program? Without paging enabled, can user programs r/w/x kernel memory? (Question-7)
• Question-8: Can user programs modify GDT? (no paging yet)

Do exercise 1 of Lab 3.

• Consider a page-removal policy that records the number of times a page is accessed in memory and always removes the one with the least number of accesses (the least-frequently-used policy). Does LFU suffer from Belady's anomaly? Explain.

• In the UNIX i-node based file system, how many disk blocks are modified when you do "rm a" in directory D? What are these blocks?
• If the power fails in the midst of the file deletion operation, the file system state should ideally remain consistent after turning the power back on. In other words, the file system should EITHER be in a state where the deletion operation happened OR in a state where the deletion operation never happened. However, if the file system just simply writes those modified disk blocks one by one to disk, what kind of inconsistent state can it be in upon crashing in the middle of the operations? (Give an example of the worst inconsistency you could find).
• To reduce the number of disk writes, many UNIX file systems keep a write-back cache (i.e. keep modified disk blocks in memory and only write them back to disk upon eviction). If a file creation operation follows a file deletion operation (e.g. "rm a; echo hello > b"), what kind of inconsistent state could the file system be in? (Give an example of the worst inconsistency you could find.)

• We use bochs to run our MPOS, SchedOS, MemOS, etc. One can also run Linux and Windows on Bochs. Do you consider Bochs as providing virtualization (according to Popek and Goldberg's rules)?
• Does software-based virtualization need to perform BT on user-level applications? Explain.
• The Adams and Agesen paper claims that "avoiding all use of traces cause either a large number of hidden faults or an expensive context switch to prevalidate shadow page tables for the new context" (Section 2.4). Please describe two MMU virtualization methods using BT that have these mentioned properties.

• Discuss the security implications of the following 4 ways of storing user passwords.
  1. Store the plaintext user passwords in a separate file /etc/shadow-plain which is only readable by root
  2. Store the hashed version of user passwords ( i.e., H(password) ) in the same /etc/passwd file as user names. The /etc/passwd file is readable by all users in the system.
  3. Store the hashed version ( i.e. H(password)) in a separate file /etc/shadow which is only readable by root.
  4. Store the salted and hashed version ( i.e. H(password, salt)) in a separate file /etc/shadow which is only readable by root. The salt value is stored in a file readable only by root also.
  Explain in what ways each of the schemes can be broken and in what ways each successive scheme may be more desirable than the previous one.