Secure Operating SystemsLesson 6: Memory

Where are we? We’re half way through sharing things –

we’ve covered synchronization Time to look at memory (because it’s a thing

that’s used in sharing a lot)

A Little Architecture The memory in registers is available

instantly… but main memory isn’t (can take a few clock cycles)

Thus, we have a cache to speed things up a LOT (a processor stall is a Bad Thing™)

Multi-process Simplest approach is base and limit – the base

is the lowest valid address, the limit the largest

Access outside this causes a trap into the OS This all implies modules which are

relocatable – addresses are relative to a base

Logical vs. Physical There’s the actual memory (physical) and the

address the program sees (logical) Can be the same… but easier if they’re not Typically, mapping is done in hardware for

speed using the MMU (memory management unit) A simple approach is to use a relocation register

Swapping If we run out of memory, a process which is

not executing can be swapped to disk (typically) Slow, but huge (and we’re talking orders of magnitude…)

Not everything can be swapped – example?

Memory Fragmentation Yikes! If we can map memory in large blocks

for processes, memory gets fragmented To deal with tracking this we have an

allocation granularity (tracking at a 1 byte resolution is expensive)

Solution to fragmentation is compaction – basically, relocate the code (again) in memory in real time

Extending this: paging In paging we extend our model by mapping

pages of memory and using a page table to “fixup” the addresses at runtime

This also allows some really clever optimization, and is worth talking about (we’ll look at Windows in a moment)

Hardware Support for Paging Old school: use super-fast registers. Why

fast? Because pretty much everything uses memory accesses - even a NOP (?)

New(er) school: have a page table base register that points to a place in memory that functions as the page table

Current approach: the TLB

Translation look-aside buffer Very high speed lookup hardware cache –

expensive Cannot keep track of everything, only things

we use a lot; often less than 1024 entries These map pages back to physical memory Studying this stuff is a study in optimization!

Case Study: Windows First, let’s see what we’ve got…

VOID GetSystemInfo(LPSYSTEM_INFO); The thing we care about is the

AllocationGranularity here…. And the page size. Note they’re not the same.

The State of an Address DWORD VirtualQuery(

LPCVOID pvAddress,PMEMORY_BASIC_INFORMATION pmbi,DWORD dwLength);

DWORD VirtualQueryEx(HANDLE hProcess,LPCVOID pvAddress,PMEMORY_BASIC_INFORMATION pmbi,DWORD dwLength);

Reserving and Committing… You can reserve memory without committing

it… this means it’s not backed by the paging file… Why is this handy?

Example: a spreadsheet using VirtualAlloc and VirtualQuery

Memory Mapped Files In Windows we can do something really cool:

a memory mapped file Can just use CreateFile… Then use CreateFileMapping,

MapViewOfFileEx… Interestingly, if you use

INVALID_HANDLE_VALUE you can back this all by the page file

Create/Open FileMapping We get to name our file mapping object, so

the object can be shared As an aside, the ways in which processes can

communicate is pretty broad – this brings up the topic of covert channels

Wait DWORD WaitForSingleObject(

HANDLE hObject,DWORD dwMilliseconds

); How long to wait for an object to be signalled Example: WaitForSingleObject(hProcess,

INFINITE);

Can also wait for more… DWORD WaitForMultipleObjects(

DWORD dwCount,CONST HANDLE *phObjects,BOOL bWaitAll,DWORD dwMilliseconds

);

Things to Do Implement a solution to the dining

philosophers problem using Windows and C++ - make sure that in all cases, you don’t deadlock

Read OSC Ch 8 & 9 – you should have these skills already

Questions & Comments What do you want to know?