[FrontPage] [TitleIndex] [WordIndex

Note: You are looking at a static copy of the former PineWiki site, used for class notes by James Aspnes from 2003 to 2012. Many mathematical formulas are broken, and there are likely to be other bugs as well. These will most likely not be fixed. You may be able to find more up-to-date versions of some of these notes at http://www.cs.yale.edu/homes/aspnes/#classes.

Memory protection: How to make sure you can't read (or worse write) my data (unless I want you to).

1. Segmentation approach

Break physical memory up into segments. Limit who can access which segment by supplying each with a base and limit value and some protection bits. Only let the kernel modify the segment addresses, and trap if a process tries to access an address outside its segment.

2. Paging

Same thing but use page tables so that processes can't even see physical addresses they aren't supposed to use. Additional constraints in page tables may mark pages as e.g. execute only or read only, so that programs can't rewrite their code (or shared libraries) by accident.

3. Software memory protection

Make processes responsible for not generating out-of-bounds addresses, perhaps by using a strongly-typed language like Java or C# that doesn't give you the ability to hit arbitrary memory addresses.

In general, this violates the never trust a process rule, but it can perhaps be enforced if you have control over the compilation toolchain and can verify that the code that you have came out of a trusted toolchain (e.g. using a digital signature). Alternatively, require the compiler to insert explicit bounds checks and only run code that has such checks.


CategoryOperatingSystemsNotes


2014-06-17 11:58