Memory Protection - University of Calgary in AlbertaMemory Fence Virtual Memory Reﬂections Memory Protection Philip W. L. Fong Department of Computer Science University of Calgary

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


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


Reflections

Enter the Notion of Processes

Before:

After:

3 / 25


Reflections

Memory Protection

Preventing memory interference

Traditionally implemented by hardware

4 / 25


Reflections

Memory Protection

Preventing memory interferenceTraditionally implemented by hardware

4 / 25


Reflections

Outline

1 Memory Fence

2 Virtual Memory

3 Reflections

5 / 25


Reflections

Outline

1 Memory Fence

2 Virtual Memory

3 Reflections

6 / 25


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


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


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


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


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


Reflections


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




9 / 25


Reflections




address + base




9 / 25


Reflections




address + base




9 / 25


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


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


10 / 25


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


10 / 25


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


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


Reflections

Example: Burroughs B6500-7500

3 tag bits to differentiatedata wordspointerscontrol words (i.e., stack pointers, etc)

12 / 25


Reflections

Example: BiiN

one tag for a block of size 128 or 256 bytesless costly

13 / 25


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


Reflections

Outline

1 Memory Fence

2 Virtual Memory

3 Reflections

15 / 25


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


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


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


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


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


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


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


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


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


Reflections

Paging + Segmentation

Paging: implementation efficiencySegmentation: logical protectionIBM 390 mainframe: paged segmentation

20 / 25


Reflections

Outline

1 Memory Fence

2 Virtual Memory

3 Reflections

21 / 25


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


Reflections


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:



22 / 25


Reflections


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:



22 / 25


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


Reflections







23 / 25


Reflections







23 / 25


Reflections







23 / 25


Reflections







23 / 25


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


Reflections



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


Reflections



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


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

Documents

Memory Protection - University of Calgary in AlbertaMemory Fence Virtual Memory Reﬂections Memory Protection Philip W. L. Fong Department of Computer Science University of Calgary