NeXTBSD aka FreeBSD X

Basic Architecture
FreeBSD-current kernel
+ Mach IPC
Common Object Runtime (create/delete/retain/release)
Libdispatch / ASL / Libnotify
launchd
launchctl legacy rc system cooperating daemons
json
config
files

Introduction to Mach
IPC
A Sympathetic Glance

Mach Kernel Abstractions
• Tasks. The units of resource ownership; each task consists of a virtual address space, a port
right namespace, and one or more threads. (Implemented as an extension to a process.)
• Threads. The units of CPU execution within a task. Simple extension to kthreads.
• Address space. In conjunction with memory managers, Mach implements the notion of a
sparse virtual address space and shared memory. (No modifications)
• Memory objects. The internal units of memory management. Memory objects include named
entries and regions; they are representations of potentially persistent data that may be mapped
into address spaces. (Unsupported)
• Ports. Secure, simplex communication channels, accessible only via send and receive
capabilities (known as port rights).
• IPC. Message queues, remote procedure calls, notifications, semaphores, and lock sets.
(Mach semaphores and lock sets are not supported).
• Time. Clocks, timers, and waiting - (rudimentary shims).

What is a port?
• A port is an endpoint of a unidirectional communication channel between a client who requests
a service and a server who provides the service.
• If a reply is to be provided to such a service request, a second port must be used.
• Tasks have permissions to access ports in certain ways (send, receive, send-once); these are
called port rights.
• A port can be accessed only via a right. (Akin to a file descriptor).
• Port rights can be copied and moved between tasks via IPC. Doing so, in effect, passes
capabilities to some object or server.
• Ports and port rights do not have systemwide names that allow arbitrary ports or rights to be
manipulated directly.
• Ports can be manipulated by a task only if the task has a port right in its port namespace.
• A port right is specified by a port name, an integer index into a 32-bit port namespace. Each
task has associated with it a single port namespace.

What can Mach ports do that
Unix domain sockets can’t?
• Separate namespace for services (doesn’t rely on file system naming or permissions)
• Message boundaries
• Kernel as peer
• Pre-existing well defined RPC interface
• Receive messages directly in call to kevent()
• OOL (out of line) messages (arbitrarily sized with zero copy for large messages)
• Port send rights - can only send to a port for which the process has explicitly received
the right to send
• Provenance - Yes, PROVENANCE, receiver can have the kernel append an audit
trailer containing full set of credentials of sender

Common Runtime Benefits
• Internal objects in multi-threaded world to share some
common semantics (retain / release)
• Examples: dispatch_object_t, asl_object_t,
xpc_object_t, etc
• Provides a rendezvous point for higher-level languages
like ObjC and C++ (which also have objects they
would like to share across language boundaries)
• One reason why “this stuff can’t just be in ports”

• An intelligent thread pool (with optional
cooperative thread resource management
between multiple tasks)
• Task-parallelism made easy: Everything is a
queue, and queues can be arbitrarily nested
• Used by many other parts of the system (ASL,
notify, etc) and provides “common runloop for
unix processes” (this is actually a really big deal)
• Apache licensed and highly portable (Linux,
BSD, Windows, etc)
Libdispatch: What the hell is it?

• All objects use common runtime (so retain/release
controls object lifetimes and thread safety)
• Queues, sources, semaphores and groups
provide basic building blocks
• Data objects provide higher-level memory
management semantics for allocating / passing
and managing data between processes
• Way too much functionality to go into here; many
tutorials on the net, many thousands of OS X / iOS
apps using it
Libdispatch: Types of functionality

• Structured Log Output: Everything is a key/value
pair, and highly extensible
• Supports multi-threaded logging out of the box
• Unifies character encoding (UTF-8 everywhere),
event sources and post-processing plug-ins, etc.
etc.
• Can be used as a building-block for telemetry
and higher-level logging / debugging needs
ASL: What the hell is it?

• Global asynchronous event management system
(publish / subscribe)
• Supports many different “notification delivery”
methods (fds, mach ipc, signals, shared
memory)
• Cooperates nicely with libdispatch (events can
cause automatic enqueuing of handler
blocks/functions on queues)
• Very useful for light-weight cache invalidation
Libnotify: What the hell is it?

• A merger of init, mach_init (which FreeBSD never
had), [x]inetd, cron, and rc/rc.d
• Provides a clear chain of custody for all
processes and a single point of control for
security policy implementation and debugging
• Handles dependencies implicitly through
communication requests / events (both HW and
SW)
• Provides per system / session / application
service management for XPC (when present)
Launchd: What the hell is it?

• Launchd speaks XML fluently (and will force you to
as well)
• Launchd’s implementation is really complicated
• Launchd clubs UNIX’s “keep it simple” philosophy
like a baby harp seal
Launchd: Popular Myths
Hint: The world has changed!

Resources & Next Steps
• https://github.com/kmacy/NextBSD
• Fork of FreeBSD -current with all this stuff
added. Builds under FreeBSD 10.1 or later.
• Nightly builds coming soon, but for now
http://www.optimcloud.com/disc1.iso is
installable image
• Merging HardenedBSD work as well

NeXTBSD aka FreeBSD X

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à NeXTBSD aka FreeBSD X

Similaire à NeXTBSD aka FreeBSD X (20)

Plus de iXsystems

Plus de iXsystems (7)

Dernier

Dernier (20)

NeXTBSD aka FreeBSD X