1. Zeldovich et al. (both papers) Reading Group by Theo

2. Part 1/2 Slides based on Zeldovich’s talk 2

3.  Untrustworthy code everywhere ◦ Legitimate programs are vulnerable  Even antivirus scanners… ◦ Users authorize malicious software  Not getting any better ◦ Software becomes more complex  Can the O/S guarantee security? ◦ Probably not… 3

4. Virus Scanner Live Update Internet Private User Files /tmp Virus Database Acceptable flow Private files should not leak to the internet! 4

5. Virus Scanner Live Update Internet Private User Files /tmp Virus Database O/S 5

6. Virus Scanner Live Update Internet Private User Files /tmp Virus Database O/S 6

7. Virus Scanner Live Update Internet Private User Files /tmp Virus Database Or: Create file SecretBitIs1.txt 2 malicious apps cooperating hard to detect! Covert Channel: Lock virus DB 7

8.  Existing O/S are too complex ◦ Too many protection mechanisms  File descriptors, user ids  Doesn’t help with security Unix P3 P2 P1 Unix Kernel (TCB) Unix Kernel (TCB) H/W Complex Objects 8

9. UnixHiStar Unix Lib P3 P2 P1 Unix Kernel (TCB) Unix Kernel (TCB) H/W P2 P1 U1 P3 U3 U2 HiStar Kernel (TCB) HiStar Kernel (TCB) H/W Simple Objects 9

10.  Most Unix implemented as user-level libraries ◦ Narrow, easily controlled interface  All kernel objects have the same, flat namespace ◦ Files, users, processes, address spaces are kernel objects  All information flow is made explicit 10

11. High Data High Process Low Data Low Process e.g.: credit card processing Web Server Globally visible, read-only confi- guration file e.g.: Untrusted user process ‘High’ information should never modify ‘low’! Information only flows upwards 11

12.  Each kernel object has a label ◦ Files, users, programs, etc  Each label is a set of categories  For each category, each object has a level  E.g. ‘unmodifiable’, ‘secret’ file of user X 12

13. LevelMeaning 0Unmodifiable (read-only) 1Default Level 2Cannot be exported from PC 3Inaccessible (no read) ⋆ Super access (can R/W anything, change tags) Fully trusted Top Secret Process can read less secret data (lower level), can write less trusted data (higher level) Objects can have multiple labels (top secret & unmodifiable) 13

14. Bob’s Files Bob’s Files Bob’s Process Bob’s Shell Internet Alice’s Files Alice’s Files Alice’s Process Alice’s Shell Color Mismatch 14

15. Bob’s Secret Files Bob’s Secret Files Bob’s Files Bob’s Shell Alice’s Files Alice’s Files Alice’s Shell Root shell 15

16.  S/W only implementation  11,600 TCB kernel code ◦ Hmmm. Can we do better? (LoStar) ◦ 1,300 extra bootstrapping code  HiStar ensures that you have enough rights to execute, read, write data  Malicious web app can leak data only of the users that called it.  Does not protect against DoS 16

17. 17

18. Part 2/2 18

19.  HiStar has few kernel objects ◦ Process, files, address space, etc  Each object has a label ◦ ‘Colored’ objects ◦ Access allowed only when I have enough credentials for that label  Let’s color the physical RAM! ◦ Using Raksha-like H/W 19

20. UnixHiStar P2 P1 U1 P3 U3 U2 HiStar Kernel (TCB) HiStar Kernel (TCB) DRAM Unix Lib P3 P2 P1 Unix Kernel (TCB) Unix Kernel (TCB) DRAM LoStar P1 U1 P2 Ker nel P3 U3 U2 Ker nel (TCB) Security Monitor (TCB) Security Monitor D D R R A A M M Super -Visor Moni- tor Physical RAM Authorized Colors Protection Domain 20

21.  Each 32-bit word has a 32-bit color  Every memory reference (I and D) will retrieve the associated color  The security monitor checks the HiStar label for that color and the current thread’s rights  Check will be cached for future reuse 21

22. Tags L1-I PC De- code Reg. File Permission Checks EXC WB ALU Preexisting Loki Logic Loki Tags L1-D Execute P-Cache R/W P-Cache Memory Controller Memory Tags Tag Handling 22

23.  Color: 32-bit physical address of HiStar’s label ◦ 1 color per page  Indirect entry for multi-colored pages (color/word)  Colors stored in RAM ◦ Physical address space reserved  Virtual memory manager not in the TCB  Colors associated with physical addresses ◦ No aliasing problem 23

24.  A cache of recently checked labels ◦ 32-bit color tag and 3 bit permissions (RWX)  32-entry 2-way set associative  Can be thought as TLB ◦ Permission Lookaside Buffer ◦ Normal TLB tricks apply  Eg P-Cache-I and P-Cache-D  Saved on context switch 24

25.  Security exception calls LoStar’s monitor ◦ Not the kernel (HiStar) of the active thread  Security monitor in TCB ◦ No checks performed ◦ No physical – virtual translation ◦ ‘Trusted’ mode above the H/W supervisor move 25

26.  HiStar calls LoStar for new labels ◦ LoStar will write-protect the new label  LoStar protects critical global HiStar structures ◦ E.g., kernel object hash table ◦ HiStar kernels do not have to trust each other  So virtual memory manager not in the TCB  LoStar does not guarantee liveness 26

27. Pipeline Depth7L1-I16 KB, 2-way SA Register Windows8L1-D32 KB, 2-way SA Memory512 MBI-TLB8-entry, fully assoc. Bus width64 bitsD-TLB8-entry, fully assoc. Frequency65 MHzI-Tag Cache8-entry, fully assoc.* D-Tag Cache8-entry, fully assoc.* P-Cache32-entry 2-way SA *Store page granularity tags. Multicolored pages store tags in ‘modified’(?) caches 27

28.  Hardware Overhead  Trusted Code Base ComponentBlock RAMs4-input LUTs Base Leon4314,502 Loki Logic22,756 % increase519 Lines of codeHiStarLoStar Kernel code11,60012,700 Bootstrapping code1,300 Security monitor-5,200 TCB size11,6005,200 28

29. 29

30. 30

31. HiStar LoStar LoStar without page tags 1.4 1.6 1.0 1.2 0.6 0.8 0.2 0.4 0.0 Average Slowdown primes syscall IPC fork/exec small-file large-file wget gzip Benchmarks 31

32.  HiStar is an O/S with strict information flow ◦ Most O/S implemented as user library ◦ ~11,000 TCB ◦ Achieves good performance  LoStar is a hardware-assisted HiStar ◦ ~5,000 TCB ◦ Similar performance to HiStar  Unclear whether the benefit of reduced TCB outweighs the cost of extra H/W 32

33.  Questions? 33