Week 6: Capabilities Advanced Operating Systems ( L)

Transcription

1 Week 6: Capabilities Advanced Operating Systems ( L) Timothy Roscoe Herbstsemester Systems Group Department of Computer Science ETH Zürich 1

2 Milestone 5: A memory manager Barrelfish uses capabilities to refer to memory regions You ve seen them in milestone 4 Today: Capabilities in general Memory management using capabilities The Barrelfish capability system 2

3 Overview for today Access control Access control lists vs. capabilities Capabilities and the Confused Deputy Implementation options Tagged capabilities Sparse capabilities Partitioned capabilities Memory management Capabilities in Barrelfish 3

4 Access control matrix Representation/definition of permissible operations in a system Objects Subjects user 1 user 2 user 3 file 1 file 2 user 1 Send msg RW R user 2 Send msg RW user 3 Set passwd Set passwd Set passwd R Subjects: users, processes, groups, etc. Objects: other users/processes, files, memory objects, etc. Privileges/rights: depends on object for file: read, write, execute, etc. 4

5 Access control matrix properties Dynamic data structure, frequent changes Very sparse with many repeated entries Impractical to store explicitly Most common discretionary mechanisms: Access control list: stores a column (who can access this) Capabilities: store a row (what this can access) 5

6 Issues for discretionary access control Propagation: Can a subject grant access to another? Restriction: Can a subject propagate a subset of its own rights? Revocation: Can access, once granted, be revoked? Amplification: Can an unprivileged subject perform restricted operations? Determination of object accessibility: Which subjects have access to a particular object? Is an object accessible by any subject? (garbage collection) Determination of subject s protection domain: Which objects are accessible to a particular subject? 6

7 Access control lists Implemented by most commodity systems ACL associated with object Propagation: meta right (eg. owner may chmod) Restriction: meta right Revocation: meta right Amplification: protected invocation right (eg. setuid) Accessibility: explicit in ACL Protection domain: hard (if not impossible) to determine Usually condensed via groups / classes Can have negative rights Sometimes implicit (eg. UNIX process hierarchy) 7

8 UNIX ACLs Despite modern terminology, classic UNIX privileges are a (restricted) ACL representation ACL rights subject (owner) subject (group) object Permissions for other are an implicit group of subjects 8

9 Capabilities Capability list associated with subject Each capability confers a certain right to its holder Propagation: copy/transfer capabilities between subjects Restriction: requires creation of new (derived) caps Revocation: requires invalidation of caps from all subjects (may be difficult) Amplification: special invocation capability Accessibility: requires inspection of all capability lists (hard if not impossible to determine) Protection domain: explicit in capability list 9

10 (Partial) history of capability systems 1961 Burroughs B Dennis and Van Horn s supervisor 1967 MIT PDP 1 Timesharing System Chicago Magic Number Machine 1968 Berkeley CAL TSS 1972 Plessey System Cambridge CAP Computer 1974 CMU Hydra; then StarOS Gnosis, KeyKOS, Eros, Coyotos 1980 present 1981 Intel iapx Linn Rekursiv 2005 present 2009 present IBM System/38, AS/400, iseries, System i, sel4 Capsicum (BSD) 10

11 Capabilities Main advantage of capabilities is fine grained access control Easy to provide access to specific subjects Easy to delegate permissions to others A cap presents prima facie evidence of right to access Think of it as a key Any representation must protect capabilities against forgery Consists of object identifier and a set of access rights Implies object naming Solves the confused deputy problem 11

12 The Confused Deputy Source file Compiler Compiler has authority to write accounting file User supplies object filename, authorized to write Accounting file System volume Object file User directory 12

13 The Confused Deputy Regular command line: cc o ~/program program.c But what about:? Oh dear cc o /var/spool/accounts program.c 13

14 The Confused Deputy Compiler has two masters: User System accounting Acquires blanket authority from both Compiler Compiler has authority to write accounting file User supplies object filename, authorized to write Accounting file System volume Object file User directory 14

15 Solution using capabilities Source file + Output file Capability: File Compiler Compiler has authority to write accounting file Accounting file User supplies object filename, authorized to write Accounting file System volume Object file User directory 15

16 How are capabilities implemented and protected? 1. Tagged: protected by hardware 2. Sparse: protected by sparsity (probabilistically secure, like encryption 3. Partitioned: protected by software 16

17 Tagged capabilities AKA hardware capabilities Extra tag bit with every memory word (or group thereof) Tag identifies capabilities Capabilities may be used and copied like normal pointers Hardware checks permissions when dereferencing capability Modifications turn the tag off (reverting caps to plain data) Only the kernel can turn a tag bit on Propagation easy Restriction requires kernel to create new (weaker) capability Revocation virtually impossible (requires memory scan) Accessibility virtually impossible to determine 17

18 Tagged capabilities outside RAM Disk has no tags AS/400 simulates them by restricting physical I/O to the low level OS Extra bit stored for every word on disk Page out page scanned and tags collected Page in tags are reconstructed Significant processing overhead on all disk I/O 18

19 Tagged capabilities: summary Secure through hardware protection Convenient for applications (appear as normal pointers) Checked by hardware fast validation Capability hardware is complex (hence slow) Separate mechanisms required for I/O and distribution 19

20 Sparse capabilities Basic idea similar to encryption: Add bit string to capability Makes valid capabilities a tiny subset of the capability space Secure by infeasibility of exhaustive search of cap space 20

21 Encrypted sparse capabilities Object ID rights Encrypt Object ID rights Signature Signature: bit string is encrypted object info Cap consists of object ID, rights, and signature Signature = object ID and rights encrypted with a private key Validated by checking signature 21

22 Password capabilities Capability: Object ID Password Global object table: OID Password Rights Password: bit string is random data Cap consists of object ID, and password Rights determined by looking up password in a global object table 22

23 Sparse capabilities: summary Sparse caps are regular user level objects Can be passed like other data Similar to tagged caps, but without hardware support Validated at invocation time (either explicitly or implicitly) Issues: Full mediation requires extra support See Mungi High amplification of leaked data Problem with covert channels 23

24 Partitioned capabilities System maintains capabilities for each process, eg. as a capability list (clist) User code uses only handles (indirect references) to caps System validates access when performing any privileged operation (eg. mapping a page) Validation is explicit at syscall time Propagation: system call to copy a cap between clients Restriction: invoke kernel to create new cap Revocation: invoke kernel to remove cap from clist Accessibility: requires scanning all clists Protection domain: explicitly represented in clist Used in Hydra, Mach, KeyKOS, EROS, sel4, Barrelfish, many others 24

25 Memory partitioning CNode capabilities: Storage for capability representations Divided into slots Unreadable from user space! Frame capabilities May be mapped into user virtual address space Multiple of page size There must never be an area of memory referred to by both a CNode cap and a Frame cap! 25

26 Partitioned capabilities: summary Secure through kernel protection Real caps live only in kernel space Validation at mapping/invocation time Apps use normal pointers Fast validation possible (for memory objects, validation is cached by MMU) Propagation requires kernel intervention Reference counting and revocation possible with kernel support No special hardware requirements 26

27 Allocation and management of physical memory Problem: Most kernels use dynamic allocation (malloc) for metadata What do you do when it runs out? sel4 model, extended in Barrelfish: All physical memory manipulated as partitioned capabilities Memory not used for bootstrap is initially untyped User controls allocation Retyping Splitting No dynamic allocation performed in kernel! 27

28 Barrelfish design decision Provide one general mechanism for tracking all OS resources Disadvantages: Mechanism must be fully general (more complex than point solutions) Potential performance hit for some operations (price of generality) Advantages: Solve this once, everything works Provides insight into the general problem for multicore hardware good from research perspective 28

29 Capabilities in Barrelfish All memory described using capabilities Along with some other system resources Capabilities are typed type of memory Memory can be retyped by its owner Subject to certain rules Memory regions can be split Result: 2 new capabilities, of the same type One for each half 29

30 Partitioned capabilities (CAP, sel4, KeyKOS, etc.) All memory regions referred to by typed capabilities CNode Frame cap. CNode cap. Dispatcher cap. Null cap. Mappable RAM Frame cap. Frame cap. Frame cap. Frame cap. Dispatcher control block 30

31 Capabilities in Barrelfish Partitioned capabilities are used CNode memory type holds capabilities Every domain has a set of capabilities The CSpace Represented as a guarded page table Root is held in the DCB Capabilities are named by a capref Address in this GPT. 31

32 Capabilities in Barrelfish Each type supports a set of operations: Think of them a bit like object references Most system calls actually capability operations Restrictions on operations enforce invariants E.g. It should be impossible to construct a bad page table from user space 32

33 (Almost) complete capability type system Frame PhysAddr DevFrame RAM Dispatcher CNode EndPoint FCNode Null VNode_x86_64_pml4 Kernel Notify Domain IRQTable IO VNode_x86_64_pdpt VNode_x86_64_pdir VNode_x86_64_ptable Retype operations VNode_x86_32_pdpt BMPEndPoint VNode_x86_32_pdir BMPTable VNode_x86_32_ptable VNode_ARM_l1 VNode_ARM_l2 33

34 Specifying capability types sel4 used a small, fixed number of capability types Hardcoded into kernel, key to the design Barrelfish uses types freely Goal: support heterogeneous architectures Different types for all page table pages, etc. How to manage complexity of type system? 34

35 Hamlet cap Null is_never_copy { /* Null/invalid object type */ }; cap PhysAddr from_self { /* Physical address range (root of cap tree) */ }; Empty capability slot Any physical address region Retyping from self can be split into parts address genpaddr base; /* Base address of untyped region */ size_bits uint8 bits; /* Address bits that untyped region bears */ Can be retyped from PhysAddr /** The following caps are similar to the previous one **/ cap RAM from PhysAddr from_self { /* RAM memory object */ A physical address region containing RAM }; address genpaddr base; /* Base address of untyped region */ size_bits uint8 bits; /* Address bits that untyped region bears */ 35

36 Hamlet cap CNode from RAM { /* CNode table, stores further capabilities */ lpaddr cnode; /* Base address of CNode */ uint8 bits; /* Number of bits this CNode resolves */ caprights rightsmask; uint8 guard_size; /* Number of bits in guard */ caddr guard; /* Bitmask already resolved when reaching this rights CNode mask */ address { cnode }; size_bits { bits + cte_size }; Includes guarded page table information and }; cap Frame from RAM from_self { /* Mappable memory frame */ RAM caps cannot be mapped (why?) Frame caps can. }; address genpaddr base; /* Physical base address of frame */ size_bits uint8 bits; /* Address bits this frame bears */ 36

37 Hamlet /* ARM specific capabilities: */ cap VNode_ARM_l1 from RAM { /* L1 Page Table */ address genpaddr base; /* Base address of VNode */ size_bits { vnode_size }; }; Page table pages have their own types! cap VNode_ARM_l2 from RAM { /* L2 Page Table */ address genpaddr base; /* Base address of VNode */ size_bits { vnode_size }; }; 37

38 Hamlet cap Dispatcher from RAM { /** The Dispatcher is a special case that can be retyped several times to an end point **/ can_retype_multiple; }; "struct dcb" dcb; /* Pointer to kernel DCB */ address { mem_to_phys(dcb) }; size_bits { dispatcher_size }; Dispatcher control blocks are user allocated kernel objects cap EndPoint from Dispatcher { /* IDC endpoint */ "struct dcb" listener; /* Dispatcher listening on this endpoint */ lvaddr epoffset; /* Offset of endpoint buffer in disp frame */ }; uint32 epbuflen; /* Length of endpoint buffer in words */ address { mem_to_phys(listener) }; We ll see endpoints later: they allow communication with domains 38

39 Capability references Referring to capabilities from user space struct cnoderef { capaddr_t address; ///< Base address of CNode in CSpace uint8_t address_bits; ///< Number of valid bits in base address uint8_t size_bits; ///< Number of slots in the CNode as a power of 2 uint8_t guard_size; ///< Guard size of the CNode } attribute ((packed)); struct capref { struct cnoderef cnode; ///< CNode this cap resides in capaddr_t slot; ///< Slot number within CNode }; 39

40 Copying, retyping, and minting All operations must specify Source capability (in some CSpace slot) Destination slot (also in CSpace) Examples: Simple copy Retype (including split) Mint (changing rights) 40

41 A good design decision? Leads to a complex interface Overgenerality? Hard to do resource specific optimizations When it works, very sound basis User level resource management Solid security foundation Can t exhaust kernel resources Decide for yourself! 41