nextbsd aka freebsd x

NeXTBSDAKA FreeBSD X

Basic ArchitectureFreeBSD-current kernel

+ Mach IPCCommon Object Runtime (create/delete/retain/release)

Libdispatch / ASL / Libnotify

launchd

launchctl legacy rc system cooperating daemons

jsonconfigfiles

Introduction to Mach IPCA 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




launchd


jsonconfigfiles

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”




launchd


jsonconfigfiles

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




launchd


jsonconfigfiles

• 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

https://github.com/kmacy/NextBSD

http://www.optimcloud.com/disc1.iso

nextbsd aka freebsd x

Software