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

▶
naming
SMART_READER_LITE
LIVE PREVIEW

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

Mar 26, 2023 227 likes •341 views

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

slide-1
SLIDE 1

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

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

Motivation

Naming is relevant for different abstractions:

  • Kernel objects
  • File systems
  • Networks
  • Programming languages
  • Hardware

... for different purposes:

  • Usability
  • Security

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

Today

  • Naming
  • Terminology
  • Distributed name services
  • Global vs. local name spaces
  • Naming and access: Capabilities
  • Examples
slide-2
SLIDE 2

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

Terminology: Names

Symbolic names:

  • textual representation of an entity

Address:

  • locates an entity

Identifiers:

  • identifies (uniquely) an entity of a system

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

Example: DNS

wikipedia com

  • rg

de . edu kernel de

URI: symbolic name and identifier gets resolved to IP address

= 145.97.39.155

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

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

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

Directory = Name space

Example: UNIX VFS

Inode 0 ('/')

links -> inode 1 etc -> inode 2

Inode 1 ('/links')

fstab

  • > /etc/fstab

bashrc -> inode 4

Inode 2 ('/etc')

fstab -> inode 5 bashrc -> inode 4

Inode = Identifier ... ...

slide-3
SLIDE 3

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

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

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

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;

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

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

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

Distributed name service

Example:

  • Name: /a/b/c

implemented by three name servers

  • Name server one

provides initial context

Name Space Client Name Server 1 Name Server 2 Name Server 3

slide-4
SLIDE 4

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

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 Name Server 1 Name Server 2 Name Server 3 1 3 2

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

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 Name Server 1 Name Server 2 Name Server 3 1 2 3

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

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 Name Server 1 Name Server 2 Name Server 3 1 2 3

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

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 server Ext2fs Object server Terminal Name server Backend Application

slide-5
SLIDE 5

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

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 server Ext2fs Object server Terminal Name server Backend Application

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

Root: 0.0

L4VFS: Mounting

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

name resolution

Object server Ext2fs Object server Terminal Name server Backend Application

Mount point Volume 0.3 3 ... ...

/ 0.0 dev 0.1 etc 0.2 tty1 0.3 conf 0.4 tty1 3.0 tty2 4.0

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

Name server Root: 0.0 Object server 2 Object server 1

L4VFS: Resolution

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

Mount point Volume 0.3 3 ... ...

/ 0.0 dev 0.1 etc 0.2 input 0.3 conf 0.4 event 3.1 mice 3.2

resolve(0.0, 'dev') 0.1

/ 3.0

resolve(0.1, 'input') 0.3 resolve(3.0, 'mice') 3.2

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

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-6
SLIDE 6

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

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

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

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

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

Local names example: Plan 9

  • Developed by Bell Labs in

the late 1980´s

  • Distributed system, one UNIX
  • ut 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

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

Local names example: Plan 9

  • Services export file hierarchies
  • Processes mount services they use into their
  • wn 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-7
SLIDE 7

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

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

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

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

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

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
  • bject 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

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

Capabilities to Endpoints

Client 1 Client 2 Server Kernel endpoint

Make thread implementation details transparent

1208 1456

Badges

Objects

slide-8
SLIDE 8

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

Terminal Core Init GUI User 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

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

Terminal Core Init GUI User 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

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

Bastei: Service announcement

  • Announcing services:

Core Init GUI

root

announce(”GUI”, root_cap)

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

Bastei: Open a session

  • Using service:

Core Init GUI User Session Terminal

root

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

slide-9
SLIDE 9

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

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

  • bject index as the badge

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

DEMO

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

Bastei Demo

Core Init Time Service Framebuffer Driver Window Manager Input Driver Launchpad Logging Window Framebuffer Window Manager Tutorial Log

uses use use use use use

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

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

slide-10
SLIDE 10

TU Dresden, 2007-11-27 MOS- Naming Slide 37 von 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 (11.12. + 18.12.)