CSE351, Autumn 2017L23: Virtual Memory Wrap-Up
VirtualMemoryWrap‐Up
CSE351Autumn2017
Instructor:
JustinHsia
TeachingAssistants:
LucasWotton
MichaelZhang
ParkerDeWilde
RyanWong
SamGehman
SamWolfson
SavannaYee
VinnyPalaniappan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Virtual Memory Wrap-Up CSE351, Autumn 2017, Lecture notes of Database Management Systems (DBMS)
A lecture note on virtual memory wrap-up for CSE351 course in Autumn 2017. It covers topics such as memory overview, context switching, page table reality, practice VM questions, row hammer exploit, and consequences of row hammer. lab and homework due dates, a virtual section on virtual memory, and a practice VM question. It is useful as study notes with a rate of 8 out of 10. The typology is lecture notes and the possible academic course is Computer Science. The possible academic year is 2017. more useful for university students and the university is the University of Washington. The extraction succeeded.
Typology: Lecture notes
2016/2017
1 / 21
This page cannot be seen from the preview
Don't miss anything!
Partial preview of the text
Download Virtual Memory Wrap-Up CSE351, Autumn 2017 and more Lecture notes Database Management Systems (DBMS) in PDF only on Docsity!
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Virtual Memory Wrap‐Up CSE 351 Autumn 2017 Instructor: Justin Hsia Teaching Assistants: Lucas WottonMichael ZhangParker DeWildeRyan WongSam GehmanSam WolfsonSavanna YeeVinny Palaniappan
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Administrivia^ ^ Lab 4 due Monday (11/27)^ ^ Homework 5 due next Friday (12/1)^ ^ “Virtual section” on virtual memory released
^ 3 PDFs: VM cheatsheet, worksheet, and solutions ^ Linked in the code section of today’s lecture ^ See Piazza post for links and videos
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Address Translation^ ^ VM is complicated, but also elegant and effective
^ Level of indirection to provide isolated memory & caching ^ TLB as a cache of page tablesavoids two trips to memoryfor every memory access
Virtual Address
TLBLookup
Page Table“Walk”
UpdateTLB
Page Fault (OS loads page)
ProtectionCheck
PhysicalAddress
TLB Miss
TLB Hit
Page notin Mem
AccessDenied
AccessPermitted
ProtectionFault^ SIGSEGV Pagein Mem
Check cache
Find in Disk
Find in Mem
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Memory Overview
Disk
Main memory(DRAM)
Cache
CPU
Page
Page
Line
Block
requested 32‐bits
^ movl 0x8043ab, %rdi
MMU^ TLB
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Page Table Reality^ ^ Just one issue… the numbers don’t work out for thestory so far!^ ^ The problem is the page table for each process:
^ Suppose 64‐bit VAs, 8 KiB pages, 8 GiB physical memory ^ How many page table entries is that? ^ About how long is each PTE? ^ Moral:
Cannot use this naïve implementation of the virtual→physical page mapping – it’s
way
too big
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
A Solution: Multi‐level Page Tables
Page tablebase register(PTBR)
VPN 1
0 p‐
n‐
VPO
VPN 2
...^
VPN k PPN
0 p‐
m‐
PPO
PPN Virtual Address
...^ Physical Address ...
Level 1page table
Level 2page table
Level kpage table
TLB
PTE VPN^
→
PTE VPN^
→
PTE VPN^
→
This is called a
page walk
This is extra(non‐testable)material
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Practice VM Question^ ^ Our system has the following properties
^ 1 MiB of physical address space ^ 4 GiB of virtual address space ^ 32 KiB page size ^ 4‐entry fully associative TLB with LRU replacementa) Fill in the following blanks:
Total entries in pagetable
Minimum bit‐width ofPTBR
TLBT bits
Max # of valid entriesin a page table
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Practice VM Question^ ^ One process uses a page‐aligned
square
matrix
mat[]
of 32‐bit integers in the code shown below:
#define MAT_SIZE = 2048for(int i=0; i<MAT_SIZE; i++)
mat[i*(MAT_SIZE+1)] = i;
b)^
What is the largest stride (in bytes) betweensuccessive memory accesses (in the VA space)?
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
For Fun: DRAMMER Security Attack ^ Why are we talking about this?^
Recent:
Announced in October 2016; Google released
Android patch on November 8, 2016 Relevant:
Uses your system’s memory setup to gain
elevated privileges^ •^ Ties together some of what we’ve learned about virtual memory andprocesses Interesting:
It’s a software attack that uses
only hardware
vulnerabilities
and requires
no user permissions
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Underlying Vulnerability: Row Hammer^ ^ Dynamic RAM (DRAM) has gotten denser over time
^ DRAM cells physically closer anduse smaller charges ^ More susceptible to “
disturbance
errors
” (interference)
^ DRAM capacitors need to be“refreshed” periodically (~64 ms)^
Lose data when loss of power Capacitors accessed in rows
^ Rapid accesses to one row canflip bits in an adjacent row!^
~ 100K to 1M times
By Dsimic (modified), CC BY‐SA 4.0,https://commons.wikimedia.org/w/index.php?curid=
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Consequences of Row Hammer^ ^ Row hammering process can affect another processvia memory
^ Circumvents virtual memory protection scheme ^ Memory needs to be in an adjacent row of DRAM Worse: privilege escalation ^ Page tables live in memory! ^ Hope to change PPN to access other parts of memory, orchange permission bits ^ Goal:
gain read/write access to a page containing a page table, hence granting process read/write access to
all of
physical memory
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
Effectiveness?^ ^ Doesn’t seem so bad – random bit flip in a row ofphysical memory
^ Vulnerability affected by system setup and physicalcondition of memory cells Improvements: ^ Double‐sided row hammering increases speed & chance ^ Do system identification first (e.g. Lab 4)^ •^
Use timing to infer memory row layout & find “bad” rows • Allocate a huge chunk of memory and try many addresses, looking fora reliable/repeatable bit flip
^ Fill up memory with page tables first^ •^
fork
extra processes; hope to elevate privileges in any page table
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
DRAMMER Demo Video^ ^ It’s a shell, so not that sexy‐looking, but still interesting
^ Apologies that the text is so small on the video
CSE351, Autumn 2017
L23: Virtual Memory Wrap-Up
How did we get here?^ ^ Computing industry demands more and faster storagewith lower power consumption^ ^ Ability of user to circumvent the caching system
^ clflush
is an unprivileged instruction in x
^ Other commands exist that skip the cache Availability of virtual to physical address mapping ^ Example:
/proc/self/pagemap
on Linux
(not human‐readable)
^ Google patch for Android (Nov. 8, 2016)^
Patched the ION memory allocator