Secure Operating Systems
-
Upload
eagan-franklin -
Category
Documents
-
view
27 -
download
0
description
Transcript of Secure Operating Systems
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?