Lecture: Meltdown & page-table isolation

administrivia

• demo day: next Thursday, camera crew
• final report: see the sample
  • why writing
  • be accurate, consistent, and self-contained
  • use examples & figures
  • citations & plagiarism

attack

• timeline, some internal discussions, and Intel’s response

• out-of-order execution
  • see figure 1
  • cpu (and compiler too) can rewrite & reorder your code - why?
  • roll back any externally visible effects if speculative execution fails
  • but the cache can have be written and is not discarded
  • how to deal with registers & cache
• address space isolation
  • review virtual memory
  • Linux’s virtual memory map
  • commonly used virtual memory map
    • user takes the lower half & kernel takes the upper half
    • why kernel takes the upper half? why top 2G on x86-64?
    • what does the kernel’s half contain - (remapping of) the entire physical memory
    • why is kernel half mapped?
    • what prevents user from accessing the kernel’s upper half - cpu mode & U bit in PTE
• high-level plan: see listing 2
  • read the secret byte from a kernel address
  • use the secret byte to index into a 256-page probe array
  • time the difference of accessing each page to find out the secret byte
• practical details
  • make probe array sparse
  • suppress exceptions - what approaches are proposed?
  • zero vs. invalid address
  • attack performance
  • ASLR
• can this attack work on:
  • other OS kernels?
  • other CPUs?
  • hypervisors?
• how is this related to spectre

defense

• disable speculative execution - downsides?

• disable speculative execution for kernel addresses - challenges?

• page-table isolation
  • perf downsides
  • x86: no atomic switch of user/kernel and page table
    • except for host/guest switch
    • what has to be mapped
      • syscall entry point
      • GDT
      • IDT & entries in IDT
      • TSS & stack pointer
      • recall: %cr3 stores physical address but other registers do not (gdtr/idtr/etc.)
• another way to look this class of problem: noninterference
  • consider a legitimate user and an adversary
  • security
    • adversary’s actions should be independent of user’s actions
    • otherwise user’s private data is leaked if the adversary can observe different results
  • integrity
    • user’s actions should be independent of adversary’s actions
    • otherwise user’s data integrity is compromised
  • does the cpu guarantee noninterference
  • how about the OS kernel
• discussions
  • are AMD/ARM affected or why not
  • does this work on JS