Memory Protection - University of Calgary in AlbertaMemory Fence Virtual Memory Reflections Memory...
Transcript of Memory Protection - University of Calgary in AlbertaMemory Fence Virtual Memory Reflections Memory...
Memory FenceVirtual Memory
Reflections
Memory Protection
Philip W. L. Fong
Department of Computer ScienceUniversity of Calgary
Calgary, Alberta, Canada
CPSC 525/625 (Winter 2018)
1 / 25
Memory FenceVirtual Memory
Reflections
Multiprogramming
Remember my Apple computer: single userMultiprogrammed OS
multiple users sharing resourcesprocesses and threads
“Processes have different resources, implying controlledaccess”“Threads share resources with less access control”
2 / 25
Memory FenceVirtual Memory
Reflections
Enter the Notion of Processes
Before:
After:
3 / 25
Memory FenceVirtual Memory
Reflections
Memory Protection
Preventing memory interference
Traditionally implemented by hardware
4 / 25
Memory FenceVirtual Memory
Reflections
Memory Protection
Preventing memory interferenceTraditionally implemented by hardware
4 / 25
Memory FenceVirtual Memory
Reflections
Outline
1 Memory Fence
2 Virtual Memory
3 Reflections
5 / 25
Memory FenceVirtual Memory
Reflections
Outline
1 Memory Fence
2 Virtual Memory
3 Reflections
6 / 25
Memory FenceVirtual Memory
Reflections
Fixed Fence
Problem: User code may read/write memory belonging tothe OS.
Solution:OS code resides in address 0 to nUser code resides in address n + 1 onwardMemory fault if user code attempts to access addresswithin range 0–n.
7 / 25
Memory FenceVirtual Memory
Reflections
Fixed Fence
Problem: User code may read/write memory belonging tothe OS.Solution:
OS code resides in address 0 to nUser code resides in address n + 1 onwardMemory fault if user code attempts to access addresswithin range 0–n.
7 / 25
Memory FenceVirtual Memory
Reflections
Fence Register
Problem: Fixed address layout, inflexible — OS size maychange over time.
Solution:Store end of OS code in a fence registerReject instruction during user mode if addressing OS codein fence
8 / 25
Memory FenceVirtual Memory
Reflections
Fence Register
Problem: Fixed address layout, inflexible — OS size maychange over time.Solution:
Store end of OS code in a fence registerReject instruction during user mode if addressing OS codein fence
8 / 25
Memory FenceVirtual Memory
Reflections
Base/Bounds Register
Problem: Only protects kernel from users. What aboutprocess against process?
Solution:Base register: all addresses in a program is offsetted by thebase register
address + base
Bounds register: all offsetted address is then compared tothe bounds register, which delimits the upper bound of alegitimate address for the program
address + base < bounds
OS changes the contents of base and bounds registerswhen context-switching to a different process.
9 / 25
Memory FenceVirtual Memory
Reflections
Base/Bounds Register
Problem: Only protects kernel from users. What aboutprocess against process?Solution:
Base register: all addresses in a program is offsetted by thebase register
address + base
Bounds register: all offsetted address is then compared tothe bounds register, which delimits the upper bound of alegitimate address for the program
address + base < bounds
OS changes the contents of base and bounds registerswhen context-switching to a different process.
9 / 25
Memory FenceVirtual Memory
Reflections
Base/Bounds Register
Problem: Only protects kernel from users. What aboutprocess against process?Solution:
Base register: all addresses in a program is offsetted by thebase register
address + base
Bounds register: all offsetted address is then compared tothe bounds register, which delimits the upper bound of alegitimate address for the program
address + base < bounds
OS changes the contents of base and bounds registerswhen context-switching to a different process.
9 / 25
Memory FenceVirtual Memory
Reflections
Base/Bounds Register
Problem: Only protects kernel from users. What aboutprocess against process?Solution:
Base register: all addresses in a program is offsetted by thebase register
address + base
Bounds register: all offsetted address is then compared tothe bounds register, which delimits the upper bound of alegitimate address for the program
address + base < bounds
OS changes the contents of base and bounds registerswhen context-switching to a different process.
9 / 25
Memory FenceVirtual Memory
Reflections
Code vs Data
Problem: Within a process, still possible to overwrite code.
Solution: Separating the data space and code space:Data baseData boundsProgram baseProgram bounds
Each of data and program space can be loaded separatelyinto different parts of the physical memory space.
10 / 25
Memory FenceVirtual Memory
Reflections
Code vs Data
Problem: Within a process, still possible to overwrite code.Solution: Separating the data space and code space:
Data baseData boundsProgram baseProgram bounds
Each of data and program space can be loaded separatelyinto different parts of the physical memory space.
10 / 25
Memory FenceVirtual Memory
Reflections
Code vs Data
Problem: Within a process, still possible to overwrite code.Solution: Separating the data space and code space:
Data baseData boundsProgram baseProgram bounds
Each of data and program space can be loaded separatelyinto different parts of the physical memory space.
10 / 25
Memory FenceVirtual Memory
Reflections
Tagged Architecture
Problem: Protects only contiguous memory blocks.All-or-nothing protection. What if:
mutual suspicion among code units within the sameprocesschange of accessibility over time (e.g., writable only duringprogram initialization)
Solution: Tagged ArchitectureProtecting each memory word separatelyEach memory word is associated with a tag (a few bits)specifying accessibility (e.g., read-only, read/write,execute-only)
11 / 25
Memory FenceVirtual Memory
Reflections
Tagged Architecture
Problem: Protects only contiguous memory blocks.All-or-nothing protection. What if:
mutual suspicion among code units within the sameprocesschange of accessibility over time (e.g., writable only duringprogram initialization)
Solution: Tagged ArchitectureProtecting each memory word separatelyEach memory word is associated with a tag (a few bits)specifying accessibility (e.g., read-only, read/write,execute-only)
11 / 25
Memory FenceVirtual Memory
Reflections
Example: Burroughs B6500-7500
3 tag bits to differentiatedata wordspointerscontrol words (i.e., stack pointers, etc)
12 / 25
Memory FenceVirtual Memory
Reflections
Example: BiiN
one tag for a block of size 128 or 256 bytesless costly
13 / 25
Memory FenceVirtual Memory
Reflections
Not Popular
While the tagged architecture is very attractive by design,stock OSes (e.g., Windows, MacOS) are designed forconventional architecture (e.g., Intel).
14 / 25
Memory FenceVirtual Memory
Reflections
Outline
1 Memory Fence
2 Virtual Memory
3 Reflections
15 / 25
Memory FenceVirtual Memory
Reflections
Segmentation
Divide a program into many small pieces (segment)a segment may correspond to a procedure or an array
Address: 〈segment ,offset〉OS maintains a table (per process) mapping segment id tophysical addressNeed mechanisms to check for access beyond end of asegment
16 / 25
Memory FenceVirtual Memory
Reflections
General Advantages of Segmentation
1 Segments can be dynamically relocated at run time2 Segments can be swapped out of physical memory into
secondary storage3 Every memory reference is mediated by the operating
system, providing opportunities for protection
17 / 25
Memory FenceVirtual Memory
Reflections
Security Advantages of Segmentation
Different levels of accessibility for different segmentsDifferent users can share a segment, with different accessrightsPhysical addresses cannot be forged
18 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pages
Divide physical memory space into equal-sized pageframesAddress: 〈page,offset〉OS maintains a table (per process) mapping pagenumbers to frame numbersSince all frames have same size, checking upper bound ofoffset is straightforward.Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pagesDivide physical memory space into equal-sized pageframes
Address: 〈page,offset〉OS maintains a table (per process) mapping pagenumbers to frame numbersSince all frames have same size, checking upper bound ofoffset is straightforward.Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pagesDivide physical memory space into equal-sized pageframesAddress: 〈page,offset〉
OS maintains a table (per process) mapping pagenumbers to frame numbersSince all frames have same size, checking upper bound ofoffset is straightforward.Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pagesDivide physical memory space into equal-sized pageframesAddress: 〈page,offset〉OS maintains a table (per process) mapping pagenumbers to frame numbers
Since all frames have same size, checking upper bound ofoffset is straightforward.Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pagesDivide physical memory space into equal-sized pageframesAddress: 〈page,offset〉OS maintains a table (per process) mapping pagenumbers to frame numbersSince all frames have same size, checking upper bound ofoffset is straightforward.
Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging
Divide program into equal-sized pagesDivide physical memory space into equal-sized pageframesAddress: 〈page,offset〉OS maintains a table (per process) mapping pagenumbers to frame numbersSince all frames have same size, checking upper bound ofoffset is straightforward.Coarser grained than segmentation: same accessiblitylevel within a page
19 / 25
Memory FenceVirtual Memory
Reflections
Paging + Segmentation
Paging: implementation efficiencySegmentation: logical protectionIBM 390 mainframe: paged segmentation
20 / 25
Memory FenceVirtual Memory
Reflections
Outline
1 Memory Fence
2 Virtual Memory
3 Reflections
21 / 25
Memory FenceVirtual Memory
Reflections
Memory Protection: Hardware Only?
Memory protection can be achieved by softwaretechnology.
Example: OmniwareOmniVM bytecode: RISC architectureSegmentsSoftware-based Fault Isolation (SFI) is employed to rewriteunsafe code into safe code, using one of two techniques:
Segment matching: guard code is injected before theinstruction to check that the referenced segment id matchesthe allowed segmentSandboxing: the segment id of the target address isdynamically overwritten by the allowed segment id
Software-based protection is potentially finer grained:beyond segments
22 / 25
Memory FenceVirtual Memory
Reflections
Memory Protection: Hardware Only?
Memory protection can be achieved by softwaretechnology.Example: Omniware
OmniVM bytecode: RISC architectureSegmentsSoftware-based Fault Isolation (SFI) is employed to rewriteunsafe code into safe code, using one of two techniques:
Segment matching: guard code is injected before theinstruction to check that the referenced segment id matchesthe allowed segmentSandboxing: the segment id of the target address isdynamically overwritten by the allowed segment id
Software-based protection is potentially finer grained:beyond segments
22 / 25
Memory FenceVirtual Memory
Reflections
Memory Protection: Hardware Only?
Memory protection can be achieved by softwaretechnology.Example: Omniware
OmniVM bytecode: RISC architectureSegmentsSoftware-based Fault Isolation (SFI) is employed to rewriteunsafe code into safe code, using one of two techniques:
Segment matching: guard code is injected before theinstruction to check that the referenced segment id matchesthe allowed segmentSandboxing: the segment id of the target address isdynamically overwritten by the allowed segment id
Software-based protection is potentially finer grained:beyond segments
22 / 25
Memory FenceVirtual Memory
Reflections
Discussion: Protection within a Process
Other than anticipating programming errors, what aresecurity considerations that motivate memory protection(or in general, mutual suspicion) among code units within aprocess?
Extensible systemsBrowser plug-ins (via dynamic loading/linking)
Systems with scripting capabilitiesVisual Basic in Excel
Mobile codeJava applets
Systems that interpret codeDatabase query evaluation (code injection)
23 / 25
Memory FenceVirtual Memory
Reflections
Discussion: Protection within a Process
Other than anticipating programming errors, what aresecurity considerations that motivate memory protection(or in general, mutual suspicion) among code units within aprocess?
Extensible systemsBrowser plug-ins (via dynamic loading/linking)
Systems with scripting capabilitiesVisual Basic in Excel
Mobile codeJava applets
Systems that interpret codeDatabase query evaluation (code injection)
23 / 25
Memory FenceVirtual Memory
Reflections
Discussion: Protection within a Process
Other than anticipating programming errors, what aresecurity considerations that motivate memory protection(or in general, mutual suspicion) among code units within aprocess?
Extensible systemsBrowser plug-ins (via dynamic loading/linking)
Systems with scripting capabilitiesVisual Basic in Excel
Mobile codeJava applets
Systems that interpret codeDatabase query evaluation (code injection)
23 / 25
Memory FenceVirtual Memory
Reflections
Discussion: Protection within a Process
Other than anticipating programming errors, what aresecurity considerations that motivate memory protection(or in general, mutual suspicion) among code units within aprocess?
Extensible systemsBrowser plug-ins (via dynamic loading/linking)
Systems with scripting capabilitiesVisual Basic in Excel
Mobile codeJava applets
Systems that interpret codeDatabase query evaluation (code injection)
23 / 25
Memory FenceVirtual Memory
Reflections
Discussion: Protection within a Process
Other than anticipating programming errors, what aresecurity considerations that motivate memory protection(or in general, mutual suspicion) among code units within aprocess?
Extensible systemsBrowser plug-ins (via dynamic loading/linking)
Systems with scripting capabilitiesVisual Basic in Excel
Mobile codeJava applets
Systems that interpret codeDatabase query evaluation (code injection)
23 / 25
Memory FenceVirtual Memory
Reflections
A Change of World View
The traditional world view: Processes as units ofprotection.
With the emergence of dynamic loaded code, scripting,mobile code, and multi-language development, thetraditional world view simply is no longer valid.As we shall see, intra-process memory protection istypically achieved by software means.
24 / 25
Memory FenceVirtual Memory
Reflections
A Change of World View
The traditional world view: Processes as units ofprotection.
With the emergence of dynamic loaded code, scripting,mobile code, and multi-language development, thetraditional world view simply is no longer valid.
As we shall see, intra-process memory protection istypically achieved by software means.
24 / 25
Memory FenceVirtual Memory
Reflections
A Change of World View
The traditional world view: Processes as units ofprotection.
With the emergence of dynamic loaded code, scripting,mobile code, and multi-language development, thetraditional world view simply is no longer valid.As we shall see, intra-process memory protection istypically achieved by software means.
24 / 25
Memory FenceVirtual Memory
Reflections
Bibliographic Notes
Most of the materials in these slides are based on Section5.1 of [Pfleeger et al.].OmniWare and SFI:
Ali-Reza Adl-Tabatabai, Geoff Langdale, Steven Lucco, andRobert Wahbe. Efficient and language-independent mobileprograms. In Proceedings of ACM SIGPLAN’96Conference on Programming Language Design andImplementation (PLDI’96), pages 127-136, May 1996.Robert Wahbe, Steven Lucco, Thomas E. Anderson, andSusan L. Graham. Efficient software-based fault isolation.In Proceedings of the 14th ACM Symposium on OperatingSystems Principles, pages 203-216, Asheville, NorthCarolina, December 1993.
25 / 25