HiStar and LoStar

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

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

3. Untrusted Software • 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…

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

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

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

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

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

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

10. HiStar (cont.) • 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

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

12. HiStar Labels • 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

13. HiStar Labels Fully trusted Top Secret Objects can have multiple labels (top secret & unmodifiable) Process can read less secret data (lower level), can write less trusted data (higher level)

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

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

16. HiStar Implementation • 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

17. HiStar ResultsSlowdown vs Linux

18. LoStar Part 2/2

19. From HiStar to LoStar • 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

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

21. LoStar Operation 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

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

23. LoStar Colors • 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

24. Permission Cache • 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

25. Tag Exceptions • 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

26. HiStar on LoStar • 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

27. Loki Implementation *Store page granularity tags. Multicolored pages store tags in ‘modified’(?) caches

28. Interesting Statistics Hardware Overhead Trusted Code Base

29. Percent of Monochromatic Pages

30. Maximum Number of Active Tags

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

32. Conclusion (finally!) • 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

33. Thank you! Questions?