Secure Operating Systems

1. Secure Operating Systems Lesson 6: Memory

2. 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)

3. 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™)

4. 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

5. 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

6. Swapping • If we run out of memory, a process which is not executing can be swappedto disk (typically) • Slow, but huge • (and we’re talking orders of magnitude…) • Not everything can be swapped – example?

7. 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

8. 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)

9. 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

10. 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!

11. 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.

12. 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);

13. 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

14. 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

15. 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

16. Wait • DWORD WaitForSingleObject( HANDLE hObject, DWORD dwMilliseconds); • How long to wait for an object to be signalled • Example: WaitForSingleObject(hProcess, INFINITE);

17. Can also wait for more… • DWORD WaitForMultipleObjects( DWORD dwCount, CONST HANDLE *phObjects, BOOL bWaitAll, DWORD dwMilliseconds);

18. 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

19. Questions & Comments • What do you want to know?