naming - os.inf.tu-dresden.de

Faculty of Computer Science Institute for System Architecture, Operating Systems Group

Naming

Dresden, 2007-11-27

Stefan Kalkowski

TU Dresden, 2007-11-27 MOS- Naming Slide 2 von 37

So far...

• Basics:● Tasks and Threads● Synchronization● Memory● Communication

• Device Drivers

• Real-Time

• Today: Naming


Motivation

Naming is relevant for different abstractions:● Kernel objects● File systems● Networks● Programming languages● Hardware

... for different purposes:● Usability● Security


Today

● Naming● Terminology● Distributed name services● Global vs. local name spaces● Naming and access: Capabilities● Examples


Terminology: Names

Symbolic names:● textual representation of an entity

Address:● locates an entity

Identifiers:● identifies (uniquely) an entity of a system


Example: DNS

wikipedia

com org de

.

edu

kernel

de

URI: symbolic name and identifier gets resolved to IP address

= 145.97.39.155


More Terminology

Name space resp. context:● contains mappings of higher-level to lower-

level names or attributes (e.g.: symbolic name -> address, id, symbolic name)

Name resolution:● process of mapping

Name service:● activity that performs name resolution


Directory =Name space

Example: UNIX VFS

Inode 0 ('/')

links -> inode 1etc -> inode 2

Inode 1 ('/links')

fstab -> /etc/fstabbashrc -> inode 4

Inode 2 ('/etc')

fstab -> inode 5bashrc -> inode 4

Inode =Identifier

... ...


Example: UNIX VFS

[14:56:59] root@penurious:/ >> ls -dils

0 4 drwxr-xr-x 4 root root 4096 Sep 27 14:47 .

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

HARDLINK

SOFTLINK


Example: C++

namespace My_names{

class Example{

...}

}

// specify the name space explicitly My_names::Example obj();

// specify name space until block endsusing namespace std;cout << ”address of obj: ” << &obj;


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


Distributed name service

Example:

• Name: /a/b/c implemented by three name servers

• Name server one provides initial context

Name Space

Client

NameServer 1

NameServer 2

NameServer 3


Iterative name resolution I

• Client controlled iterative lookup

• Client repeatedly queries servers(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

Name Space

Client

NameServer 1

NameServer 2

NameServer 3

1

32


Iterative name resolution II

• Server controlled iterative lookup

• Initial name server repeatedly queries subsequent name servers(1)lookup(ns1,”/a/b/c”)(2)lookup(ns2,”/b/c”)

-> ns1: ns3,”/c”(3)lookup(ns3,”/c”)

-> ns1: file_id-> client: file_id Name Space

Client

NameServer 1

NameServer 2

NameServer 3

1

2 3


Recursive name resolution

• Server controlled recursive lookup

• Each name server queries subsequent name server(1)lookup(ns1,”/a/b/c”)

(2)lookup(ns2,”/b/c”)

(3)lookup(ns3,”/c”)-> ns2: file_id-> ns1: file_id-> client: file_id

Name Space

Client

NameServer 1

NameServer 2

NameServer 3

1

2

3


Distributed name service: L4VFS

• Part of the L4 Environment

• Provides a UNIX like hierarchical name space

• Distributed name service with object and name servers

• Object servers provide sub name spaces called volumes

• Name servers manage volumes and resolve names

Object serverExt2fs

Object serverTerminal

Name server

Backend

Application


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

• Object server● Maps names -> local object ids● Can manage different volumes● Keeps client’s state (seek pos.,

access mode, ...) Object serverExt2fs


Name server

Backend

Application


Root: 0.0

L4VFS: Mounting

• Mounting is completely done by name server• Mount table is checked for each step in

name resolution

Object serverExt2fs


Name server

Backend

Application

Mount point Volume0.3 3... ...

/0.0

dev0.1

etc0.2

tty10.3

conf0.4

tty13.0

tty24.0


Name server

Root: 0.0

Object server 2Object server 1

L4VFS: Resolution

• Request: /dev/input/mice -> 3.2

Mount point Volume0.3 3... ...

/0.0

dev0.1

etc0.2

input0.3

conf0.4

event3.1

mice3.2

resolve(0.0, 'dev')0.1

/3.0

resolve(0.1, 'input')0.3

resolve(3.0, 'mice')3.2


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


Principle of least privilege

“Every program and every user of the systemshould 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


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


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


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


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


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:

Alice ...R Resource

Access control list

Alice ...R Resource

Capability list


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


Capabilities to Endpoints

Client 1

Client 2

ServerKernel

endpoint

Make thread implementationdetails transparent

1208

1456

Badges

Objects


Terminal

Core

Init

GUIUser

Session

Capabilities in userland: Bastei

• Strict hierarchical structure

• Core provides basic services to provide system's resources

• Parent node acts as name server and 'reference monitor'

• Resource accounting for every service a node uses


Terminal

Core

Init

GUIUser

Session

Capabilities in userland: Bastei

• Tasks initially possess only a parent capability

• Child nodes query their parent for services/objects

• Child nodes can announce services at their parent

• Subsystem configuration can be implemented by creating new subtrees


Bastei: Service announcement

• Announcing services:

Core

Init

GUIroot

announce(”GUI”, root_cap)


Bastei: Open a session

• Using service:

Core

Init

GUI UserSession

Terminal

root

session(”GUI”, ”input=yes, label=xterm”)

session(”GUI”, ”label=bob->xterm, input=yes”)

session(”input=false, label=bob->xterm”)


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


DEMO


Bastei Demo

Core

Init

TimeService

FramebufferDriver

WindowManager

InputDriver

Launchpad

LoggingWindow

FramebufferWindowManager

Tutorial

Log

uses

use

use

use

use use


References

• Christian Helmuth and Norman Feske: 'Design of the Bastei OS Architecture' Tech. Report 2006 http://os.inf.tu-dresden.de/paper_ps/bastei_design.pdf

• Rob Pike, Dave Presetto, Ken Thompson et al.: 'The use of name spaces in Plan 9' ACM SIGOPS Operating Systems Review 1993 http://plan9.bell-labs.com/sys/doc/names.html

• Jerome H. Saltzer and Michael D. Schroeder: 'The Protection of Information in Computer Systems' Proceedings of the IEEE 1974 http://www.acsac.org/secshelf/papers/protection_information.pdf

• Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro: 'Capability Myths Demolished' Tech. Report 2003 http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf


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 (11.12. + 18.12.)

naming - os.inf.tu-dresden.de

Documents