Successfully reported this slideshow.

NeXTBSD aka FreeBSD X

32

Share

NeXTBSD
AKA FreeBSD X
Basic Architecture
FreeBSD-current kernel
+ Mach IPC
Common Object Runtime (create/delete/retain/release)
Libdispatch / AS...
Basic Architecture
FreeBSD-current kernel
+ Mach IPC
Common Object Runtime (create/delete/retain/release)
Libdispatch / AS...

YouTube videos are no longer supported on SlideShare

View original on YouTube

Upcoming SlideShare
Python on FreeBSD
Python on FreeBSD
Loading in …3
×
1 of 20
1 of 20

NeXTBSD aka FreeBSD X

32

Share

Download to read offline

During the August 2015 meeting, Jordan Hubbard and Kip Macy spoke about their upcoming initiatives on NeXTBSD.

A video of the talk can be seen at the end of the video or here: https://www.youtube.com/watch?v=49sPYHh473U

During the August 2015 meeting, Jordan Hubbard and Kip Macy spoke about their upcoming initiatives on NeXTBSD.

A video of the talk can be seen at the end of the video or here: https://www.youtube.com/watch?v=49sPYHh473U

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

NeXTBSD aka FreeBSD X

  1. 1. NeXTBSD AKA FreeBSD X
  2. 2. 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
  3. 3. 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
  4. 4. Introduction to Mach IPC A Sympathetic Glance
  5. 5. 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).
  6. 6. 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.
  7. 7. 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
  8. 8. 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
  9. 9. 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”
  10. 10. 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
  11. 11. • 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?
  12. 12. • 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
  13. 13. • 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?
  14. 14. • 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?
  15. 15. 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
  16. 16. • 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?
  17. 17. • 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!
  18. 18. 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
  19. 19. Q&A

×