Faculty of Computer Science Institute for System Architecture, Operating Systems Group. Naming. Stefan Kalkowski. Dresden,

Transcription

1 Faculty of Computer Science Institute for System Architecture, Operating Systems Group Naming Stefan Kalkowski Dresden,

2 So far... Basics: Tasks and Threads Synchronization Memory Communication Device Drivers Real-Time Today: Naming Slide 2 von 37

3 Motivation Naming is relevant for different abstractions: Kernel objects File systems Networks Programming languages Hardware... for different purposes: Usability Security Slide 3 von 37

4 Today Naming Terminology Distributed name services Global vs. local name spaces Naming and access: Capabilities Examples Slide 4 von 37

5 Terminology: Names Symbolic names: textual representation of an entity Address: locates an entity Identifiers: identifies (uniquely) an entity of a system Slide 5 von 37

6 Example: DNS. com edu org kernel de wikipedia de = URI: symbolic name and identifier gets resolved to IP address Slide 6 von 37

7 More Terminology Name space resp. context: contains mappings of higher-level to lowerlevel names or attributes (e.g.: symbolic name -> address, id, symbolic name) Name resolution: process of mapping Name service: activity that performs name resolution Slide 7 von 37

8 Example: UNIX VFS Inode 0 ('/') links -> inode 1 etc -> inode 2 Directory = Name space Inode 1 ('/links') Inode 2 ('/etc') fstab -> /etc/fstab bashrc -> inode 4 fstab -> inode 5 bashrc -> inode 4 Inode = Identifier Slide 8 von 37

9 Example: UNIX VFS [14:56:59] >> ls -dils SOFTLINK 0 4 drwxr-xr-x 4 root root 4096 Sep 27 14: drwxr-xr-x 2 root root 4096 Sep 27 14:49 links 4 4 -rw-r r-- 2 root root 1293 Sep 27 14:48 links/bashrc 3 0 lrwxrwxrwx 1 root root 9 Sep 27 14:49 links/fstab->etc/fstab 2 4 drwxr-xr-x 2 root root 4096 Sep 27 14:48 etc 4 4 -rw-r r-- 2 root root 1293 Sep 27 14:48 etc/bashrc 5 4 -rw-r r-- 1 root root 1026 Sep 27 14:48 etc/fstab HARDLINK Slide 9 von 37

10 Example: C++ namespace My_names { class Example {... } } // specify the name space explicitly My_names::Example obj(); // specify name space until block ends using namespace std; cout << address of obj: << &obj; Slide 10 von 37

11 More Differentiation... Name spaces can be organized: flat or hierarchical global or local Name services might be implemented centralized or distributed Resolving names can be done iterative or recursive Slide 11 von 37

12 Distributed name service Example: Name: /a/b/c implemented by three name servers Name server one provides initial context Client Name Server 1 Name Server 2 Name Server 3 Name Space Slide 12 von 37

13 Iterative name resolution I Client controlled iterative lookup Client Client repeatedly queries servers 1 (1)lookup(ns1, /a/b/c ) -> client: ns2, /b/c (2)lookup(ns2, /b/c ) -> client: ns3, /c (3)lookup(ns3, /c ) -> client: file_id 2 Name Server 1 Name Server 2 3 Name Server 3 Name Space Slide 13 von 37

14 Iterative name resolution II Server controlled iterative lookup Client Initial name server repeatedly queries subsequent name servers 1 (1)lookup(ns1, /a/b/c ) (2)lookup(ns2, /b/c ) -> ns1: ns3, /c (3)lookup(ns3, /c ) -> ns1: file_id -> client: file_id 2 Name Server 1 Name Server 2 3 Name Server 3 Name Space Slide 14 von 37

15 Recursive name resolution Server controlled recursive lookup Client Each name server queries subsequent name server 1 (1)lookup(ns1, /a/b/c ) (2)lookup(ns2, /b/c ) (3)lookup(ns3, /c ) -> ns2: file_id -> ns1: file_id -> client: file_id 2 Name Server 1 Name Server 2 Name Server 3 3 Name Space Slide 15 von 37

16 Distributed name service: L4VFS Part of the L4 Environment Provides a UNIX like hierarchical name space Distributed name service with object and name servers Application Backend Name server Object servers provide sub name spaces called volumes Name servers manage volumes and resolve names Object server Ext2fs Object server Terminal Slide 16 von 37

17 Distributed name service: L4VFS Name server Maps symbolic names -> object ids: (volume id).(local object id) Iteratively queries object servers to resolve names Maps volume ids to object servers Manages mount table Application Backend Name server Object server Maps names -> local object ids Can manage different volumes Keeps client s state (seek pos., access mode,...) Object server Ext2fs Object server Terminal Slide 17 von 37

18 L4VFS: Mounting server Mounting is completely done by name Application Mount table is checked for each step Backend in name resolution Mount point Volume 3... Root: 0.0 Name server / 0.0 dev 0.1 tty1 0.3 etc 0.2 tty1 Object server 3.0 Ext2fs tty2 Object4.0 server Terminal conf 0.4 Slide 18 von 37

19 L4VFS: Resolution Request: /dev/input/mice -> 3.2 Mount point Name server Volume 3... Root: resolve(0.1, resolve(0.0,'input') 'dev') resolve(3.0, 'mice') Object server 1 / 0.0 dev 0.1 input 0.3 Object server 2 / 3.0 etc 0.2 event 3.1 conf 0.4 mice 3.2 Slide 19 von 37

20 Local vs. global name spaces Global name spaces: All instances share the same view Classical in monolithic systems Easy to configure Local name spaces: Instances have a private name space Forwards 'principle of least privilege' Facilitates virtualization and debugging Development trend: FreeBSD's jails or chroot Slide 20 von 37

21 Principle of least privilege Every program and every user of the system should operate using the least set of privileges necessary to complete the job. (Saltzer and Schroeder) General design principle to reduce vulnerabilities in software Local name spaces enable developers to put this into practice Slide 21 von 37

22 Problems with global names Example: L4 thread ids are globally visible Everyone can send IPC to everyone Services need to care of access control Denial of Service attacks are possible No full isolation Possible solution: Reference monitor Kernel uses a bitmap that contains communication rights Simpler solution: using local names Slide 22 von 37

23 Local names example: Plan 9 Developed by Bell Labs in the late 1980 s Distributed system, one UNIX out of a lot of systems Main features: All resources are named and accessed like files Network protocol 9P for remote file access Per process, private hierarchical file name space Slide 23 von 37

24 Local names example: Plan 9 Services export file hierarchies Processes mount services they use into their own name space Processes might inherit the name space of their parent process In addition processes can use bind to duplicate paths in the file hierarchy Slide 24 von 37

25 Combine name and access Capabilities Designate a specific object (e.g.: kernel object) and give certain access rights to that object Possession of a capability is sufficent to access the concerning object Can be implemented by using hardware support, memory protection mechanisms or cryptography Famous capability systems: KeyKOS, EROS, Coyotos Mach / GNU Hurd Amoeba Slide 25 von 37

26 Capability properties Capability models differ: Originally: possession of a capability is sufficient to further delegate that capability -> complicates information flow control Today: most capability systems have separate privileges for capability propagation Capabilities vs. Access Control Lists: R... Alice Alice Resource Access control list R... Resource Capability list Slide 26 von 37

27 Capabilities in practice L4.Sec (Florence): Local names in a task local capability space translate to capabilities Capabilities reference kernel objects, especially endpoints Capabilities can be obtained by creating an object or by mapping An additional identifier the badge is associated with each endpoint capability Badges enable the receiver to distinguish sender capabilities from each other Slide 27 von 37

28 Capabilities to Endpoints Make thread implementation details transparent Client 1 Objects Server 1456 Kernel Badges endpoint Client Slide 28 von 37

29 Capabilities in userland: Bastei Strict hierarchical structure Core provides basic services to provide system's resources GUI Parent node acts as name server and 'reference monitor' User Session Init Resource accounting for every service a node uses Terminal Core Slide 29 von 37

30 Capabilities in userland: Bastei Tasks initially possess only a parent capability Child nodes query their parent for services/objects GUI Child nodes can announce services at their parent Subsystem configuration can be implemented by creating new subtrees Terminal User Session Init Core Slide 30 von 37

31 Bastei: Service announcement Announcing services: GUI root announce( GUI, root_cap) Init Core Slide 31 von 37

32 Bastei: Open a session Using service: Terminal session( GUI, input=yes, label=xterm ) GUI User Session root session( input=false, label=bob->xterm ) session( GUI, label=bob->xterm, input=yes ) Init Core Slide 32 von 37

33 Outlook: Mapping to kernel caps Creation of a new service object: Creation of new service object and insertion into service object data structure Use policy data when creating service object, so that resource access by the service object can only be done in a defined fashion Mapping of send-capability to existing or new endpoint of the server by using the service object index as the badge Slide 33 von 37

34 DEMO Slide 34 von 37

35 Bastei Demo use Logging use use Window Framebuffer Window Manager Tutorial use Time Service Framebuffer Driver Launchpad Window Manager Input Driver uses Init use Core Log Slide 35 von 37

36 References Christian Helmuth and Norman Feske: 'Design of the Bastei OS Architecture' Tech. Report Rob Pike, Dave Presetto, Ken Thompson et al.: 'The use of name spaces in Plan 9' ACM SIGOPS Operating Systems Review Jerome H. Saltzer and Michael D. Schroeder: 'The Protection of Information in Computer Systems' Proceedings of the IEEE Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro: 'Capability Myths Demolished' Tech. Report Slide 36 von 37

37 Coming soon... Tomorrow: Paper reading: On micro-kernel construction by the godfather Jochen Liedtke Read and understand it Be prepared to summarize it Next weeks: Resource Management (4.12.) Virtualization ( ) Slide 37 von 37