Naming Device Drivers Stefan Kalkowski Real-Time Today: Naming - PowerPoint PPT Presentation

So far... Faculty of Computer Science Institute for System Architecture, Operating Systems Group • Basics: ● Tasks and Threads ● Synchronization ● Memory ● Communication Naming • Device Drivers Stefan Kalkowski • Real-Time • Today: Naming Dresden, 2007-11-27 TU Dresden, 2007-11-27 MOS- Naming Slide 2 von 37 Motivation Today ● Naming Naming is relevant for different abstractions: ● Kernel objects ● Terminology ● File systems ● Distributed name services ● Networks ● Global vs. local name spaces ● Programming languages ● Naming and access: Capabilities ● Hardware ● Examples ... for different purposes: ● Usability ● Security TU Dresden, 2007-11-27 MOS- Naming Slide 3 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 4 von 37

Terminology: Names Example: DNS Symbolic names: ● textual representation of an entity . Address: ● locates an entity com edu org de Identifiers: ● identifies (uniquely) an entity of a system kernel wikipedia = 145.97.39.155 de URI: symbolic name and identifier gets resolved to IP address TU Dresden, 2007-11-27 MOS- Naming Slide 5 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 6 von 37 More Terminology Example: UNIX VFS Name space resp. context : Directory = ● contains mappings of higher-level to lower- Inode 0 ('/') Name space level names or attributes (e.g.: symbolic name links -> inode 1 etc -> inode 2 -> address, id, symbolic name) Name resolution : ● process of mapping Inode 2 ('/etc') Inode 1 ('/links') fstab -> /etc/fstab fstab -> inode 5 Name service : bashrc -> inode 4 bashrc -> inode 4 ● activity that performs name resolution Inode = ... ... Identifier TU Dresden, 2007-11-27 MOS- Naming Slide 7 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 8 von 37

Example: UNIX VFS Example: C++ [14:56:59] root@penurious:/ >> ls -dils namespace My_names { SOFTLINK 0 4 drwxr-xr-x 4 root root 4096 Sep 27 14:47 . class Example 1 4 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 // specify the name space explicitly My_names::Example obj(); HARDLINK // specify name space until block ends using namespace std; cout << ”address of obj: ” << &obj; TU Dresden, 2007-11-27 MOS- Naming Slide 9 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 10 von 37 More Differentiation ... Distributed name service ● Name spaces can be organized: Example: ● flat or hierarchical • Name: /a/b/c Client ● global or local implemented by three ● Name services might be implemented name servers centralized or distributed • Name server one ● Resolving names can be done iterative or Name provides initial context Server 1 recursive Name Name Server 2 Server 3 Name Space TU Dresden, 2007-11-27 MOS- Naming Slide 11 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 12 von 37

Iterative name resolution I Iterative name resolution II • Client controlled • Server controlled iterative lookup iterative lookup Client Client • Client repeatedly • Initial name server queries servers repeatedly queries 1 1 subsequent name (1)lookup(ns1,”/a/b/c”) 2 3 -> client: ns2, /b/c servers Name Name (2)lookup(ns2,”/b/c”) Server 1 Server 1 (1)lookup(ns1,”/a/b/c”) 2 -> client: ns3, /c 3 (2)lookup(ns2,”/b/c”) (3)lookup(ns3,”/c”) Name Name -> ns1: ns3,”/c” Name Name -> client: file_id Server 2 Server 3 Server 2 Server 3 (3)lookup(ns3,”/c”) -> ns1: file_id Name Space -> client: file_id Name Space TU Dresden, 2007-11-27 MOS- Naming Slide 13 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 14 von 37 Recursive name resolution Distributed name service: L4VFS • Server controlled • Part of the L4 Environment Application recursive lookup • Provides a UNIX like Client Backend • Each name server hierarchical name space queries subsequent • Distributed name service 1 name server with object and name (1)lookup(ns1,”/a/b/c”) Name Name server servers Server 1 (2)lookup(ns2,”/b/c”) 2 • Object servers provide sub (3)lookup(ns3,”/c”) Name -> ns2: file_id Name name spaces called volumes Server 2 Server 3 -> ns1: file_id • Name servers manage -> client: file_id 3 Object server Object server Name Space Ext2fs Terminal volumes and resolve names TU Dresden, 2007-11-27 MOS- Naming Slide 15 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 16 von 37

Distributed name service: L4VFS L4VFS: Mounting • Name server • Mounting is completely done by name server Application Application Maps symbolic names -> object • Mount table is checked for each step in ● ids: (volume id).(local object id) Backend Backend name resolution Iteratively queries object servers ● to resolve names Mount point Volume Maps volume ids to object servers ● 0.3 3 Root: 0.0 Manages mount table ● Name server ... ... Name server • Object server Maps names -> local object ids / ● 0.0 Can manage different volumes ● Keeps client’s state (seek pos., dev etc ● tty1 tty2 Object server Object server 0.1 Object server Object server 0.2 access mode, ...) 3.0 4.0 Ext2fs Terminal Ext2fs Terminal tty1 conf 0.3 0.4 TU Dresden, 2007-11-27 MOS- Naming Slide 17 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 18 von 37 L4VFS: Resolution Local vs. global name spaces • Request: /dev/input/mice • Global name spaces: ● All instances share the same view -> 3.2 ● Classical in monolithic systems Name server Mount point Volume ● Easy to configure 0.3 3 Root: 0.0 ... ... • Local name spaces: 0.1 0.3 3.2 ● Instances have a private name space resolve(0.1, 'input') resolve(0.0, 'dev') resolve(3.0, 'mice') ● Forwards 'principle of least privilege' Object server 1 Object server 2 / ● Facilitates virtualization and debugging 0.0 / ● Development trend: FreeBSD's jails or chroot 3.0 dev etc 0.1 0.2 event mice input conf 3.1 3.2 0.3 0.4 TU Dresden, 2007-11-27 MOS- Naming Slide 19 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 20 von 37

Principle of least privilege Problems with global names • Example: L4 thread ids are globally visible ● Everyone can send IPC to everyone “Every program and every user of the system ● Services need to care of access control should operate using the least set of ● D enial o f S ervice attacks are possible privileges necessary to complete the job.” ● No full isolation (Saltzer and Schroeder) • Possible solution: Reference monitor ● General design principle to reduce ● Kernel uses a bitmap that contains vulnerabilities in software communication rights ● Local name spaces enable developers to put • Simpler solution: using local names this into practice TU Dresden, 2007-11-27 MOS- Naming Slide 21 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 22 von 37 Local names example: Plan 9 Local names example: Plan 9 • Developed by Bell Labs in • Services export file hierarchies the late 1980´s • Processes mount services they use into their • Distributed system, one UNIX own name space out of a lot of systems • Processes might inherit the name space of • Main features: their parent process ● All resources are named and accessed like files • In addition processes can use bind to duplicate ● Network protocol 9P for remote file access paths in the file hierarchy ● Per process, private hierarchical file name space TU Dresden, 2007-11-27 MOS- Naming Slide 23 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 24 von 37

Combine name and access Capability properties • Capabilities • Capability models differ: ● Designate a specific object (e.g.: kernel object) ● Originally: possession of a capability is and give certain access rights to that object sufficient to further delegate that capability ● Possession of a capability is sufficent to access -> complicates information flow control ● Today: most capability systems have separate the concerning object ● Can be implemented by using hardware privileges for capability propagation support, memory protection mechanisms or • Capabilities vs. A ccess C ontrol L ists: cryptography • Famous capability systems: ● KeyKOS, EROS, Coyotos R R Alice Alice ... Resource ... Resource ● Mach / GNU Hurd Access control list Capability list ● Amoeba TU Dresden, 2007-11-27 MOS- Naming Slide 25 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 26 von 37 Capabilities in practice Capabilities to Endpoints L4.Sec ( Florence ): Make thread implementation ● Local names in a task local capability space details transparent translate to capabilities Client 1 ● Capabilities reference kernel objects, especially Objects endpoints Server 1456 ● Capabilities can be obtained by creating an Kernel Badges object or by mapping endpoint Client 2 ● An additional identifier the badge is associated 1208 with each endpoint capability ● Badges enable the receiver to distinguish sender capabilities from each other TU Dresden, 2007-11-27 MOS- Naming Slide 27 von 37 TU Dresden, 2007-11-27 MOS- Naming Slide 28 von 37