XNU handbook: complete table of contents

Guide index · Reading guide

This is the reviewable Markdown handbook structure. Every Markdown page is listed below, with its main section headings where useful. Introductory guides establish the objects and vocabulary; the subsequent implementation chapters explain decisions, concurrency, ownership, errors and teardown. Build the local HTML book, including SVG diagrams, with python3 make_docs.py; see build and reading instructions.

Use the source index to navigate from a source file back to its explanations. Section links here target the Markdown headings; source excerpts retain checkout-relative references.

Regenerate with python3 docs-ai/tools/build_toc.py.

1. Orientation

• XNU source guide
• Architecture and object relationships
  • One kernel, several object models
  • The objects to learn first
  • Three routes from user space
  • Interfaces between subsystems
  • Platform and configuration are part of the design
• Source map
  • Top-level directories
  • Inside osfmk
  • Inside bsd
  • Generated interfaces and external boundaries
  • Search by question
• A practical route through XNU
  • Read an operation, then widen the boundary
  • Pass 1: learn the identities
  • Pass 2: follow one entry from user space
  • Pass 3: understand blocking before scheduler policy
  • Pass 4: translate a virtual address
  • Pass 5: follow a file descriptor into VFS or networking
  • Pass 6: learn IPC ownership and service boundaries
  • Pass 7: connect policy and hardware
  • A repeatable source-reading worksheet
  • Efficient searches
  • Use diagnostics and tests to check your model
  • Argument, identity and lifetime paths
  • Executable memory, synchronization and packet policy
  • Exec stacks, executable I/O and scheduler placement
  • IPsec interfaces, MPTCP and process inspection
• Vocabulary and object index
• Source-reference index

2. Key structures: allocation, access and lifetime

• Key structures: allocation, access and lifetime
• Structure layouts
  • Find a field and its offset
  • Choose the preprocessing configuration
  • Compare and reopen a selection
  • Scope and source evidence
• The process and its protected data
  • 1. Read the fields by role and protection
  • 2. One writable allocation contains both process and task
  • 3. proc_ro is a separate object with grouped fields
  • 4. Construct a writable template, then install it in the RO element
  • 5. Access paths supply different guarantees
  • 6. A concrete protected update: the exec identity version
  • 7. References, waiters and allocation holds end at different times
  • 8. Kernel bootstrap and corpses are explicit exceptions
  • 9. Scope and reading limits
• The task and its shared read-only data
  • 1. Writable task state and the protected companion
  • 2. One combined allocation, two structure addresses
  • 3. Constructing the task and attaching protected state
  • 4. Obtaining a task and reading its protected fields
  • 5. Updating writable fields and RO fields
  • 6. Logical termination, final task release and shared storage
  • 7. Worked access, mutation and lifetime example
  • 8. Source scope and limits
• Updating read-only process and task metadata
  • 1. The ordinary process/task pair shares one RO record
  • 2. Initialization also uses the update API
  • 3. Reads validate the relationship and then load normally
  • 4. Plain field copy: process identity version
  • 5. Atomic field update: task flags
  • 6. Object offsets, physical addresses and aperture addresses
  • 7. The mapping and mutation mechanisms differ by ARM64 backend
  • 8. Checked mutation leaves object synchronization with its callers
  • 9. Clearing a backlink and freeing the object are different operations
  • 10. Evidence limits
• The thread, its BSD extension and protected associations
  • 1. Three structures, two allocations and several additional resources
  • 2. Read the writable fields by their protocol
  • 3. Protected fields are links and reference holdings
  • 4. Construction has several publication boundaries
  • 5. Obtaining a pointer does not always obtain a reference
  • 6. Credential refresh updates protected pointers, not credential contents
  • 7. Exception actions demonstrate the limit of pointer protection
  • 8. A live reference does not make every thread operation admissible
  • 9. Termination removes operations before freeing storage
  • 10. Worked source-reading routes and boundaries
• Credentials: immutable identity and writable lifetime state
  • 1. Three representations with different storage
  • 2. Allocation creates a protected value and a writable companion
  • 3. Access validates storage only where the API says so
  • 4. Lifetime references and long-term holdings are separate counts
  • 5. Identity replacement changes the publication, not the old value
  • 6. Worked UID and group changes
  • 7. Thread identity has two independently held associations
  • 8. Retirement precedes storage reclamation
  • 9. Field access and synchronization checklist
  • Source scope and remaining boundaries
• MAC labels: owner pointers, policy slots and protected storage
  • 1. The label contains a pointer address and policy slots
  • 2. Allocation initializes the slot encoding through the RO API
  • 3. Validation does not acquire object lifetime
  • 4. Null is encoded, and slot writes are protected copies
  • 5. Credential labels use private construction and a diagnostic seal
  • 6. Worked owned label: lazy vnode publication and competing allocators
  • 7. Owned destruction clears the field; plain free does not
  • 8. Copying and policy dispatch are not raw structure cloning
  • 9. Reading a label call site
  • Source scope and remaining boundaries
• IPC spaces and entries: allocating, finding and retiring capabilities
  • 1. Three allocations, three meanings of ownership
  • 2. Read the current space fields, not the historical comments
  • 3. Construction and the two initial references
  • 4. Decode a name before following an entry pointer
  • 5. Reservation, initialization and publication
  • 6. Lookup: protect the table and revalidate the relationship
  • 7. Growth replaces the array without replacing the space
  • 8. Namespace death before final allocation release
  • 9. Source-reading checklist and limits
• IPC ports and kernel objects: storage, state and capability lifetime
  • 1. Start with the object header and its containing allocation
  • 2. Allocation initializes a locked object before publishing its right
  • 3. Field and accessor map
  • 4. Receiver state tells you which pointer exists
  • 5. Count rights, urefs and allocation references separately
  • 6. Kobject association has a separate type and lifetime contract
  • 7. Named access and transfer APIs return different things
  • 8. No senders, backup transfer and endpoint death are different events
  • 9. Final release frees storage after logical death
  • 10. Reviewed scope and boundaries
• VM maps, entries and the storage behind an address range
  • 1. The map is a container, an entry is a range record
  • 2. Map fields and their distinct contracts
  • 3. Allocation and initialization before publication
  • 4. Entry fields: backing, coordinates and policy
  • 5. Constructing, cloning and publishing an entry
  • 6. How a caller reaches a map and keeps it alive
  • 7. Two indexes, one set of entries
  • 8. Interlocks, entry locks and range contexts
  • 9. Clipping and coalescing with a worked offset example
  • 10. Submap pointers change the coordinate system
  • 11. Removal, deferred disposal and final map release
  • 12. Failure paths and source-reading walks
• VM objects and backing storage
  • The object is metadata, not its contents
  • Allocation and initialization: writable, aligned, initially empty
  • References, paging holds and activity holds are different ledgers
  • Pager association is an in-kernel pointer relationship
  • Follow offsets through resident, shadow and compressed backing
  • Cache membership, last unmap and termination
  • Source-reading checkpoints and limits
• VM pages and resident storage
  • Four different identities surround one resident page
  • Where descriptors come from
  • Packed links and physical-page accessors
  • Access protection follows the state being changed
  • Acquiring a page and publishing its resident identity
  • Lookup, busy waits and reassociation
  • Wiring, unmapping and freeing are different transitions
  • Configuration boundaries and reading route
• Pmap and ARM64 translation storage
  • 1. Start with the objects, not just the root address
  • 2. Object storage and table protection are different contracts
  • 3. Bootstrap and ordinary creation start from different storage
  • 4. Roots and subordinate tables have different allocators
  • 5. PTDs, reverse mappings and the addresses they recover
  • 6. Access safety has several independent layers
  • 7. Publishing a table and recovering from a competing creator
  • 8. ASIDs, nesting and ledger ownership extend the field map
  • 9. Mapping removal, table reclamation and final pmap release
  • 10. Follow a storage question to its implementation boundary
• Memory-entry capabilities and VM copy storage
  • 1. A named entry is a port-owned descriptor
  • 2. Allocation, construction and publication are separate steps
  • 3. Port access borrows the descriptor; mapping acquires backing
  • 4. Final send-right release does not remove existing mappings
  • 5. A VM copy has two representations and one active owner protocol
  • 6. Copy entries own backing but do not use live-map entry locks
  • 7. Buffer copies allocate bytes separately and publish only after copying
  • 8. Match the exact transfer API to its cleanup
  • 9. Source-reading checklist and limits
• File descriptor tables: storage, publication and reuse
  • 1. An embedded header owns two movable arrays
  • 2. Fields describe different kinds of state
  • 3. Header initialization is not array allocation
  • 4. Slot state determines whether a pointer is published
  • 5. Growth preserves indices, not array addresses
  • 6. Lookup, iteration and existing I/O holders
  • 7. Fork and exec construct different inherited views
  • 8. Close makes a number reusable before the endpoint necessarily dies
  • 9. Invalidate contents, then destroy locks, then release proc storage
  • 10. A reading route and the limits of this account
• Fileprocs and fileglobs: descriptor instances and shared open files
  • 1. The sharing graph has several independent lifetimes
  • 2. Ordinary writable zones and the constructor's extra hold
  • 3. Fileproc fields are descriptor-instance state
  • 4. Fileglob fields describe the shared open state
  • 5. Accessing endpoint data and selecting a callback
  • 6. A guard adds storage without changing the shared fileglob
  • 7. The reference ledger: I/O holds are not shared-file owners
  • 8. Shared offsets: a worked duplicate and independent-open example
  • 9. UNIX messages and fileports keep fileglobs without original slots
  • 10. Drain the fileproc, then drop the shared open file
  • 11. Reading an unfamiliar caller without conflating the objects
• Vnodes and vnode identity
  • 1. The allocation and the objects attached to it
  • 2. Reference counts, subsets and lifecycle flags
  • 3. Allocate storage, initialize identity, then publish it
  • 4. Recover a usable incarnation from a cached pointer
  • 5. An open file retains the vnode; each operation obtains active access
  • 6. Inactive, reclaim, dead state, reuse and storage release
  • 7. Reading limits and next structures
• UBC information and vnode pagers
  • 1. Four structures, several different kinds of ownership
  • 2. Construction publishes an association in stages
  • 3. The pager header identifies a provider, not a task-local port name
  • 4. Accessors borrow the association
  • 5. Credentials, prediction and writeback tracking own separate storage
  • 6. Mapping bits describe a shared epoch, not individual VM entries
  • 7. File-size updates change the validity boundary before VM cleanup
  • 8. The operation table crosses into filesystem callbacks
  • 9. Cached pages, UBC storage and open-file lifetime can end separately
  • 10. Reclaim disables VM backing before freeing the UBC allocation
  • 11. Source-reading route and boundaries
• Code-signature blobs and protected attachment storage
  • 1. The wrapper is in an RO zone; its pointees have separate contracts
  • 2. Allocate bytes, adopt them, then prepare the protected wrapper
  • 3. Storage transformations invalidate interior addresses
  • 4. PAC must match the eventual field address
  • 5. Publication transfers the candidate to UBC ownership
  • 6. Accessors return different kinds of results
  • 7. How an allowed write reaches RO storage
  • 8. Worked example: file coordinates and buffer coordinates
  • 9. Detach first, then release each owned resource
  • 10. Supplemental storage and source boundaries
• IPC kmsgs and message storage
  • 1. A fixed container with four storage layouts
  • 2. Allocation reserves capacity before it acquires rights
  • 3. Accessors depend on layout and representation
  • 4. Resource ownership changes in stages
  • 5. Queue handoff changes the owner, not the buffer layout
  • 6. Receiver conversion and deflation are different operations
  • 7. A Mach timer retains storage across separate messages
  • 8. Destroy resources, then release or retain storage
  • 9. Reading boundaries
• Sockets and protocol attachments
  • 1. One allocation, several separately owned associations
  • 2. A field and ownership map
  • 3. Protocol selection and attachment happen before external publication
  • 4. Descriptor access and kernel handles reach the same record differently
  • 5. Locking and references must be read together
  • 6. Listener queues publish children before accept publishes descriptors
  • 7. Upcalls have a separate close handshake
  • 8. Close, detach, buffer cleanup and final storage release
  • 9. Reading boundaries and next steps
• Socket buffers and record queues
  • 1. Embedded headers, separately allocated records
  • 2. Field groups and protection domains
  • 3. Reservation configures budgets; it does not preallocate payload
  • 4. Logical bytes and storage charges: a numeric example
  • 5. Append helpers differ in capacity checks and failure ownership
  • 6. Socket mutex, queue ownership and waiting are different operations
  • 7. Receive can borrow, copy, detach or transfer the same mbuf shape
  • 8. Drop and flush repair topology before releasing storage
  • 9. Filter-retained data and transport state are additional owners
  • 10. How to follow an unfamiliar queue mutation
• Internet PCBs and transport storage
  • 1. TCP allocates one aggregate, UDP and raw IP allocate a plain PCB
  • 2. Fields name network identity, memberships and separate state owners
  • 3. Allocation, protocol readiness and tuple publication are separate
  • 4. Wanted references protect the gap between table and socket locks
  • 5. Worked tuple lookup and reference ledger
  • 6. Timers and subordinate transport records have distinct owners
  • 7. Route references, interface associations and policy resources
  • 8. Close, detach and final aggregate release
  • 9. Configuration and source-reading boundaries
• Mbufs: packet views, shared clusters and external storage
  • 1. Separate the descriptor, its byte view and its backing
  • 2. Select the layout before doing storage arithmetic
  • 3. Allocation supplies one component or a reusable three-part bundle
  • 4. Access the current view, not an assumed payload address
  • 5. Shared clusters use a sticky software writability state
  • 6. Cloning data and transferring packet metadata are different operations
  • 7. Reshaping a chain can invalidate both the head and earlier views
  • 8. Attaching external bytes establishes a destructor contract
  • 9. Paired ring buffers have a second reference protocol
  • 10. Final release can free a descriptor while preserving its bytes
  • 11. Worked storage and reference ledger
  • 12. Reading checklist and implementation boundaries

3. Execution, scheduling, waits and timers

• Mach runtime: execution, scheduling, and synchronization
• Objects and lifecycle
  • Four objects to distinguish
  • Creating a task and its first thread
  • Suspension and execution control
  • Termination is staged
  • Lifetime and locking rules that matter when reading
• Suspension, stopping and aborting threads
  • 1. Entry points do not all require the same capability
  • 2. The counters form two levels of aggregation
  • 3. A hold requests APC; waiting observes the CPU boundary
  • 4. Legacy task suspension tracks hidden ordinary send rights
  • 5. Task suspend2 carries one hold in a send-once right
  • 6. PID suspension is a distinguished hold with policy and notifications
  • 7. Direct thread holds and the different thread token protocol
  • 8. Aborting a wait does not release a suspension
  • 9. Termination disconnects capabilities and wins over parking
  • 10. Configuration, tests and reading boundary
• From runnable thread to CPU execution
  • Common machinery and selected policy
  • A wake-to-run trace
  • Priority and QoS are several layers
  • Clutch: select a class, workload, then thread
  • Edge and alternate paths
• From runnable thread to executing context
  • 1. The state that must agree
  • 2. Waking is a state transition before it is placement
  • 3. Selecting includes deciding to keep the current thread
  • 4. Invocation: same thread, donated stack, or saved context
  • 5. What ARM64 installs
  • 6. Departure, quantum, and final termination
  • Inspection limits and a useful source walk
• ASTs: pending work, safe service points, and return-to-user control
  • 1. There are two pending masks, plus subsystem payloads
  • 2. Setting work and interrupting a remote CPU are separate actions
  • 3. Kernel service means eligible urgent preemption
  • 4. User-return dispatch consumes a snapshot, not the thread's entire future
  • 5. Assembly rechecks, PFZ deferral, and the eventual privilege transition
  • 6. Selected asynchronous workers have an explicit service loop
  • 7. Clearing a request and detaching its payload are different operations
  • 8. Three distinct ways a callback can block
  • 9. Restartable ranges: request delivery is not completion
  • 10. Exception records and reporting failures have their own ownership rules
  • Sources inspected and limits
• AST flavor reference: every bit and its consumer
  • 1. Active bits and service contracts
  • 2. Composite masks, zero, and historical holes
  • 3. Kevent payload: three reasons under one top-level bit
  • 4. Telemetry payload: five triggers and two context flags
  • 5. Kperf payload and unrelated uses of the word AST
  • 6. Inspection limits
• Priority, QoS, timeshare decay, and quantum expiration
  • 1. Keep requested policy, base priority, and scheduled priority distinct
  • 2. Effective QoS is recomputed before CPU priority
  • 3. From effective QoS to base priority
  • 4. Usage decay and promotion produce scheduled priority
  • 5. Clutch and dualq do not measure contention at the same scope
  • 6. Quantum size is policy input, not a fixed universal timeslice
  • 7. Nonurgent preemption requests get a bounded grace mechanism
  • 8. Excessive computation demotes mode and later restores it
  • Sources inspected and limits
• Realtime policy, deadlines, and processor-set runqueues
  • 1. Time-constraint parameters and what acceptance means
  • 2. Requested realtime mode can still be demoted
  • 3. A processing arrival establishes an absolute deadline
  • 4. The queue has both per-priority and global deadline metadata
  • 5. Default dequeue is conditional priority plus earliest deadline
  • 6. CPU placement and IPI dispatch are separate from dequeue order
  • 7. Edge stealing rechecks published candidates under the donor lock
  • 8. Queue shutdown and scope of the guarantees
• Work-interval policy and thread-group selection
  • One interval, several kinds of identity
  • Loading configuration and copying a selected phase
  • Assigning an interval's workload ID
  • Class, scheduling mode, and priority remain distinct
  • Resolving the group seen by the scheduler
  • A two-thread wakeup and propagation schedule
  • Unwind, remote demotion, and final release
  • Configuration and evidence limits
• Clutch hierarchy and Edge cluster placement
  • 1. Four objects that are easy to confuse
  • 2. Insertion establishes three different orderings
  • 3. Root selection: deadline, warp, and starvation window
  • 4. Thread-group interactivity and the final thread comparison
  • 5. Edge: selecting a cluster before selecting its CPU
  • 6. Stealing is a different search
  • Sources inspected and limits
• Thread-group accounting and cluster migration
  • Keep membership, runnable accounting, and queue placement separate
  • An explicit group change happens outside a run queue
  • Transfer the runnable contribution and finish old-group accounting
  • A placement update supplies preferences and two independent actions
  • Running members receive a request, not a direct transfer
  • Queued members pass through a temporary scheduler queue
  • Worked two-cluster schedule
  • Configuration, tests, and implementation boundaries
• CPU eligibility, SMT, and scheduler variants
  • 1. The scheduler implementation is selected at build time
  • 2. Available, online, recommended, idle, and bound are different states
  • 3. dualq makes the queue and preemption rules visible
  • 4. SMT constraints are checked at placement and selection
  • 5. Realtime CPU preferences allow explicit backup exceptions
  • 6. The alternate AMP scheduler has a narrower P/E model
  • 7. Recommendation updates move queued ownership before redispatch
  • 8. The recommended-core failsafe differs from thread demotion
  • Sources inspected and limits
• Waiting, locking, and priority inheritance
  • A wait is registration followed by scheduling
  • Mutex: fast acquisition, then adaptive wait
  • Turnstiles represent who must run to unblock someone
  • Reader/writer and spinning locks: inspect the actual variant
• Wait registration, mutex contention, and priority propagation
  • 1. Registering a wait does not immediately leave the CPU
  • 2. Detach first, make runnable second
  • 3. The mutex slow path is a retry loop
  • 4. Turnstile storage is donated, then recovered
  • 5. What priority propagates
  • 6. Changing the inheritor transfers references and queued updates
  • 7. Walking a chain while its members can wake
  • Review scope and reading exercises
• Reader-writer locks: admission, upgrades and wakeup lifetime
  • 1. The default type and the explicit new implementation
  • 2. Legacy state: intent and ownership are different
  • 3. Legacy shared and exclusive acquisition
  • 4. Legacy upgrades, downgrades and the lost-read-lock case
  • 5. Legacy release and destruction
  • 6. New RW state and why a failed read increment is not rolled back
  • 7. New contention: queued writer spinners and three typed waits
  • 8. New wakeup and storage lifetime after unlocking
  • 9. New conversion and spin-mode contracts
  • 10. RW counts, scheduler promotion and explicit condition sleeps
  • 11. Evidence, tests and remaining limits
• Ticket and pointer locks: spinning, reservations and publication
  • 1. Distinguish the primitive from the spin-lock wrapper
  • 2. Ticket allocation and the serving counter
  • 3. Waiting, ARM64 atomics and timeout policy
  • 4. Reserve, drop an outer lock, wait, then revalidate
  • 5. Invalidation and the ARM64 recoverable reservation
  • 6. PV ticket waiting is a different execution boundary
  • 7. Pointer packing and what the payload owns
  • 8. Pointer contention and the per-CPU MCS queue
  • 9. Release-XOR preserves a concurrently changing queue tail
  • 10. Waiting for a payload is not acquiring the pointer lock
  • 11. Worked client: scalable SMR hash mutation and migration
  • 12. Evidence and limits
• Time, deferred work, and resource attribution
  • Reading the time and accounting paths
  • Timer calls and thread calls
  • Measurement, limits, and attribution are separate jobs
  • Work intervals and vouchers connect work to scheduling
• ARM64 clocks, calendar time, and the commpage
  • 1. Choose the time domain before doing arithmetic
  • 2. From the counter to absolute time
  • 3. Continuous time and sleep reconciliation
  • 4. Calendar state, NTP scaling, and deliberate clock steps
  • 5. A commpage snapshot is a publication protocol
  • 6. Deadlines, configuration, and tests
• Timers and thread calls: execution, cancellation, and lifetime
  • 1. Low-level timer state and deadline selection
  • 2. Opposite lock order without blocking the expiry scanner
  • 3. The thread wait timer is a concrete teardown protocol
  • 4. Thread-call groups and object state
  • 5. Enter, delayed expiry, and the meaning of ONCE
  • 6. Worker execution and blocked-worker compensation
  • 7. Cancellation API behavior is branch-dependent
  • 8. Freeing storage and shutting down the callback's owner
  • 9. SIGNAL and continuous-time boundaries
  • Sources inspected and limits
• Recount tracks, execution snapshots, and resource attribution
  • 1. Objects and where their counters live
  • 2. A context switch attributes a delta to the outgoing thread
  • 3. User/kernel transitions and metrics with different producers
  • 4. What a consistent read guarantees
  • 5. Thread exit, task exit, and coalition totals
  • 6. Work-interval ownership and telemetry
  • 7. Allocation, configuration, and validation boundaries
• Ledger balances, per-CPU settlement, and limit enforcement
  • 1. Templates select representation and behavior
  • 2. Direct updates versus an open per-CPU tab
  • 3. Opening, flushing, and remote acknowledgements
  • 4. A concrete delayed-balance example
  • 5. Limits, refill, and publication of AST work
  • 6. Ownership and configuration boundaries

4. Virtual memory, hardware mappings and allocators

• Virtual memory and kernel allocation
• Memory mapping from API request to CPU access
  • 1. Allocate anonymous memory, then write one byte
  • 2. Map file contents, then compare private and shared writes
  • 3. Share or copy a range across address spaces
  • 4. Change protection, remove a range, or reclaim a page
  • 5. Kernel RAM, a physical aperture, and device memory
  • What to track while following a real address
• Maps and faults: a reading guide
  • Follow one virtual address
  • Know the five principal structures
  • Read the paths in this order
  • Current-checkout details that change the reading strategy
  • Sources inspected and limits
• Virtual address maps: intervals, ownership, locking, and mutation
  • The map and entry layouts
  • Lookup, holes, and entry clipping
  • Range locks stabilize operations beyond the interlock
  • API entry points and sanitization
  • Insertion and fixed-address replacement
  • Submaps and pmap nesting
  • Protection changes are coordinated with future faults
  • Fork and inheritance
  • Remap separates extraction from installation
  • Removal, deferred release, and teardown
  • Sources inspected and limits
• VM API arguments: arithmetic, compatibility and map authority
  • 1. Follow three separate decisions at the API boundary
  • 2. Unsafe types preserve the obligation to validate
  • 3. Canonicalization retains the original extent
  • 4. Address validation checks addition and page rounding separately
  • 5. Zero size controls whether the caller continues
  • 6. Protection syntax and compatibility can transform the request
  • 7. Error compatibility separates reporting from behavior
  • 8. Fixed allocation connects validation to output publication
  • 9. Checked arithmetic does not authorize the map operation
  • 10. Source tests and reviewed boundaries
• Executable memory: mapping admission, protection changes, and ARM64 faults
  • Keep the representations separate
  • MAP_JIT admission precedes entry publication
  • Common mobile policy and the macOS branch
  • mprotect changes map policy before hardware permissions catch up
  • Association records how executable pages should be admitted
  • A fault turns entry policy into a page mapping
  • Worked 16 KiB scenarios
  • Fork, copying and remapping preserve different things
  • Tests as source evidence and remaining boundaries
• VM objects and physical pages
  • The object is an offset namespace with backing policy
  • Allocation creates bookkeeping before contents
  • Resident-page identity and lookup
  • Ordinary references and I/O holds protect different things
  • Shadows and copy strategies
  • Delayed copies preserve snapshots by pushing old contents upward
  • Collapse and bypass: remove a level without changing visible contents
  • Last-reference teardown can outlive the last mapping
  • From resident page to reusable physical memory
  • Sources inspected and limits
  • Termination retries, pager disconnection and accounting order
• MTE tag storage and the physical-page lifecycle
  • What MTE checks, and what XNU must preserve
  • 1. Separate the data page, its tags and the backing page
  • 2. Cells, queues and memory classes answer different questions
  • 3. Boot creates metadata before publishing usable backing
  • Process enablement and hardware checking are separate state
  • From a user allocation request to the first tagged access
  • Provenance, aliases and copies preserve the mitigation's boundary
  • 4. A tagged allocation reserves accounting before changing pmap state
  • 5. Activation changes frame ownership before publishing ACTIVE
  • 6. Borrowing backing for ordinary contents and reclaiming it
  • 7. The fill worker balances taggable capacity and ordinary reuse
  • 8. Compressing tags differs from borrowing backing for the compressor
  • How kernel allocators turn tag checking into allocation-lifetime checks
  • Tag-check faults: enforcement, recovery and attribution
  • 9. Configuration and verification boundaries
• Fault resolution: from an address to a usable translation
  • Inputs and state carried through the fault
  • Page size is not one number
  • Stabilize the mapping and check permissions
  • Fast paths are several distinct algorithms
  • Slow faults release and revalidate the mapping
  • The common handoff to pmap
  • Page-table shortage requires a full retry
  • Resilient mappings: recover selected missing contents without changing the file
  • Completion and failures preserve ownership
  • Sources inspected and limits
• ARM64 pmap: address spaces, page tables, and reverse mappings
  • The objects behind one translation
  • Page size is a property of several different layers
  • What the PTE actually encodes
  • Physical-page metadata and the reverse walk
  • Creating an address space and its root
  • Nested pmaps and ASIDs describe different sharing
  • Reading route and limits
• Pmap fundamentals through concrete address translations
  • 1. Keep the virtual range, table storage, and data page separate
  • 2. Select the geometry before dividing an address
  • 3. Walk one address using 4 KiB pages
  • 4. Walk the same address using 16 KiB pages, then include L0
  • 5. Decode a complete PTE example
  • 6. Turn an absent translation into the tables shown above
  • 7. Protect, remove, and disconnect the same example
  • 8. Finish the change before using or reusing the address
  • Inspection scope and reproducible reading checks
• ARM64 mapping lifecycle: enter, restrict, disconnect, reclaim
  • The contract at the VM boundary
  • SPTM enter is a retryable transaction
  • The legacy commit uses a pmap lock and PTE compare-exchange
  • Allocate, initialize, then publish a table
  • Restricting a range is different from disconnecting a page
  • Why removing the last PTE does not immediately free its table
  • Legacy reclaim can deliberately discard live translations
  • Referenced/modified tracking and fast faults
  • Locking rules that make these paths fit together
  • Sources inspected and limits
• ARM64 TLB, cache, and root-switch completion
  • Publication, invalidation, and completion are different boundaries
  • Choosing the translation entries to invalidate
  • Break-before-make and table lifetime
  • Activating a pmap and reusing an ASID
  • SPTM normally owns PTE maintenance, but XNU still has explicit flush paths
  • Physical addresses, aperture aliases, and translation queries
  • Cache type changes and instruction visibility
  • Reading and verification boundaries
• x86_64 pmap: tables, reverse mappings, PCIDs, and invalidation
  • 1. The pmap has roots, table-page owners, and per-CPU identity
  • 2. Decode a virtual address using this checkout's geometry
  • 3. A PTE combines hardware state with software metadata
  • 4. Missing tables are allocated outside the insertion lock
  • 5. Insert or replace one mapping
  • 6. Reverse mappings support operations starting from a physical page
  • 7. Activation uses per-CPU PCIDs and two root views
  • 8. TLB invalidation is a distributed completion protocol
  • 9. Shared hierarchy and EPT are separate features
  • Reading route and limits
• Wiring, memory entries, and VM transfers
  • What wiring holds
  • Wiring is a three-stage operation in this checkout
  • A named memory entry is an IPC capability with bounded contents
  • Mapping a handle does not transfer its pmap
  • The two current vm_map_copy representations
  • Copyout and failure ownership
  • Sources inspected and limits
• Copy-overwrite, remapping and mixed page sizes
  • 1. Entry points select the maps and the ownership contract
  • 2. Overwrite admission is checked while streaming the destination
  • 3. Alignment permits an optimization; it does not guarantee substitution
  • 4. Physical copying must revalidate after faulting
  • 5. Head, middle and tail have separate progress
  • 6. Kernel-buffer overwrite follows copyio instead
  • 7. Remap extracts owned views before reserving the target
  • 8. Target adjustment reconciles interval and object geometry
  • 9. Immediate repacking has a narrower implementation and failure boundary
  • 10. Destination installation and output publication
  • 11. Tests identify invariants, not results of this documentation work
• Pagers, UBC, and page ownership during I/O
  • The pager boundary is an object interface
  • How a file becomes VM backing
  • A missing file page: demand, cluster, filesystem, completion
  • What a UPL owns and what its page list means
  • Creating the UBC UPL
  • Commit, abort and deallocate are separate operations
  • Dirty file pages travel back through the vnode
  • Map-based UPL creation
  • Device backing and I/O-wired UPLs
  • Sources inspected and limits
• UPL gathering, partial completion, and vector ownership
  • The state that must survive a lock drop
  • Entry: choose contents before collecting physical pages
  • Resident fast paths and the general fault loop
  • Why an I/O-wired UPL can contain pages with wire count zero
  • Delayed work, executable pages, and failure after progress
  • Explicit access blocking is a separate protocol
  • Partial completion: bytes select pages, bits record remaining ownership
  • A vector joins completion coordinates, not VM objects
  • Vector completion can finish one child before failing on the next
  • Source tests and remaining boundaries
• Executable pages and UPL I/O: permission, copies, and backing lifetime
  • 1. I/O direction and CPU permission describe different operations
  • 2. The entry predicates choose rejection, direct gathering, or copying
  • 3. Range preparation happens before the copy decision
  • 4. The copied path changes backing after releasing source protection
  • 5. Worked 16 KiB example: the first byte moves to offset zero
  • 6. Removing the temporary mapping does not finish the UPL
  • 7. Physical-page checks cover more than the original entry
  • 8. Return values, retries, and partial progress
  • 9. Source tests and the remaining implementation boundary
• Shared regions and transforming pagers
  • Region identity and task association
  • Exec reserves a placeholder; the check path installs the submap
  • Installing files and sealing the region
  • Shared-region pager and dyld pager serve different transformations
  • One fault transforms a destination page
  • References outlive mappings in different ways
• Reclamation, compression, swap, and process memory policy
  • Several forms of memory shortage
  • Replacement queues and decisions
  • Anonymous contents become compressor slots
  • Swap stores compressor backing through VFS
  • BSD memorystatus: process-level decisions
  • Freezing preserves selected process contents
• Compressor segments, compaction and swapfile lifetime
  • Three coordinates, with back-pointers for relocation
  • Allocating and filling a segment
  • Queue state, locks and busy ownership
  • Minor compaction changes slots inside one segment
  • Major compaction moves content between segments
  • Compactor, swapout, creation and GC are separate workers
  • Creating and retiring a swapfile
  • Configuration and evidence limits
• Deferred reclamation: the shared ring and task lifetime
  • Two representations and three kinds of protection
  • Allocating and publishing the ring
  • Producer publication and cancellation are present in libsyscall
  • Kernel reservation, wrapped copies and partial progress
  • Gate ownership, sampling and callers
  • Resize, fork, task death and errors
• Purgeable objects, aging tokens and owner accounting
  • Admission happens before the object state transition
  • Content state and lifetime are separate
  • Queues, groups and token age
  • Selecting an object without reversing lock order
  • Purging resident and compressed backing
  • Owner ledgers and final teardown
• Phantom cache: recording eviction and measuring refaults
  • History entries have object identity and a small page bitmap
  • Insertion and refault update hold both relevant locks
  • Sampling detects repeated turnover, not just high read volume
  • ARM64 configuration boundary and policy effect
• Memorystatus selection, freezing, and recovery
  • 1. State is spread across a process, a task, and VM
  • 2. A wakeup is a hint to reevaluate, not a selected victim
  • 3. Selecting a kill candidate requires reference acquisition and restart
  • 4. The freezer selects candidates under two levels of policy
  • 5. Freeze reserves a process but releases the global process-list lock
  • 6. Task serialization and map evaluation protect different things
  • 7. Object freezing keeps busy/activity ownership across compression
  • 8. Packing completion, disk completion, and counters are different
  • 9. Resume and demotion preserve backing until it is actually needed
  • Sources inspected and limits
• Kernel allocation: mechanisms, type isolation, and lifetimes
  • Detailed reading route
  • What type isolation means here
  • The structures to keep open while reading
  • Follow one allocation and its release
  • Flags and API variants change the contract
  • Inspecting the implementation in a matching kernel
  • Scope and verification
• Zone allocator: identity, caches, expansion, and reclamation
  • 1. The structures and the three meanings of “free”
  • 2. Creation fixes geometry and isolation policy
  • 3. VA regions and out-of-line metadata
  • 4. Allocation: CPU magazines first, central slots second
  • 5. Growing a zone without holding its lock across VM waits
  • 6. Free, validation, and when an empty page really exists
  • 7. Trimming, draining, and destruction
  • 8. Concurrency map and reading route
  • Sources inspected and limits
• Kalloc heaps: size classes, routing, free, and realloc
  • The heap object is a routing and accounting view
  • Size classes: two tables serve different purposes
  • Runtime allocation: resolve the view, then choose storage
  • Large allocations preserve category and placement inputs
  • Free validates storage identity before returning it
  • Realloc is a decision tree with ownership consequences
  • Encoded arrays carry capacity separately from ordinary pointers
  • Sources and boundaries
• Typed allocation: from C layouts to zones and VM ranges
  • 1. A source expression emits a metadata record
  • 2. What the compiler signature classifies
  • 3. Startup discovers and transforms the records
  • 4. Fixed allocations: size classes, layout groups, and a finite zone budget
  • 5. Variable allocations: whole heap families and special classes
  • 6. Runtime selection and the shared initial-allocation phase
  • 7. Large allocations: signatures become a limited placement hint
  • 8. Freeing verifies allocator relationships, not nominal C identity
  • 9. What the isolation provides, and where sharing remains
  • 10. Reading and verification route
• Kernel virtual allocation: placement, guard objects, and page ownership
  • The allocation contract has three independent axes
  • Kernel virtual ranges and type-derived placement
  • Guard objects are a map-store allocation scheme
  • A populated allocation, from page request to published address
  • Population owns references across pmap calls
  • Freeing validates allocation identity before releasing mappings
  • Reallocation transfers backing ownership
  • Submaps and boundaries of this implementation
  • Reading route and inspection limits
• Read-only and special zones: mutation and lifetime contracts
  • 1. Read-only zone registration and geometry
  • 2. Mutation is checked at two different layers
  • 3. Atomic updates and read-only free
  • 4. SMR zones delay cleanup, not just physical page reclamation
  • 5. Per-CPU allocations represent multiple instances
  • 6. Permanent allocations bypass the free-list lifecycle
  • 7. Exhaustible zones
  • 8. Callback-backed object caches: zcache
  • Sources inspected and limits
• Allocator interfaces and protected-memory categories
  • IOKit byte and typed allocation
  • C++ classes provide type views through generated operators
  • Aligned allocation can reserve extra storage around the payload
  • Physically constrained and pageable IOKit allocations
  • BSD compatibility interfaces do not create a malloc type heap
  • Kernel-extension image allocation uses a map constraint
  • Mapping restrictions are a separate layer of isolation
  • Sources and limits

5. Processes, signals, descriptors and event servicing

• BSD processes and the POSIX interface
• Process objects and lifetime
  • Four objects, distinct responsibilities
  • Credentials and references
  • Fork and spawn
  • Exec replaces the proc/task pair
  • Exit, zombie, and reap
• Fork, spawn, exec, exit, and wait
  • 1. Four forms of exclusion
  • 2. Fork: build first, release the child last
  • 3. Spawn: mutate the child before activating its image
  • 4. Exec: replace the proc/task pair while preserving identity
  • 5. Exec failure has a point of no return
  • 6. Exit ownership precedes resource teardown
  • 7. Wait consumes status, then reaping releases the identity
  • Inspection scope
• Exec identity and inherited state
  • 1. The process being changed is explicit
  • 2. File actions and permission checks precede the transition
  • 3. The ordered UID/group predicate controls the exception
  • 4. Credential updates preserve real IDs and publish replacements
  • 5. MAC transition, disjointness, and IPC inheritance are separate results
  • 6. Reset revokes selected access to the target objects
  • 7. Standard-descriptor repair is an attempted, fallible operation
  • 8. Every completed helper tail advances identity and refreshes tokens
  • 9. Identity preparation precedes final publication and launch approval
  • 10. Configuration and evidence boundaries
• Exec arguments and the initial user stack
  • 1. Extract from the caller before writing into the target
  • 2. One cached allocation carries strings, scratch space and image bytes
  • 3. A script changes both the lookup path and the argument sequence
  • 4. Source pointer width and destination pointer width have separate jobs
  • 5. Stack allocation supplies a top, an extent and a no-access region
  • 6. The Apple vector contains metadata and a published port name
  • 7. Copyout rebuilds pointers from offsets
  • 8. Worked ARM64 stack layout
  • 9. Saved SP and PC are installed separately
  • 10. Failure preserves the stage's actual progress
  • 11. Evidence and limits
• System calls, signals, and exceptions
  • The syscall table is generated
  • A concrete ARM64 call path
  • Where signal state lives
  • Mach exceptions become signals through a real IPC boundary
• Signal posting, handler entry, and sigreturn
  • 1. State is split between the proc and uthread
  • 2. Posting chooses an action and a thread
  • 3. AST processing decides what can be delivered now
  • 4. ARM64 sendsig builds a user-owned frame
  • 5. sigreturn validates and restores a requested continuation
  • 6. Exec and cancellation alter the signal environment
  • Inspection scope
• File descriptors: allocation, replacement and close
  • Three levels of identity
  • A slot can be occupied without being available
  • Allocation and table growth recheck after sleeping
  • Duplication preserves the open file and replaces descriptor state
  • Reference and close protocol
  • Guards constrain operations on the descriptor instance
  • Following a read
  • Pipes and transferred file references
  • Other local communication entry points
  • Configuration, source tests and inspection boundary
• Process inspection, identities and descriptor snapshots
  • 1. A syscall selector chooses another interface
  • 2. Resolve a process, then ask which identity was found
  • 3. Identity checks and access checks answer different questions
  • 4. Descriptor listing returns numbers and types
  • 5. Typed detail retains the object it actually finds
  • 6. Worked list-then-detail operation with concurrent changes
  • 7. Fileport detail uses a different namespace and lifetime
  • 8. Failure, output and release boundaries
  • 9. Evidence and limits
• Pipes, UNIX sockets and queued file rights
  • Pipe endpoints and publication
  • Byte storage, atomic writes and fault boundaries
  • Close is a draining operation
  • UNIX socket data and backpressure
  • Why reference counting needs a collector
• User-address waits, unfair locks and turnstiles
  • The address is a lookup key, not a kernel lock pointer
  • Compare and queue without losing the wake
  • Wake selection and owner handoff
  • Completion and last-waiter teardown
• POSIX named semaphores and shared memory
  • Named semaphore objects and creation
  • Wait/post and the reference held across sleep
  • Shared-memory names and backing entries
  • Mapping one object into two processes
  • Unlink, close and mappings that remain
• System V IPC: queues, semaphore vectors and shared segments
  • IDs contain both a slot and a generation
  • Message send reserves before publishing
  • Receive can consume a message even if copyout fails
  • A semaphore request is a vector
  • Shared segments and attachments
• TTY queues, PTY endpoints and job control
  • State and dispatch
  • Input processing and canonical records
  • Noncanonical completion and output pressure
  • Session and foreground group decisions
  • Sleep, hangup and final release
• Events, pthreads, and workqueues
  • Kevent registers interests; knotes remember them
  • Three queue implementations
  • Source locks and queue locks
  • Pthread implementation boundary
  • How work reaches a servicing thread
• Kqueue, knote, and workloop lifetimes
  • 1. A knote belongs to three structures
  • 2. Registration publishes identity before attaching the filter
  • 3. Posting runs under the source object's contract
  • 4. Delivery revalidates and changes future behavior
  • 5. Close and drop must detach before releasing storage
  • 6. Dynamic workloop IDs are names, not permanent ownership
  • 7. Owner, servicer, request, and turnstile are different roles
  • Inspection scope
• Pthread boundaries, workqueue service, and cancellation
  • 1. The pthread function table is an implementation boundary
  • 2. A process workqueue tracks demand and workers separately
  • 3. There are two main sources of service demand
  • 4. Admission is more than counting idle threads
  • 5. A creator carries demand into the scheduler
  • 6. Selecting, binding, and entering userspace
  • 7. Return and parking are race-sensitive handshakes
  • 8. Cancellation requests interruption; pthread performs user cleanup
  • 9. Thread termination and process exit release different owners
  • Inspection scope
• Asynchronous file I/O and teardown
  • Request state and ownership
  • Submission validates the request, then publishes work
  • Two worker implementations are present
  • Completion and cancellation coordinate with process exit
  • Cancellation is a queue-removal race
  • Close, exec, and exit wait for different completion conditions
  • Inspection limits

6. Mach IPC and exception delivery

• Mach IPC: names, capabilities, messages, and kernel interfaces
• Port names, namespace entries, and references
  • 1. Read the current structures before reading old Mach descriptions
  • 2. A name combines a slot index with a finite generation
  • 3. Rights, user references, and object references count different things
  • 4. Lookup stabilizes a relationship; it does not always acquire ownership
  • 5. Growing a live namespace
  • 6. Exhaustion, termination and the caller's lock state
  • Sources inspected and boundaries
• Port and right lifecycle
  • 1. Where a public operation becomes a kernel right operation
  • 2. Allocation creates a receive endpoint before it creates send authority
  • 3. Dispositions describe the source operation
  • 4. Insertion and extraction expose the same transfer machinery
  • 5. Deallocate, modify, and destroy have different scopes
  • 6. The receive right can leave every task namespace
  • 7. Port death and dead names are separate updates
  • 8. Notifications carry capabilities, accounting snapshots, or names
  • 9. Space teardown and concurrency boundaries
  • Sources inspected and limits
• Port sets, membership and persistent readiness
  • 1. Three different relationships: right, membership and message
  • 2. One two-way link per membership
  • 3. Membership APIs and their lock contracts
  • 4. Sending: identify a receiver or retain readiness
  • 5. Receiving: lock a member, revalidate, then consume
  • 6. Kqueue observes readiness through another attachment
  • 7. Removing membership, moving a receiver and destroying a set
  • 8. Evidence, tests and limits
• A message from userspace to its receiver
  • The stages and the actual delivery point
  • What is in a message
  • From libsyscall to the ARM64 trap
  • The trap's two operations
  • A request/reply exchange without confusing the names
  • Where to continue and what was inspected
  • Trailer layout at receive time
• Message ownership, queueing, and receive conversion
  • 1. Allocate storage before acquiring message resources
  • 2. Inflate bytes, then acquire rights and VM objects
  • 3. Check the destination and choose dispatch or queueing
  • 4. Reserve capacity, then post the message
  • 5. Receive from a port or a set of ports
  • 6. Convert the selected message into the receiver's namespace
  • 7. Errors tell you which resources moved
  • Source route and limits
  • Destruction cascades use a per-thread reaping queue
• Complex messages: aliasing, memory transfer and partial copyout
  • 1. A message has three representations and several owners
  • 2. Header aliasing needs a coordinated right operation
  • 3. OOL memory crosses through an owned VM copy
  • 4. An OOL port array has two different partial-progress boundaries
  • 5. Header copyout reserves capacity, then reconciles port lifetime
  • 6. Receiver resource installation precedes message-byte delivery
  • 7. Failed-send compensation has its own reply and error rules
  • 8. Review failure by stage, not just by the return-code family
• Message integrity and descriptor authentication
  • 1. What is signed, and which representation is being signed?
  • 2. Signing happens before body conversion finishes
  • 3. Validation returns the count that was checked
  • 4. Copying a kernel message requires pointer relocation
  • 5. Representation summary and review limits
• Synchronous IPC dependencies and special reply ports
  • The objects in one request and reply
  • Establishing the destination link
  • State determines which union member may be used
  • Event-driven receipt transfers the scheduling dependency
  • Reset, interruption and port death
  • A worked RPC and its independent checks
• Kernel RPC, MIG, and exceptions
  • A Mach trap and a Mach RPC are different entry routes
  • The destination selects an object; the message ID selects an operation
  • MIG supplies the typed boundary
  • Request/reply ownership is part of the server ABI
  • Task/thread capabilities and lifetime
  • Exceptions are kernel-initiated message exchanges
• From an ARM fault to a Mach exception reply
  • The objects at each stage
  • Installing a handler stores send rights, not a callback address
  • A concrete unresolved user memory fault
  • Snapshot the action before making a blocking RPC
  • Behavior determines the actual message contract
  • The faulting thread becomes the IPC client
  • The default Unix handler is a kernel kobject in this tree
  • A successful state reply does not immediately load hardware registers
  • Failures and limits to keep in the trace
• Port policy and work attribution
  • Several independent properties constrain a right
  • Reply ports and special ports
  • Vouchers carry managed attributes
  • Importance and turnstiles have different jobs
• Guards, port types, and policy enforcement
  • 1. A port type supplies policy; state supplies the current restriction
  • 2. Guard installation and context access are distinct interfaces
  • 3. Destruction and movement do not all test guards the same way
  • 4. A guard exception is a deferred report with policy-dependent consequences
  • 5. Reply type checks and persona context protect different boundaries
  • 6. Notification policy is separate from notification ownership
  • Sources inspected and limits
  • Copyout labels can substitute the capability
  • Strict reply: a consumed check, with two independent voucher locations
• Vouchers, attribute caches, and importance inheritance
  • 1. Four objects and four kinds of count
  • 2. Construction is a transaction over recipes
  • 3. Voucher ports donate one object reference to no-senders
  • 4. The last cached reference cannot simply free a handle
  • 5. Send, receive, and thread adoption are separate transitions
  • 6. Importance begins with a message link and a port assertion
  • 7. Receive transfers the relationship, then cleanup balances it
  • Sources inspected and limits
• Importance propagation, port migration and delayed policy drops
  • 1. Five forms of state must stay separate
  • 2. Sending establishes a live edge, even before it carries a boost
  • 3. Propagation updates each edge, then follows only changed tasks
  • 4. A receive right in transit extends the port path
  • 5. Applying policy without reversing task/importance lock order
  • 6. Hysteresis delays policy withdrawal, not graph accounting
  • 7. Releasing work and disconnecting a task do not erase the same graph
  • Review boundary
• Bank accounts, voucher adoption, and execution charging
  • 1. Objects and the four task roles
  • 2. Creating a bank-task context and an account
  • 3. Send, receive, and explicit redemption change different roles
  • 4. Made counts are not storage references
  • 5. Adoption keeps the bill alive through the old charge
  • 6. Splitting a quantum across adopted bills
  • 7. Live reports and final bill rollup
  • 8. Task detachment, configuration, and remaining boundaries
• Mach semaphores and eventlink signal/wait
  • 1. The interface and object models
  • 2. Constructing and obtaining a semaphore
  • 3. Semaphore count, wait registration, and preposting
  • 4. Combined semaphore wait and signal orders two objects
  • 5. Eventlinks publish two endpoints and a waiting association
  • 6. Eventlink counts describe observations, not consumable credits
  • 7. Handoff, timeouts, interruption, and returned counts
  • 8. Destroy, no-senders, and final storage release
  • 9. Source tests and implementation limits

7. System-call and Mach entry-point map

• Kernel entry interfaces: BSD syscalls, Mach traps and Mach messages
• Machine entry points: ARM64 SVC, x86 syscall classes, and compatibility routes
  • 1. ARM64: the SVC instruction and selector are separate
  • 2. ARM Mach-table arguments, policy, and return
  • 3. x86-64: syscall class selects the dispatcher
  • 4. Legacy x86 entry and 32-bit argument munging
  • 5. Complete x86 machine-dependent tables
  • 6. x86 diagnostic selectors
  • 7. Boundaries and source coverage
• Command dispatch, argument copying and endpoint lifetime
  • The syscall number is the first selector
  • Ioctl first copies an outer argument block
  • Descriptor retention and endpoint dispatch have different locks
  • Worked argument conversion: installing a BPF program
  • Fcntl chooses the representation in each command
  • Sysctl stores lookup state separately from transfer state
  • Dynamic OID removal waits for admitted handlers
  • Output failures preserve each endpoint's actual progress
  • Scope and continuation
• Mach traps: complete slot catalog and operation boundaries
  • Complete table: all 128 slots
  • ABI metadata and historical discrepancies
  • Current-task fast traps and MIG fallback
  • Message transport, packed ABI, and interruption
  • Semaphores, scheduler calls, and timer ports
  • Exclaves slot 88: all 26 secondary operations
  • IOKit, task access, and retained stubs
  • Mach-named operations outside this table
  • Inspection scope and regeneration

8. BSD system-call catalog

• Complete BSD syscall catalog and dispatch
• BSD syscall number and configuration index
  • Reconciliation
• BSD syscalls: Processes credentials and policy
  • 1: exit
  • 2: fork
  • 7: wait4
  • 20: getpid
  • 23: setuid
  • 24: getuid
  • 25: geteuid
  • 26: ptrace
  • 38: sys_crossarch_trap
  • 39: getppid
  • 43: getegid
  • 47: getgid
  • 49: getlogin
  • 50: setlogin
  • 55: reboot
  • 59: execve
  • 66: vfork
  • 79: getgroups
  • 80: setgroups
  • 81: getpgrp
  • 82: setpgid
  • 96: setpriority
  • 100: getpriority
  • 117: getrusage
  • 126: setreuid
  • 127: setregid
  • 147: setsid
  • 151: getpgid
  • 152: setprivexec
  • 173: waitid
  • 181: setgid
  • 182: setegid
  • 183: seteuid
  • 194: getrlimit
  • 195: setrlimit
  • 243: initgroups
  • 244: posix_spawn
  • 285: sys_settid
  • 286: gettid
  • 287: setsgroups
  • 288: getsgroups
  • 289: setwgroups
  • 290: getwgroups
  • 293: identitysvc
  • 310: getsid
  • 311: sys_settid_with_pid
  • 322: iopolicysys
  • 323: process_policy
  • 327: issetugid
  • 336: proc_info
  • 380: __mac_execve
  • 400: wait4_nocancel
  • 416: waitid_nocancel
  • 433: pid_suspend
  • 434: pid_resume
  • 435: pid_hibernate
  • 436: pid_shutdown_sockets
  • 445: usrctl
  • 446: proc_rlimit_control
  • 452: proc_uuid_policy
  • 454: system_override
  • 456: sfi_ctl
  • 457: sfi_pidctl
  • 458: coalition
  • 459: coalition_info
  • 494: persona
  • 532: coalition_ledger
  • 538: task_inspect_for_pid
  • 539: task_read_for_pid
  • 545: proc_info_extended_id
  • 556: sys_coalition_policy_set
  • 557: sys_coalition_policy_get
• BSD syscalls: Signals and thread control
  • 37: kill
  • 46: sigaction
  • 48: sigprocmask
  • 52: sigpending
  • 53: sigaltstack
  • 111: sigsuspend
  • 184: sigreturn
  • 328: __pthread_kill
  • 329: __pthread_sigmask
  • 330: __sigwait
  • 331: __disable_threadsignal
  • 332: __pthread_markcancel
  • 333: __pthread_canceled
  • 334: __semwait_signal
  • 410: sigsuspend_nocancel
  • 422: __sigwait_nocancel
  • 423: __semwait_signal_nocancel
  • 520: terminate_with_payload
  • 521: abort_with_payload
  • 529: os_fault_with_payload
• BSD syscalls: Events pthreads and async io
  • 93: select
  • 230: poll
  • 297: psynch_rw_longrdlock
  • 298: psynch_rw_yieldwrlock
  • 299: psynch_rw_downgrade
  • 300: psynch_rw_upgrade
  • 301: psynch_mutexwait
  • 302: psynch_mutexdrop
  • 303: psynch_cvbroad
  • 304: psynch_cvsignal
  • 305: psynch_cvwait
  • 306: psynch_rw_rdlock
  • 307: psynch_rw_wrlock
  • 308: psynch_rw_unlock
  • 309: psynch_rw_unlock2
  • 312: psynch_cvclrprepost
  • 313: aio_fsync
  • 314: aio_return
  • 315: aio_suspend
  • 316: aio_cancel
  • 317: aio_error
  • 318: aio_read
  • 319: aio_write
  • 320: lio_listio
  • 360: bsdthread_create
  • 361: bsdthread_terminate
  • 362: kqueue
  • 363: kevent
  • 366: bsdthread_register
  • 367: workq_open
  • 368: workq_kernreturn
  • 369: kevent64
  • 372: thread_selfid
  • 374: kevent_qos
  • 375: kevent_id
  • 394: pselect
  • 395: pselect_nocancel
  • 407: select_nocancel
  • 417: poll_nocancel
  • 421: aio_suspend_nocancel
  • 443: guarded_kqueue_np
  • 478: bsdthread_ctl
  • 496: mach_eventlink_signal
  • 497: mach_eventlink_wait_until
  • 498: mach_eventlink_signal_wait_until
  • 499: work_interval_ctl
  • 515: sys_ulock_wait
  • 516: sys_ulock_wake
  • 530: kqueue_workloop_ctl
  • 544: sys_ulock_wait2
• BSD syscalls: Files and descriptors
  • 3: read
  • 4: write
  • 5: open
  • 6: sys_close
  • 41: sys_dup
  • 42: pipe
  • 54: ioctl
  • 89: sys_getdtablesize
  • 90: sys_dup2
  • 92: sys_fcntl
  • 120: readv
  • 121: writev
  • 131: sys_flock
  • 153: pread
  • 154: pwrite
  • 199: lseek
  • 216: open_dprotected_np
  • 218: openat_dprotected_np
  • 277: open_extended
  • 396: read_nocancel
  • 397: write_nocancel
  • 398: open_nocancel
  • 399: sys_close_nocancel
  • 406: sys_fcntl_nocancel
  • 411: readv_nocancel
  • 412: writev_nocancel
  • 414: pread_nocancel
  • 415: pwrite_nocancel
  • 430: sys_fileport_makeport
  • 431: sys_fileport_makefd
  • 441: guarded_open_np
  • 442: guarded_close_np
  • 444: change_fdguard_np
  • 463: openat
  • 464: openat_nocancel
  • 479: openbyid_np
  • 484: guarded_open_dprotected_np
  • 485: guarded_write_np
  • 486: guarded_pwrite_np
  • 487: guarded_writev_np
  • 540: sys_preadv
  • 541: sys_pwritev
  • 542: sys_preadv_nocancel
  • 543: sys_pwritev_nocancel
• BSD syscalls: Filesystem namespace
  • 9: link
  • 10: unlink
  • 12: sys_chdir
  • 13: sys_fchdir
  • 14: mknod
  • 56: revoke
  • 57: symlink
  • 58: readlink
  • 61: chroot
  • 128: rename
  • 132: mkfifo
  • 136: mkdir
  • 137: rmdir
  • 205: undelete
  • 223: exchangedata
  • 226: delete
  • 227: copyfile
  • 291: mkfifo_extended
  • 292: mkdir_extended
  • 348: __pthread_chdir
  • 349: __pthread_fchdir
  • 462: clonefileat
  • 465: renameat
  • 471: linkat
  • 472: unlinkat
  • 473: readlinkat
  • 474: symlinkat
  • 475: mkdirat
  • 488: renameatx_np
  • 517: fclonefileat
  • 551: freadlink
  • 553: mkfifoat
  • 554: mknodat
• BSD syscalls: Filesystem metadata
  • 15: chmod
  • 16: chown
  • 33: access
  • 34: chflags
  • 35: fchflags
  • 60: umask
  • 123: fchown
  • 124: fchmod
  • 138: utimes
  • 139: futimes
  • 188: stat
  • 189: sys_fstat
  • 190: lstat
  • 191: pathconf
  • 192: sys_fpathconf
  • 196: getdirentries
  • 200: truncate
  • 201: ftruncate
  • 217: fsgetpath_ext
  • 220: getattrlist
  • 221: setattrlist
  • 222: getdirentriesattr
  • 225: searchfs
  • 228: fgetattrlist
  • 229: fsetattrlist
  • 234: getxattr
  • 235: fgetxattr
  • 236: setxattr
  • 237: fsetxattr
  • 238: removexattr
  • 239: fremovexattr
  • 240: listxattr
  • 241: flistxattr
  • 278: umask_extended
  • 279: stat_extended
  • 280: lstat_extended
  • 281: sys_fstat_extended
  • 282: chmod_extended
  • 283: fchmod_extended
  • 284: access_extended
  • 338: stat64
  • 339: sys_fstat64
  • 340: lstat64
  • 341: stat64_extended
  • 342: lstat64_extended
  • 343: sys_fstat64_extended
  • 344: getdirentries64
  • 364: lchown
  • 427: fsgetpath
  • 461: getattrlistbulk
  • 466: faccessat
  • 467: fchmodat
  • 468: fchownat
  • 469: fstatat
  • 470: fstatat64
  • 476: getattrlistat
  • 524: setattrlistat
• BSD syscalls: Filesystem mounts and control
  • 18: getfsstat
  • 36: sync
  • 95: fsync
  • 155: nfssvc
  • 157: statfs
  • 158: fstatfs
  • 159: unmount
  • 161: getfh
  • 164: funmount
  • 165: quotactl
  • 167: mount
  • 187: fdatasync
  • 242: fsctl
  • 245: ffsctl
  • 248: fhopen
  • 345: statfs64
  • 346: fstatfs64
  • 347: getfsstat64
  • 408: fsync_nocancel
  • 424: __mac_mount
  • 425: __mac_get_mount
  • 426: __mac_getfsstat
  • 455: vfs_purge
  • 518: fs_snapshot
  • 526: fmount
  • 537: pivot_root
  • 549: graftdmg
  • 555: ungraftdmg
• BSD syscalls: Virtual memory
  • 65: msync
  • 73: munmap
  • 74: mprotect
  • 75: madvise
  • 78: mincore
  • 85: swapon
  • 197: mmap
  • 203: mlock
  • 204: munlock
  • 250: minherit
  • 294: shared_region_check_np
  • 296: vm_pressure_monitor
  • 324: mlockall
  • 325: munlockall
  • 405: msync_nocancel
  • 439: kas_info
  • 440: memorystatus_control
  • 453: memorystatus_get_level
  • 489: mremap_encrypted
  • 534: memorystatus_available_memory
  • 536: shared_region_map_and_slide_2_np
  • 550: map_with_linking_np
• BSD syscalls: Local ipc
  • 251: semsys
  • 252: msgsys
  • 253: shmsys
  • 254: semctl
  • 255: semget
  • 256: semop
  • 258: msgctl
  • 259: msgget
  • 260: msgsnd
  • 261: msgrcv
  • 262: shmat
  • 263: shmctl
  • 264: shmdt
  • 265: shmget
  • 266: shm_open
  • 267: shm_unlink
  • 268: sem_open
  • 269: sem_close
  • 270: sem_unlink
  • 271: sem_wait
  • 272: sem_trywait
  • 273: sem_post
  • 418: msgsnd_nocancel
  • 419: msgrcv_nocancel
  • 420: sem_wait_nocancel
• BSD syscalls: Sockets and network policy
  • 27: recvmsg
  • 28: sendmsg
  • 29: recvfrom
  • 30: accept
  • 31: getpeername
  • 32: getsockname
  • 97: socket
  • 98: connect
  • 104: bind
  • 105: setsockopt
  • 106: listen
  • 118: getsockopt
  • 133: sendto
  • 134: shutdown
  • 135: socketpair
  • 337: sendfile
  • 401: recvmsg_nocancel
  • 402: sendmsg_nocancel
  • 403: recvfrom_nocancel
  • 404: accept_nocancel
  • 409: connect_nocancel
  • 413: sendto_nocancel
  • 447: connectx
  • 448: disconnectx
  • 449: peeloff
  • 450: socket_delegate
  • 460: necp_match_policy
  • 480: recvmsg_x
  • 481: sendmsg_x
  • 490: netagent_trigger
  • 501: necp_open
  • 502: necp_client_action
  • 522: necp_session_open
  • 523: necp_session_action
  • 525: net_qos_guideline
  • 546: tracker_action
• BSD syscalls: Skywalk
  • 503: __nexus_open
  • 504: __nexus_register
  • 505: __nexus_deregister
  • 506: __nexus_create
  • 507: __nexus_destroy
  • 508: __nexus_get_opt
  • 509: __nexus_set_opt
  • 510: __channel_open
  • 511: __channel_get_info
  • 512: __channel_sync
  • 513: __channel_get_opt
  • 514: __channel_set_opt
• BSD syscalls: Security and audit
  • 169: csops
  • 170: csops_audittoken
  • 350: audit
  • 351: auditon
  • 353: getauid
  • 354: setauid
  • 357: getaudit_addr
  • 358: setaudit_addr
  • 359: auditctl
  • 381: __mac_syscall
  • 382: __mac_get_file
  • 383: __mac_set_file
  • 384: __mac_get_link
  • 385: __mac_set_link
  • 386: __mac_get_proc
  • 387: __mac_set_proc
  • 388: __mac_get_fd
  • 389: __mac_set_fd
  • 390: __mac_get_pid
  • 428: audit_session_self
  • 429: audit_session_join
  • 432: audit_session_port
  • 483: csrctl
  • 500: getentropy
• BSD syscalls: Time and accounting
  • 51: acct
  • 83: setitimer
  • 86: getitimer
  • 116: gettimeofday
  • 122: settimeofday
  • 140: adjtime
  • 186: thread_selfcounts
  • 373: ledger
  • 482: thread_selfusage
  • 527: ntp_adjtime
  • 528: ntp_gettime
  • 531: __mach_bridge_remote_time
• BSD syscalls: Diagnostics and system control
  • 67: oslog_coproc_reg
  • 68: oslog_coproc
  • 142: gethostuuid
  • 177: kdebug_typefilter
  • 178: kdebug_trace_string
  • 179: kdebug_trace64
  • 180: kdebug_trace
  • 185: sys_panic_with_data
  • 202: sysctl
  • 274: sys_sysctlbyname
  • 451: telemetry
  • 477: proc_trace_log
  • 491: stack_snapshot_with_config
  • 492: microstackshot
  • 493: grab_pgo_data
  • 533: log_data
  • 535: objc_bp_assist_cfg_np
  • 547: debug_syscall_reject
  • 548: sys_debug_syscall_reject_config
  • 552: sys_record_system_event

9. Mach message and MIG interface catalog

• Mach message interfaces: declarations, dispatch and implementation routes
• MIG subsystem and source inventory
  • Include wrappers
  • Supporting type definitions
  • Test interfaces
  • Reconciliation
• Mach messages: mach_port
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_vm
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: task
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: thread_act
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_host
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: host_priv
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: processor
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: processor_set
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: clock
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: device
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_voucher
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_eventlink
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: memory_entry
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: restartable
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: exc
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_exc
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: notify
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: UNDReply
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: UNDRequest
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: arcade_register
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: arcade_upcall
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: audit_triggers
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: clock_priv
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: clock_reply
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: coalition_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: doubleagent_mig
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: fairplayd_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: gssd_mach
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: host_notify_reply
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: host_security
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: iocompressionstats_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: kextd_mach
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: ktrace_background
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: ledger
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: lockd_mach
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_test_upcall
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: mach_voucher_attr_control
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: memory_error_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: netname
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: prof
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: resource_notify
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: semaphore
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: sysdiagnose_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: task_access
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: telemetry_notification
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: upl
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: vfs_nspace
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: vm32_map
  • Reading these entries
  • Complete routine and reserved-slot catalog
• Mach messages: vm_map
  • Reading these entries
  • Complete routine and reserved-slot catalog

10. VFS, filesystem objects and storage I/O

• VFS, filesystems, and storage I/O
• Vnodes, mounts, open files, and operation dispatch
  • Four objects with different lifetimes
  • Iocount, usecount, holdcount and identity
  • From open to filesystem method
  • Lifecycle and lock boundaries
• Pathname resolution, name caching, and authorization
  • A pathname lookup is a stateful operation
  • Component traversal and fast paths
  • Name cache entries are validated identities
  • Authorization happens at several boundaries
  • Compound operations and cleanup
• Vnode permissions, ACL evaluation and inheritance
  • 1. The request is an action mask plus an execution context
  • 2. Attributes and temporary state used by the evaluator
  • 3. Mount, immutable, root and opaque-filesystem decisions
  • 4. Ordered ACL evaluation: requested rights and residual rights differ
  • 5. Principal matching and incomplete group information
  • 6. How unresolved ACL rights become POSIX checks
  • 7. Delete permission is a two-object decision
  • 8. Creation composes a new ACL with explicit ownership
  • 9. Updating security attributes and invalidating cached decisions
  • 10. Configuration, tests and boundaries
• Name-cache validation and vnode reclamation
  • The identities and references involved
  • A single-component cache lookup
  • Walking several cached components
  • Publishing, deleting and purging names
  • Draining a vnode is a state transition
  • Cleaning filesystem state and changing identity
  • What these checks do and do not establish
• Vnode cache identity, reclamation, and reuse
  • 1. What is cached, and what does eviction mean?
  • 2. References protect different things
  • 3. Free, age, dead, and asynchronous queues
  • 4. Filesystem lookup recovers a vnode, not just a pointer
  • 5. Name-cache replacement and its three validity checks
  • 6. Cached permission is a credential-specific allowed-action set
  • 7. Inactive, reclaim, UBC teardown, and mount pressure
  • 8. Reading route and inspection limits
• Namespace mutations: lookup, authorization, and publication
  • 1. The objects carried through an operation
  • 2. Ordinary and compound operations
  • 3. Create and mkdir: a successful creation is a distinct event
  • 4. Hard links and unlink: names and object lifetime separate
  • 5. Rename: two lookups, one serialization decision, several retry classes
  • 6. What “publication” means here
• Attribute lists, extended attributes and property transfer
  • Attribute selection becomes a vnode request
  • Packed layout and a concrete relative-offset example
  • Bulk directory enumeration is stateful
  • Attribute setting is ordered work, not one universal transaction
  • Extended-attribute syscall to VNOP
  • AppleDouble fallback crosses into DoubleAgent
• Advisory byte-range locks and file leases
  • Which owner survives dup, fork and close?
  • Normalize, find conflicts and edit intervals
  • Sleep and deadlock checks
  • Closing a file and disposing a transferred reference
  • Lease state and break requests
• Filesystem events: production, watcher queues and delivery
  • Shared events and private watcher state
  • Registering a watcher creates a new descriptor
  • Production and coalescing
  • Queue pressure is observable loss
  • Reading complete event records
  • Close, readiness and unmount
• Quota records, cache identity and filesystem boundaries
  • Control dispatch and the stored objects
  • Quota-file open and close exclusion
  • Cache lookup survives sleeping and races
  • The on-disk lookup and byte order
  • Three release routes and their different I/O rules
• Mount publication, traversal and unmount
  • One mount, several lifetime mechanisms
  • Mount and update enter through different branches
  • Crossing a mount during lookup
  • What vfs_busy actually guarantees
  • Unmount closes admission before draining
  • vflush distinguishes busy vnodes and device aliases
  • Successful detach still leaves lifetime work
  • Failed unmount is not a rewind
• UBC, clustered I/O, buffers, and storage completion
  • One file, several representations
  • Trace a cached read through an included filesystem
  • Extents and device constraints
  • Completion returns ownership
  • Writes, delayed work, and the buffer cache
• File-data caching, read decisions, and UBC lifetime
  • 1. Keep file identity, VM contents and transfers separate
  • 2. The first decision is which read mechanism applies
  • 3. A resident hit still has an ownership protocol
  • 4. A miss gathers a mixed range rather than discarding resident pages
  • 5. Read-ahead is predictive and disposable
  • 6. Direct reads still need a coherence boundary
  • 7. Mappings keep the vnode alive, but private copies can diverge
  • 8. Size changes and invalidation operate on page ranges
  • 9. Work through a mixed resident/missing read
  • Sources inspected and limits
• Buffer-cache identity, block I/O, and completion ownership
  • 1. One structure participates in several independent lists
  • 2. Acquisition must revalidate identity after any wait
  • 3. Metadata owns storage; file-data buffers borrow VM pages
  • 4. Reads return an owned buffer; read-ahead transfers ownership
  • 5. Strategy dispatch crosses filesystem and device boundaries
  • 6. Dirty, submitted and durable are different states
  • 7. biodone and brelse finish different obligations
  • 8. Reuse, invalidation and pressure collection have different policies
  • 9. Header counts do not cap all cached file data
  • 10. A concrete block-device read and partial write
  • Sources inspected and limits
• Clustered writes, dirty tracking and I/O completion
  • State carried across the layers
  • Selecting the write path
  • Buffered copying preserves untouched data
  • Packed extents and sparse dirty regions
  • Picking up the right pages for writeback
  • Mapping file ranges into buffer transactions
  • Completion has several layers
  • Direct writes still synchronize with the file cache
  • Failure, synchronization and durability boundaries
• Compressed file data, decmpfs state and UPL completion
  • The compressed cnode and its metadata
  • Providers, locks and the fetch contract
  • Ordinary reads try resident data first
  • Page-in keeps three offsets distinct
  • Converting the whole file changes backing state
• Filesystem registration, boot mounts, small filesystems, and NFS
  • Filesystem type registration and operation vectors
  • Boot and ordinary mounts
  • Included filesystems and operation layers
  • NFS server request path
  • lockd, gssd, and missing client code
• Device nodes, specfs, and named FIFOs
  • 1. Devfs has a namespace before it has a vnode
  • 2. Lookup converts a named devnode into a usable vnode
  • 3. Clone devices deliberately do not cache one vnode
  • 4. Specfs identity is the device number and type
  • 5. Open, data transfer, and last close reach the device switch
  • 6. Named FIFO activation creates a local stream transport
  • 7. FIFO close ends an active instance, not the name
• Stacked filesystems: bindfs and nullfs
  • 1. Two different namespace shapes
  • 2. Alias structures and three independent reference purposes
  • 3. Creation races are resolved at hash insertion
  • 4. Lookup forwards one operation, then wraps the result
  • 5. Reported identity and the nullfs credential context
  • 6. Reads and faults cross the layers differently
  • 7. Reclaim and unmount release different references
• NFS server requests: transport, replay, file handles, and writes
  • 1. The state objects and locks
  • 2. A user-supplied socket becomes server-owned transport
  • 3. Raw stream bytes become complete RPC records
  • 4. Worker ownership and two kinds of error
  • 5. The replay cache is a bounded duplicate filter
  • 6. File handles resolve an export and a local vnode
  • 7. READ fills reply mbufs through a kernel-space uio
  • 8. WRITE stability becomes local I/O flags
  • 9. Delayed writes transfer descriptor ownership into gather queues
  • 10. COMMIT is a vnode-wide fsync in this implementation
  • 11. Reply transmission and shutdown finish ownership

11. Sockets, transports, interfaces and Skywalk

• Networking
• Sockets and buffering
  • From descriptor to protocol
  • Socket state and buffers
  • Send and receive contracts
  • Lock selection is protocol-dependent
  • Readiness and final teardown
• Socket lifetime, buffering, and I/O ownership
  • The objects and independent forms of protection
  • Sending: prepare, reserve access, then surrender the mbufs
  • Receiving: dequeue is separate from userspace copyout
  • Ancillary data can carry references, not just bytes
  • Wakeups and close complete a different lifetime
  • Sources inspected and limits
• Internet PCBs: address lookup, port allocation and lifetime
  • The objects and the three kinds of protection
  • Binding a port is a publication transaction
  • Lookup: exact tuple, wildcard fallback, then a lifetime handoff
  • Connect and disconnect change receive identity
  • Death, stop-using and final disposal
  • Boundaries and follow-up evidence
• UDP: sending a datagram, receiving a record and reporting errors
  • Endpoint state and entry points
  • Worked send: unconnected socket, implicit local port
  • Headers, checksum and ownership across IP output
  • Receive: validation before endpoint lookup
  • Socket-buffer admission and record delivery
  • Local errors, missing listeners and asynchronous errors
  • IPv6 and configuration boundaries
• TCP, IP, interfaces, and mbufs
  • State for one TCP connection
  • Ordinary established-connection transmit
  • Receive from an interface to a reader
  • DLIL, routes, and driver lifetime
  • Mbuf ownership
  • UDP and IPv6 reading branches
• TCP connections, accept queues, loss timers, and close
  • One connection and its synchronization
  • Active open: publish the tuple, then drive the handshake
  • Passive open: the listener and child have different lifetimes
  • Buffered data, acknowledgment, and loss are separate mechanisms
  • Timers own references and must revalidate after locking
  • Half-close, TIME_WAIT, and actual teardown
  • Sources inspected and limits
• TCP loss recovery and congestion control
  • 1. State and execution context
  • 2. ACK processing: delivery evidence is not buffer release
  • 3. Legacy SACK: represent what is missing
  • 4. RACK: retain transmissions and identify delivery in time
  • 5. RACK loss detection and its reordering timer
  • 6. Recovery entry, output and completion
  • 7. Tail-loss probes, reordering expiry and RTO
  • 8. Congestion-control dispatch and storage
  • 9. NewReno and CUBIC: actual window decisions
  • 10. Worked RACK recovery with NewReno
  • 11. ECN, Prague and background traffic boundaries
  • 12. Configuration, tests and teardown
• MPTCP sessions and TCP subflows
  • 1. One application socket, several transport identities
  • 2. Connect admission precedes several kinds of publication
  • 3. Lock switching and deferred callbacks protect the session
  • 4. Assign DSNs before choosing a TCP carrier
  • 5. Select an eligible subflow, then apply the service policy
  • 6. Reinjection preserves the connection range
  • 7. Receive mappings feed a second reassembly layer
  • 8. Data ACK releases the parent send buffer
  • 9. Worked example: two subflows and one missing connection range
  • 10. Fallback changes the numbering contract used for delivery
  • 11. Subflow loss, stream close and storage release are different events
  • 12. Configuration and evidence limits
• IPv6: configuration, packet paths and object lifetime
  • Reading order
  • Objects that must not be conflated
  • One host operation across the chapters
  • Source map and coverage limits
• IPv6 addresses, autoconfiguration and duplicate detection
  • The objects that outlive configuration
  • Entry points and serialization
  • Attaching a link and selecting a link-local IID
  • Constructing and publishing an interface address
  • Prefix association follows address publication
  • SLAAC persistent addresses, CGA and privacy addresses
  • Starting DAD: flags, multicast and scheduling
  • Probe transmission, duplicate observations and the nonce
  • DAD completion, failure and secured-address retries
  • Deprecation, expiry and complete teardown
  • Worked lifetime example and boundaries
• IPv6 router advertisements, prefixes and route lifetime
  • State is split between routers, prefixes, addresses and routes
  • ICMPv6 entry and admission
  • Option parsing is bounded but not all-or-nothing
  • Interface parameters from the RA
  • Default-router candidates and zero-lifetime advertisements
  • Route Information Options have their own candidate lists
  • Prefix Information Options: L and A answer different questions
  • Address lifetimes and the two-hour rule
  • Reachability changes deprecate without immediately removing the prefix route
  • Expiry, deletion and interface detach
  • Events, partial results and implementation boundaries
• IPv6 scopes, source-address selection and route-cache ownership
  • Three different meanings of interface selection
  • Source selection has three entry cases
  • The candidate loop is an ordered decision procedure
  • Policy labels are not a user-space destination sort
  • Route selection reuses state only after validation
  • Boundaries and useful follow-up checks
• IPv6 sockets, packet options and transport handoffs
  • Protocol registration chooses the callback family
  • Native IPv6 and mapped IPv4 are different output paths
  • Binding publishes a tuple under table protection
  • Connect changes lookup identity without sending a handshake
  • One native UDP send, from ancillary records to output
  • Sticky and ancillary options are allocated representations
  • Native UDP receive: exact tuple, wildcard and wanted references
  • Receive controls preserve metadata before headers disappear
  • Raw IPv6 and ICMPv6 datagram sockets
  • Review limits
• IPv6 input, extension headers and forwarding
  • Entry and the objects carried through input
  • Admission changes packet representation before delivery
  • Hop-by-Hop processing and the payload-length contract
  • The local next-header loop is a continuation protocol
  • Router forwarding is an output transaction with an error copy
  • Raw and ICMP delivery boundaries
  • Evidence and limits
• IPv6 output, next-hop resolution and neighbor lifetime
  • Addresses, routes and neighbor records
  • Source selection precedes the packet-to-link handoff
  • Extension headers become an owned mbuf chain
  • MTU, checksum and fragments are explicit decisions
  • Neighbor lookup can change which route is held
  • The held packet is replaced, not appended forever
  • Advertisement validation and release of held packets
  • Timer transitions, failed resolution and teardown
  • Scope of this reconstruction
• IPv6 neighbor messages, reachability and redirects
  • Cache representation: address, route, link-layer bytes and state
  • ICMPv6 admission and the two consumers of an ND message
  • ND options: bounded parsing and preserved first occurrences
  • Neighbor Solicitation: validate the target, learn the source, answer
  • Neighbor Advertisement: the target entry and three independent flags
  • NUD is driven by use, messages and asynchronous maintenance
  • Constructing NS and NA packets
  • Redirects validate the current first hop before changing routes
  • Evidence and boundaries
• IPv6 multicast membership, source filters and MLD
  • Three meanings of membership
  • Socket entry points and interface selection
  • The join and filter-change transaction
  • Failure and partial progress are not a universal rollback
  • MLD states, queries and compatibility
  • Report buffers, timers and output ownership
  • Receive filtering and multicast loopback
  • Leave, close, deferred release and interface detach
  • Inspecting state and tests available in this tree
• Packet storage, route references, and interface teardown
  • Mbuf chains, packet lists, and external storage
  • Routes: a cache entry is a reference, not a permanent decision
  • Output: protocol media work can retain a packet
  • Input: queueing and protocol dispatch change the processing context
  • Interface teardown: hide, quiesce, dismantle, release
  • Sources inspected and limits
• Routing control and IPv4 ARP
  • 1. Objects: a request, a route, a next hop and a held packet
  • 2. Routing socket admission and message decoding
  • 3. Mutation, scoped lookup and host clones
  • 4. Notifications and route deletion have their own lifetimes
  • 5. IPv4 Ethernet output: use a link address or transfer packet ownership
  • 6. Reply processing and a worked unresolved-neighbor flow
  • 7. Three independent aging decisions
  • 8. Test evidence and remaining boundaries
• IP fragment reassembly and ICMP error feedback
  • Entry, delivery and the meaning of an incomplete result
  • Queue identity and the objects that own bytes
  • IPv4 insertion, overlap and assembly
  • IPv6: atomic fragments, first-header validation and dirty queues
  • Resource bounds, timers and cleanup context
  • Generating an ICMP error consumes the offending packet
  • Receiving ICMP: quoted headers become transport control input
  • Path MTU: route state, TCP state and validation occur at different points
  • Review limits and source tests
• Mbuf allocation classes, CPU caches and memory pressure
  • Select the allocator before following a same-named function
  • Initialization connects generic caches to networking slabs
  • Fast allocation and the slow path
  • Composite allocation is a three-resource transaction
  • Shared external buffers determine what a free can release
  • Freeing, pressure and waking blocked allocators
  • Reading limits
• Kernel control sockets and network statistics subscriptions
  • Registration, naming and per-connection identity
  • Connecting safely while callbacks run without the socket lock
  • Sending and receiving have different buffer contracts
  • Ntstat installs that transport and adds a provider/source model
  • Request dispatch and adding a source
  • Queries can make partial progress
  • PCB lifetime and observer teardown
  • Limits
• Policy and protocol extensions
  • NECP: decisions associated with a socket or flow
  • Content filters retain and reinject data
  • PF and IPsec operate at packet boundaries
  • Flow diversion changes the transport route
  • MPTCP adds a connection above TCP subflows
• Classic BPF capture and filter lifetime
  • Device, descriptor, interface entry, and packet view
  • Open reserves a minor; binding supplies capture storage
  • Filter replacement has an explicit publication boundary
  • Validation and the classic interpreter
  • Tap direction, capture length, and record layout
  • Two allocations rotate through three slots
  • Read protects a slot while dropping the mutex
  • Detach and close remove different access paths
  • Source tests and remaining boundaries
• PF rule publication, packet state and reclamation
  • 1. Device access does not own a ruleset
  • 2. Inactive rules become active by a pointer swap
  • 3. Packet entry carries mutable ownership
  • 4. A state is more than a cached matching rule
  • 5. Unlinking stops lookup before storage is freed
  • 6. Configuration, test evidence and remaining scope
• IPsec policy, associations, and packet transforms
  • 1. Policy identity and association identity are different
  • 2. PF_KEY admission, parsing, and operation results
  • 3. Publishing and retiring an SA
  • 4. A single-request IPv4 output operation
  • 5. ESP output changes the packet before completion
  • 6. Inbound lookup, authentication, and replay are separate decisions
  • 7. IPv6 output separates transport insertion from tunnel construction
  • 8. Multiple requests transform the current packet in list order
  • 9. Rekey selection is state-ordered and can retire candidates
  • 10. Variants, tests, and implementation boundaries
• IPsec interfaces, packet representations, and staged disconnect
  • 1. One interface implementation has three packet paths
  • 2. Control admission creates identities before publishing an interface
  • 3. Interface publication changes who owns final cleanup
  • 4. Interface output selects an association and consumes the mbuf
  • 5. Native TX changes representation before ordinary IPsec output
  • 6. Kernel pipes keep ESP processing in packet form
  • 7. Inbound injection transfers ownership before delivery finishes
  • 8. Disconnect crosses several independent lifetime barriers
  • 9. Scope and external boundaries
• NECP policy sessions, compilation and packet decisions
  • 1. Entry points and objects
  • 2. Opening and controlling a policy session
  • 3. TLV parsing transfers owned buffers into a staged policy
  • 4. Session priority and compiled order
  • 5. One session rule can produce several kernel policies
  • 6. Apply and removal are serialized, but not a rollback transaction
  • 7. Maps reduce candidates without replacing rule evaluation
  • 8. Matching accumulates secondary results before a terminal decision
  • 9. Socket caching and invalidation
  • 10. Packet tags connect socket policy to IP output
  • 11. Application evaluation also asks whether a route is usable
  • 12. Worked update and verification boundaries
• NECP clients, flow registrations and agent assignments
  • 1. The fd is a control and readiness object
  • 2. UUIDs name different levels of state
  • 3. Lock order, references and the route
  • 4. ADD copies a request, checks privileges and publishes a client
  • 5. Path evaluation updates base results and concrete flow viability
  • 6. ADD_FLOW publishes a registration, then requests provider work
  • 7. Kernel and userspace agents return assignments differently
  • 8. Socket registration connects an inpcb to the client
  • 9. Readiness, result serialization and partial copyout
  • 10. Push observers receive bounded copies, not a lossless journal
  • 11. Claim, explicit removal and close
  • 12. Worked path: a client with one nexus flow
  • 13. Review boundaries and useful invariants
• BSD socket content filtering: byte verdicts, retained data and reinjection
  • 1. Where the mechanism enters the socket stack
  • 2. Provider admission, transport units and policy selection
  • 3. The objects that own state and data
  • 4. Absolute offsets and whole-record release
  • 5. Multiple filters and a numeric example
  • 6. Events, action validation and the initial verdict
  • 7. Controller backpressure and a source-level retry limitation
  • 8. Reinjection consumes data before reporting its result
  • 9. Held bytes still consume socket capacity
  • 10. Datagram flow identity, ancillary data and saved socket state
  • 11. Lock ordering and references across waits
  • 12. Policy changes, blessing, drop and provider disconnect
  • 13. Shutdown, close and delayed protocol teardown
  • 14. Datagram garbage collection and cleanup boundaries
  • 15. Verification and remaining boundaries
• Flow diversion, provider buffers, and socket lifetime
  • 1. The policy decision changes the socket's dispatch
  • 2. A flow, a group and a control connection have different identities
  • 3. Provider admission and token parsing are separate decisions
  • 4. CONNECT acceptance is not completed connection establishment
  • 5. Two different kinds of backpressure retain different buffers
  • 6. Inbound data and application read notifications
  • 7. Provider fallback changes dispatch again
  • 8. Shutdown, detach and provider death end different lifetimes
  • 9. Source-test evidence and remaining boundaries
• Skywalk channels and flowswitch
  • Objects and the userspace boundary
  • TX sync validates and transfers ownership
  • Concrete flowswitch transmit path
  • Netif and receive-side integration
• Skywalk channel, packet-pool, and flow lifecycles
  • Four objects that must remain distinct
  • Channel creation: authorization, binding, then publication
  • Sync is a validated ownership protocol
  • Allocation rings: packet availability can be partial
  • Transmit and receive transfer different ownership
  • Free rings and close-time reclamation
  • Defunct serializes kernel work and revokes mapped access
  • Flow registration: process association, port binding, and rollback
  • Flow deletion removes visibility before final lifetime ends
  • Sources inspected and limits
• Skywalk controllers, providers, and nexus port lifetime
  • The object hierarchy and its two kinds of provider
  • Initialization and configuration select the available architecture
  • Opening a controller establishes an authority object
  • Domain-provider registration extends an implementation
  • Registering a provider fixes parameters and callback contracts
  • Creating an instance and understanding publication failures
  • A port binding and an adapter association are independent
  • External connection callbacks bracket channel resources
  • Close removes authority before the final objects disappear
  • Tests, invariants, and source limits
• Skywalk channel ABI, readiness, and event delivery
  • What crosses the syscall boundary
  • Admission precedes fd publication
  • The operational surface and its limits
  • Channel thresholds and knote thresholds are different layers
  • Readiness is active work, not a passive flag read
  • Notifications, mitigation, and destruction of wait state
  • Extended hints and packet event records are separate transports
  • Interface-advisory subscription crosses a lock boundary
  • Defunct, close, and tests of the observable contract
• Skywalk memory: regions, caches, arenas and task mappings
  • The hierarchy, including what is shared
  • Region geometry and protection are chosen before mapping
  • Object allocation: magazines, construction and partial success
  • Getting a segment and its memory descriptor
  • Constructing the arena and mapping it into a process
  • Redirecting a mapping revokes backing without immediately deleting its address range
  • Completion boundary and remaining surfaces
• Skywalk packets, buflets and pool ownership
  • Packet, quantum, buflet and backing object
  • Creating the pool chooses the ownership model
  • Constructors versus reuse initialization
  • Allocation rings establish ownership before exposing indices
  • TX submission is lookup, removal and validation
  • What metadata validation actually establishes
  • Kernel sharing and copy modes
  • Freeing a packet can release other packet representations
  • Device ownership and closing the pool
• Skywalk user and kernel pipes
  • 1. Endpoints, rings and memory are different objects
  • 2. User-pipe creation fixes geometry and admits each side
  • 3. Paired rings exchange attachments within one arena
  • 4. Submission, transfer and user-visible completion occur separately
  • 5. Worked example: an eight-slot pair fills and recovers
  • 6. Close, absent peers and defunct are separate transitions
  • 7. Kernel pipes delegate packet decisions to a provider
  • 8. A real consumer: kernel-pipe directions through utun
  • 9. Kernel-pipe defunct preserves provider-facing storage until disconnect
  • 10. Configuration, test evidence and limits
• Skywalk namespaces, flow identity, and packet lookup
  • 1. Four namespaces and a destination port
  • 2. Preparation chooses the reservation mechanism
  • 3. Port reservation objects and publication
  • 4. Collision decisions: owner counts, wildcards, and reuse
  • 5. Ephemeral allocation and BSD/PF participation
  • 6. Changing an address, withdrawing, and releasing
  • 7. Protocol tokens and compact flow IDs
  • 8. Keys are normalized to local and remote endpoints
  • 9. Ordered lookup and retained results
  • 10. UDP child flows add a second lookup stage
  • 11. Evidence, tests, and remaining work
• Skywalk flowswitch classification, routes, and packet delivery
  • 1. Objects and entry points
  • 2. Demultiplex the link header before parsing IP
  • 3. Classification populates metadata; it does not deliver a packet
  • 4. The route cache is shared by destination
  • 5. Ethernet resolution can transfer a packet to BSD neighbor queues
  • 6. Normal channel TX: source packet, device packet, then queue
  • 7. RX: classification miss, per-flow worker, and destination ring
  • 8. Host fallback is an actual delivery path
  • 9. Flow viability and tracking are different from transport execution
  • 10. Route notifications, expiry, and reaper work
  • 11. A worked UDP round trip
  • 12. Source and availability boundaries
• Skywalk fragment ordering, reassembly queues, and flow tracking
  • 1. Where fragments enter the receive path
  • 2. The manager owns queue wrappers and original packets
  • 3. Admission, ordering, overlap, and completion
  • 4. What “reassembled” means here
  • 5. Resource limits, expiry, ICMP, and destruction
  • 6. Transmit fragments use a different rule
  • 7. Tracking records observations in each direction
  • 8. TCP window observation and close transitions
  • 9. UDP observations and generated abort packets
  • 10. Evidence, tests, and remaining boundaries
• Skywalk TCP aggregation, segmentation, and offload boundaries
  • 1. Four operations with different inputs and results
  • 2. Receive aggregation is selected per flow
  • 3. Which packets can join an aggregate?
  • 4. Checksum failure prevents merging, not necessarily delivery
  • 5. Channel aggregation allocates destination buflets
  • 6. Host aggregation builds mbuf chains
  • 7. Channel TX chooses hardware or software segmentation
  • 8. Channel GSO allocation and per-segment construction
  • 9. Host GSO starts with a BSD mbuf
  • 10. Enqueue consumes segments even when congestion is reported
  • 11. QoS marking changes headers after flow processing
  • 12. AOP flow steering is a separate offload lifecycle
  • 13. Validation routes and limits
• Skywalk netif: logical links, queues, and driver servicing
  • 1. Objects: a logical link is not a ring or a hardware DMA queue
  • 2. Link construction and partial provider initialization
  • 3. Queue selection and admission do not imply transmission
  • 4. Native output: doorbells, ring refill and queue dequeue
  • 5. Host and compatibility paths change representation
  • 6. Receive: staging, flushing and the upper consumer
  • 7. Mitigation and polling select when work runs
  • 8. Low-latency push and teardown boundaries
  • 9. Configuration, tests and remaining boundaries
• Interface packet scheduling, FQ-CoDel, and congestion feedback
  • 1. Select the scheduler and packet representation first
  • 2. One scheduler contains groups, classes and per-flow queues
  • 3. Enqueue results carry ownership and feedback
  • 4. Dequeue has two scheduling levels
  • 5. New CoDel: sustained delay, marking and dropping
  • 6. Legacy delay feedback and L4S are separate branches
  • 7. Pacing, shaping and asynchronous feedback
  • 8. Empty queues, purge and scheduler destruction
  • 9. Evidence, tests and interpretation limits
• Skywalk netif filters and packet reinjection
  • 1. Objects and the two meanings of direction
  • 2. Admission, allocation and activation
  • 3. The filter view owns an original packet or mbuf
  • 4. Callback references let the list lock be dropped
  • 5. Delivery to userspace and accepted-packet return
  • 6. RX resumes after filtering; TX waits in processed queues
  • 7. Default drop, teardown and verification boundaries
• Skywalk netif agents, virtual-port flows and traffic rules
  • 1. Separate control identity, receive ownership and queue selection
  • 2. Agent registration and the local NECP boundary
  • 3. Binding a flow does not activate a packet receiver
  • 4. Low-latency address reuse and listener assignments
  • 5. Channel activation publishes the actual receive flow
  • 6. Agent deletion, channel destruction and interface detach
  • 7. Traffic-rule ioctl admission and stored representation
  • 8. Validation and mask order define rule semantics
  • 9. Publication succeeds before optional provider notification
  • 10. From packet bytes to a retained qset
  • 11. Removal, controller close and enumeration
  • 12. Worked lifetimes and verification boundaries
• Skywalk diagnostics, configuration and tests
  • 1. Establish the configuration before interpreting an observation
  • 2. Which object owns the statistic?
  • 3. Sysctl dispatch, authority and private record formats
  • 4. A snapshot is materialized before user copy
  • 5. Flow statistics survive lookup removal
  • 6. Ring and netif counters measure different transitions
  • 7. Mapped protocol statistics, closed ports and system settings
  • 8. Memory snapshots expose backing, cache reuse and mapping separately
  • 9. Logs, Kdebug, DTrace and drop taps carry different evidence
  • 10. Invalid shared state: the diagnostic is part of enforcement
  • 11. Tests are executable scenarios with configuration and outcome limits
  • 12. A test map for the surrounding mechanisms
  • 13. What this inspection establishes and what remains

12. IOKit, drivers and kernel libraries

• IOKit, driver execution, and libkern
• IOKit bootstrap, device-tree import, and the BSD handoff
  • 1. Kernel startup deliberately splits initialization from matching
  • 2. C++ constructors initialize the framework before the root provider is allocated
  • 3. Device-tree import creates registry objects and preserves backing lifetime
  • 4. Selected platform services exist before general matching
  • 5. Resource publication and a completed matching pass are different observations
  • 6. Root-device discovery converts matching policy into a BSD device identity
  • 7. Mount completion and later security hooks remain outside service matching
  • Inspection scope
• libkern objects, executable runtime, and supporting libraries
  • OSObject ownership underlies IOKit
  • Collections own objects but do not supply universal synchronization
  • Metaclasses connect a name to an allocatable class
  • Bootstrap and kext start are different levels
  • Linking and kernel collections are configuration-dependent
  • Useful supporting areas
• IOKit object runtime, class registration, and collection ownership
  • 1. Construction, initialization, and destruction are separate steps
  • 2. The reference word includes collection membership
  • 3. Collections own members but do not serialize callers
  • 4. Copying the container graph is not cloning every object
  • 5. Metaclasses are registered in a module-load transaction
  • 6. Casts, instance counts, and service-instance enumeration
  • Reading route and inspection limits
• Symbol interning: identity, backing bytes and delayed destruction
  • 1. One symbol identity, several kinds of ownership
  • 2. Prepare a safe key before entering SMR
  • 3. Creation races with another creator
  • 4. No-copy and permanent are different decisions
  • 5. Pool growth and shrink reuse the simple-table protocol
  • 6. Final release unlinks before the allocator destroys
  • 7. Module unload can replace borrowed backing
  • 8. Dictionary keys show why the distinction matters
• Kernel collections and OSKext load, start and unload
  • 1. State exists at several levels
  • 2. Boot collection metadata creates module objects
  • 3. Deferred auxiliary collections and runtime file loading differ
  • 4. Lookup may defer work instead of loading immediately
  • 5. Dependency resolution checks identity, compatibility and cycles
  • 6. Executable registration, C++ initialization and start are ordered
  • 7. Stop and unload protect code that still has users
  • 8. Autounload is conditional work, not a reference-count destructor
  • Inspection boundary
• Libkern serialization and IOKit property transport
  • 1. There are three parser families
  • 2. Serialization preserves repeated identity
  • 3. The legacy text parser still has callers
  • 4. XML parsing owns temporary nodes and an object-reference table
  • 5. Binary words encode types, lengths and collection endings
  • 6. Indexed output has additional representation rules
  • 7. Temporary ownership is released after containers retain children
  • 8. A concrete property request crosses VM, parsing and policy
  • Inspection boundary
• NVRAM variables, format handlers and persistence
  • 1. Name, dictionary value, image record and hardware storage are distinct
  • 2. Initialization can precede hardware-controller registration
  • 3. Permissions depend on the operation and variable
  • 4. A property write has special-command and ordinary-value paths
  • 5. V3 updates stage append/removal state
  • 6. V3 raw sync appends before invalidating; reclaim rebuilds a bank
  • 7. CHRP serializes common/system partitions into a replacement image
  • 8. Synchronization success has a limited meaning
  • Inspection boundary
• Registry and service lifecycle
  • A registry entry is an object with relationships
  • Publishing triggers matching
  • Probe results and start are separate decisions
  • Removal is a coordinated protocol
• Registry planes, property ownership, and traversal
  • 1. One entry can participate in several plane graphs
  • 2. Reciprocal links retain entries and must be detached
  • 3. Property locks protect lookup; copy APIs add lifetime
  • 4. Paths identify a route, names and locations are plane-sensitive
  • 5. Snapshot adjacency iterators and live recursive iterators differ
  • Reading route and limits
• Service matching, startup, and coordinated termination
  • 1. Objects, state, and lock domains
  • 2. Publication records work before invoking matching
  • 3. Candidate discovery, filtering, probe, and start
  • 4. Start failure has attachment and launch ownership to unwind
  • 5. Open ownership is independent of attachment
  • 6. Phase 1: make the affected graph inactive
  • 7. Phases 2 and 3: callbacks, finalization, stop, detach
  • 8. Concrete rematch fixtures and what they establish
  • Sources inspected and limits
• Service notifications, replay, and arbitration
  • 1. Four locks or protocols should not be conflated
  • 2. Installing a matching notifier also captures existing services
  • 3. Event selection and callback invocation have separate lifetimes
  • 4. Removal waits for other threads, with a self-callback exception
  • 5. Interest messages attach to one service
  • 6. A synchronous match wait is a temporary notification
  • 7. Arbitration tracks owners and breaks only permitted deadlocks
  • 8. Open/close serialize service policy and cooperate with termination
  • 9. Local examples and limits of the test evidence
  • Reading route and source-review limits
• User clients and DriverKit RPC
  • A connection is an exported kernel object
  • Opening a service creates or obtains a user client
  • External methods validate transport shape before driver behavior
  • Mappings and close have their own lifetimes
  • DriverKit retains a kernel-side object and transport layer
• User-client connections and DriverKit object lifetime
  • 1. Export identity and object ownership
  • 2. Opening a connection and entering a method
  • 3. Three different connection shutdown routes
  • 4. DriverKit message dispatch and object conversion
  • 5. Outbound RPC retains a destination and tracks message movement
  • 6. Remote user-client creation and stop completion
  • Reading exercise and limits
• External methods: connection admission, arguments and completion
  • 1. Keep the service, connection and calling task separate
  • 2. Open creates the client before all admission has completed
  • 3. The message describes bounded inline arrays and numeric user addresses
  • 4. Large buffers belong to the current call's address space
  • 5. Current-caller filtering precedes the client's method lock
  • 6. Dispatch validates a method contract, then calls its implementation
  • 7. Returning a method result does not undo published output
  • 8. Async completion has a separate right and resource lifetime
  • 9. Close, final call exit and object destruction are different events
  • 10. What the local test and this review establish
• DriverKit class dispatch, actions, and event sources
  • 1. Interface declarations become class and method metadata
  • 2. A dispatch queue is also a retained transport endpoint
  • 3. Dispatch uses object identity, server context, and method identity
  • 4. An action retains a target and translates one callback method
  • 5. Aborted delivery, cancellation, and completion are separate events
  • 6. Interrupt sources transfer counts from interrupt context to a consumer
  • 7. Source cancellation has a visible kernel portion and an external contract
  • 8. Service notifications combine pending arrays with retained registry objects
  • 9. Authorization precedes usable class and queue routing
  • Sources inspected and limits
• Shared data queues and asynchronous notifications
  • 1. Choose the queue by its actual contract
  • 2. Classic queues separate shared offsets from private allocation metadata
  • 3. Enqueue publishes a complete entry before moving the tail
  • 4. Dequeue validates a record before returning space to the producer
  • 5. A data-available message is a prompt to inspect memory
  • 6. The circular queue uses reader validation instead of producer backpressure
  • 7. Circular publication has both queue and entry commit points
  • 8. Circular readers must handle overwrite, reset and partial progress
  • 9. External-method completion is a separate Mach-message protocol
  • 10. DriverKit's queue has shared records and two action directions
  • 11. Tests expose specific invariants, not complete queue correctness
  • Inspection scope
• Workloops, interrupts, and power transitions
  • A workloop combines a worker with a lock
  • A command gate does not imply a thread switch
  • Interrupt handling has two stages
  • Power management is a queued state machine
  • Root-domain policy ends at the platform boundary
• Workloop execution, event lifetime, and power acknowledgments
  • 1. The gate and wakeup lock protect different invariants
  • 2. Membership, removal, and owner lifetime
  • 3. Interrupt arrival and deferred consumption
  • 4. Timer delivery has active and passive implementations
  • 5. PM requests, replies, and blocked state machines
  • 6. Driver return and driver acknowledgment can race
  • 7. PM stop blocks new calls and performs bounded coordination
  • Sources inspected and limits
• Interrupt routing, deferred handlers, and command ownership
  • 1. Resolve a provider-local index before discussing vectors
  • 2. Vector state is separate from device state
  • 3. Sharing inserts another controller and changes the nub's route
  • 4. A concrete CPU-controller boundary differs from generic hardware hooks
  • 5. Filtering and counted delivery cross execution contexts
  • 6. Command pools transfer retained objects through a gate
  • 7. The legacy command ring has a different capacity and completion model
  • 8. Read a driver's complete callback lifetime
• Device power states, parent dependencies, and transition completion
  • 1. A state index is not necessarily its power order
  • 2. Read the state as several independent coordinates
  • 3. A power-tree edge is an object with its own readiness and acknowledgment
  • 4. Parent power is negotiated as flags, then mapped back to states
  • 5. Self-initiated and parent-forced transitions have different sequencing
  • 6. Child and driver acknowledgments carry explicit ownership
  • 7. Distinguish acknowledgment timeout from hardware settling
  • 8. Removal and stop must release dependency state too
  • Sources inspected and limits
• System sleep requests, capability changes, and wake completion
  • 1. Power state, capabilities and progress are different state
  • 2. A public sleep request queues policy work
  • 3. Client notification is filtered by transition and recipient
  • 4. Reply cookies, timeout and cancellation advance the PM machine
  • 5. Filesystem sync runs before the constrained CPU phase
  • 6. Tasks, interested drivers and power children have ordered preparation
  • 7. The platform handoff changes scheduling and execution constraints
  • 8. Returning from machine sleep starts wake policy
  • Inspection scope
• Power assertions, sleep preventers and idle policy
  • 1. State holders and execution contexts
  • 2. Creating an ID, installing a record and publishing its effect
  • 3. Assertion bits select different mechanisms
  • 4. DriverKit closes the assertion-installation gap explicitly
  • 5. Sleep-preventer sets follow completed device capabilities
  • 6. Aggressiveness is coalesced settings delivery
  • 7. An idle timer releases a policy desire; it does not put the CPU to sleep
  • 8. Evidence, diagnostics and remaining boundaries
• Memory descriptors, mappings, and DMA
  • Three addresses and three different objects
  • Descriptor preparation acquires VM backing
  • CPU mapping is separate from DMA preparation
  • DMA commands prepare device mappings, not the source pages
• Memory descriptor composition and CPU mapping lifetimes
  • 1. Separate the objects before following a pointer
  • 2. Buffer descriptors select an allocation and release protocol
  • 3. Subranges and composite descriptors retain their constituents
  • 4. Named memory references preserve VM backing identity
  • 5. CPU mapping may return an existing object or a view
  • 6. VM allocation, page geometry, cache mode, and prefaulting
  • 7. Device-pager faults and two meanings of redirect
  • 8. Destruction breaks references at each layer
  • Sources inspected and limits
• DMA preparation, mapping ownership, and failure cleanup
  • 1. Read the state as several ownership ledgers
  • 2. Descriptor prepare: direction, UPL construction, and rollback
  • 3. Final descriptor completion owns the backing teardown
  • 4. Attaching a descriptor to a reusable command
  • 5. Direct iteration, sparse bounce pages, and full copying
  • 6. Device mapping can belong to the command or the descriptor
  • 7. Segment generation advances a bounded cursor
  • 8. Command completion and CPU maps remain separate
  • Sources inspected and limits
• DMA segment generation: descriptor offsets, physical runs, and device addresses
  • 1. Four coordinates and three separate operations
  • 2. The public call and the state it changes
  • 3. How descriptor classes enter the walk
  • 4. What must exist before enumeration
  • 5. Linear mapping versus padded mapping
  • 6. The generator is a lookahead iterator with constraints
  • 7. Continuation, output encoding, and nontransactional errors
  • 8. Where bounce addresses and payload copies enter
  • 9. A concrete DriverKit-facing caller and its completion
  • 10. Sources inspected and limits
• IOKit reporting and device-work performance accounting
  • 1. Reporting identifies a provider, channel and element
  • 2. Configuration and updates use different locks
  • 3. Enablement, dimensions and sample copying are separate operations
  • 4. Simple, state and histogram formats have different update semantics
  • 5. Performance control registers callbacks and preserves submitter identity
  • 6. End of a work interval is not necessarily final completion
  • Inspection scope

13. Authorization, audit and protected execution

• Security mechanisms and policy boundaries
• Credentials, authorization, and task rights
  • Identity is a referenced value
  • A concrete credential update
  • Kauth scopes and MAC hooks answer different questions
  • Task rights require acquisition and conversion checks
• Credential publication and authorization-policy lifetimes
  • 1. A credential is a shared value with two kinds of holdings
  • 2. Construction, deduplication, and retirement
  • 3. Taking a process credential reference races with replacement
  • 4. Process publication is a retrying compare-and-replace
  • 5. Thread identity caches preserve assumed identity
  • 6. Kauth listener aggregation has its own lifetime contract
  • 7. MAC registration divides stable and dynamic policy entries
  • 8. Check, grant, perform, and label ownership
  • Inspection scope
• Personas, process identity and external membership resolution
  • 1. Identify the subject before following a permission check
  • 2. Management: allocate privately, copy results, then publish
  • 3. Process adoption is a transition plus optional credential derivation
  • 4. Invalidation, dropping membership and thread vouchers
  • 5. Group membership: local positive, authoritative local negative, or resolver
  • 6. Identity translation has another cache and expiry policy
  • 7. Resolver work crosses a userspace boundary
  • 8. Configuration and verification routes
• Task and thread capabilities: acquisition, conversion and revocation
  • 1. Flavor describes the authority accepted by a conversion
  • 2. Objects and references at the boundary
  • 3. Acquiring a control right from a PID
  • 4. Name, inspect and read acquisition have different gates
  • 5. Input conversion checks type, association and policy
  • 6. A Mach VM request converts the capability into a map reference
  • 7. Output conversion consumes a reference and may return no usable right
  • 8. Lazy-port no-senders is separate from task death
  • 9. Identity tokens resolve identity without becoming unconditional authority
  • Configuration, tests and remaining boundaries
• ARM64 thread-state conversion and restoration
  • Three representations and two kinds of flags
  • Admission and stopping the target
  • Exported pointers and the selected diversifier
  • Import: replacement, authentication, and pointer poisoning
  • Exception replies retain an old state and caller-selected policy
  • Sigreturn: three checks with distinct inputs
  • Installing and signing the kernel saved state
  • Source tests and boundaries
• Code signing and platform policy
  • Three decisions to keep separate
  • Signature state belongs to the file-backed VM connection
  • A page fault checks bytes and mapping conditions
  • Trust caches and external policy
  • CSR/SIP is boot-derived configuration consumed by checks
• Signature format, CodeDirectory selection, and blob validation
  • 1. Three layers of data and three kinds of offset
  • 2. Code hashes, special-slot hashes, and CDHash differ
  • 3. Generic length validation is only the first layer
  • 4. Selection chooses a directory, not a certificate trust result
  • 5. Directory validation constrains geometry but leaves explicit semantic limits
  • 6. Special-slot validation binds auxiliary bytes to the selected directory
  • 7. Initial wrapper state is derived before full policy acceptance
  • 8. Reconstitution preserves needed evidence while changing storage
  • 9. Multilevel hashes are a constrained representation optimization
  • Sources inspected and limits
• Vnode signature attachment, revalidation, and destruction
  • 1. The UBC object owns a list, not a process-local signature cache
  • 2. The Mach-O loader acquires or reuses an attachment
  • 3. fcntl registration has different input and reuse rules
  • 4. The new blob passes through a staged ownership transfer
  • 5. Policy, monitor, and entitlement objects have separate results
  • 6. List compatibility and publication are a separate commit point
  • 7. Generation refresh and invalidation answer different questions
  • 8. Destruction waits for the vnode lifecycle and respects monitor ownership
  • 9. Supplemental signatures use a distinct single-attachment path
  • Sources inspected and limits
• From an attached signature to executable mappings and process policy
  • 1. State moves across several objects
  • 2. Execution access is checked before signature acceptance
  • 3. The loader accepts signature metadata before mapping segments
  • 4. Initial command bytes are validated separately from later faults
  • 5. Exec publishes process flags and performs final launch checks
  • 6. The external-signature route has narrower acceptance
  • 7. Mapping a library adds its own access and policy gates
  • 8. VM connects a signed file interval to a monitor region
  • 9. Failure and cache-reuse checkpoints
  • 10. Where the available implementation ends
• File-page signature validation and cached integrity state
  • 1. Four different kinds of validity
  • 2. How a file offset becomes a hash comparison
  • 3. When the cached result avoids hashing
  • 4. The optional vnode bitmap survives individual resident pages
  • 5. Mapping policy consumes all of the state
  • 6. Monitor association and executable page entry are separate stages
  • 7. Writes, COW and UPL completion change the cache
  • 8. Three cache histories through the same file
  • Sources inspected and boundaries
• Trust-cache admission, runtime ownership and lookup
  • 1. The entry points and the missing library boundary
  • 2. Three backends, three protection and reclamation contracts
  • 3. Typed dynamic loading: admission precedes authenticated publication
  • 4. Ordinary runtime: allocate outside the lock, publish under it
  • 5. PPL: the wrapper and bytes share a protected allocation
  • 6. TXM: retained payload pages versus a monitor-owned copy
  • 7. Query results are tokens, not executable mappings
  • 8. Boot caches use a physical range and offsets
  • 9. UUID checks, unloading and validation generations
  • 10. Inspection scope and remaining boundaries
• Process code-signing controls and ARM64 CSR policy
  • 1. State exists in the process, executable blob, task and VM map
  • 2. Syscall admission: identify the process before operating on it
  • 3. The complete command surface in this checkout
  • 4. Variable-length queries: an error can publish useful bytes
  • 5. XML and DER entitlement ownership differs
  • 6. Mutations are not uniformly transactional
  • 7. CSR on ARM64: initialize a boot policy, then consult it
  • 8. Allowance bits, reported configuration and effective checks
  • 9. csrctl is a read/check surface, not a setter
  • 10. Follow a bit into a real consumer
  • 11. Tests, inspection scope and unresolved policy
• Audit records and sessions
  • Selection begins before the operation
  • Commit transfers ownership and can wait
  • Sessions and control interfaces
• Audit selection, queue ownership, and output
  • 1. A record first belongs to a uthread
  • 2. Exit commits an outcome, not necessarily a record
  • 3. The worker drains batches outside the queue mutex
  • 4. Trail writes can trigger rotation, suspend, or fail-stop
  • 5. Rotation transfers vnode and credential ownership
  • 6. Audit pipes copy records and can lose them independently
  • 7. User-supplied BSM follows a separate selection contract
  • Inspection scope
• Audit sessions, credential adoption and Mach capabilities
  • 1. The ASID, credential and port refer to different objects
  • 2. BSD entry points create or update session identity
  • 3. Publishing a session capability
  • 4. Joining consumes a temporary kernel send right
  • 5. Empty sessions can remain joinable
  • 6. Session events, configurations and inspection limits
• SPTM, TXM, and Exclaves: security boundaries and entry/exit map
  • The mechanisms have different responsibilities
  • Detailed reading route
  • Kernel entry and exit points
  • Normal call completion differs from interrupt resumption
  • Exception levels, guarded execution, and configuration
  • How to assess the security claims in these guides
• SPTM: frame authority, protected transitions, and XNU's responsibilities
  • What is present, and what the build supplies
  • Bootstrap: establish the interface before ordinary VM initialization
  • Runtime calls: thread state, per-CPU buffers, and interrupt return
  • Frame types: physical-page policy distinct from a mapping's permissions
  • A mapping operation across the boundary
  • Epochs, table ownership, batches, and reuse
  • Root activation and protected I/O
  • Boot lockdown and panic lockdown are different transitions
  • Reading and auditing the boundary
  • Sources inspected and limits
• TXM: signatures, protected ownership, and executable mappings
  • 1. The boundary: what XNU implements and what it imports
  • 2. A TXM call: stack borrowing, register arguments, and shared results
  • 3. Shared memory: readable references and ownership transfer
  • 4. A signature's lifetime, from UBC input to final cleanup
  • 5. Address spaces, regions, and executable page enforcement
  • 6. Locking is part of the monitor contract
  • 7. Profiles, entitlements, trust caches, and policy controls
  • 8. Observability, reading route, and limits
• Exclaves: execution, resources, and security boundaries
  • Detailed reading route
  • One endpoint call crosses several layers
  • The objects are not interchangeable
  • Scope of the expanded reading
• Exclaves execution: traps, scheduler requests, upcalls, and interrupt return
  • 1. The two protocols and their storage
  • 2. Darwin userspace reaches an ordinary Mach trap first
  • 3. Authorization, readiness, and copying at the trap boundary
  • 4. IPC-buffer and scheduling-context lifetime
  • 5. An endpoint RPC is a resumable loop
  • 6. Per-CPU scheduler exchange and the secure entry boundary
  • 7. Waits, wakes, and priority donation
  • 8. Yield, spawn, and response handling limits
  • 9. Upcalls execute on the in-progress XNU thread
  • 10. Hardware interrupts resume SK through an assembly selector
  • 11. Stop completion and what “unwind” means here
  • 12. Boot establishes the data needed by every later transition
  • Reading route and inspected boundaries
• Exclaves resources, task attachment, and physical-memory ownership
  • 1. Resource identity includes a domain and type
  • 2. Resource ports bridge into ordinary Mach capabilities
  • 3. A conclave attaches to a task through a lifecycle protocol
  • 4. Physical-page donation keeps bookkeeping but changes authority
  • 5. Shared memory requires both service permission and a shareable frame type
  • 6. Copy, unmap, and release are separate transitions
  • Sources inspected and limits
• Exclaves services: what an upcall can ask XNU to do
  • Storage: a shared data buffer plus a separate file namespace
  • Sensors and arbitrated buffers
  • Driver upcalls resolve an IOKit proxy
  • Notifications leave the secure RPC through ordinary XNU event mechanisms
  • Always-on work is another rendezvous protocol
  • Inspection, panic, and source-navigation tools
  • Inspection depth

14. Boot, exception levels, CPU lifecycle and platform services

• Platform, boot, and machine execution
• Boot to PID 1
  • Choose the compiled entry path first
  • C initialization builds the environment for ordinary kernel code
  • STARTUP is an ordered registry, interleaved with explicit calls
  • BSD and the first userspace process
  • x86_64 comparison
• ARM64 bootstrap memory, ownership and lockdown
  • 1. Boot arguments describe supplied memory; they do not allocate it
  • 2. First translations and stacks precede ordinary kernel allocation
  • 3. Early table allocation is a physical cursor or image reservation
  • 4. Pmap stealing breaks the map/zone/page-descriptor dependency cycle
  • 5. Canonical page descriptors make the remaining frames allocatable
  • 6. Replacing CPU boot stacks must precede releasing their segment
  • 7. Static release disconnects aliases and may delay free-list publication
  • 8. Finalization and lockdown are related but separate operations
  • 9. Reading a later physical page back through boot
  • 10. Configuration, evidence and limits
• Exceptions, interrupts, and CPU execution
  • Follow one complete transition
  • Interrupts connect device callbacks and timer queues
  • CPU bringup and a context switch
• ARM64 exception entry: from a vector to a kernel operation
  • How the CPU finds these vectors
  • Structures and registers that carry the interrupted execution
  • EL0 entry: preserve the user stack pointer, then stop using it
  • Same-EL entry: the interrupted kernel stack stays meaningful
  • First-level synchronous handling and SPTM ordering
  • C dispatch: an SVC, a page fault, and a debug trap are different routes
  • Interrupt bookkeeping before the C callback
  • Sources inspected and limits
• ARM64 exception return: ASTs, continuations, and authenticated restore
  • Which execution is being resumed?
  • Changing the saved result or resume PC
  • Returning to EL1: only an eligible urgent preemption
  • Returning to EL0: pending ASTs can change the path
  • Authenticating precisely the values that will be restored
  • Finishing the restore without losing the mapping beneath it
  • Reading checks and limits
• ARM64 exception assembly: five instruction walkthroughs
  • Before following the instructions
  • 1. EL0 entry: use SP as a destination address, then replace it with a kernel stack
  • 2. EL1 SP0 entry: create a context below the interrupted stack pointer
  • 3. Spill first, then call C: follow the changing jobs of x0, x1, x21 and LR
  • 4. Returning is a loop over saved state, not a single ret
  • 5. Authenticate candidates, restore registers, and stop using the context address
  • Configuration boundaries and reading checks
• ARM64 user-memory access: copyin, copyout and fault recovery
  • 1. The objects are addresses, a map and a recoverable instruction range
  • 2. Validation separates a bad user argument from a kernel programming error
  • 3. PAN and tagged access surround the copy, including its error return
  • 4. The assembly exports both a copy routine and its recovery contract
  • 5. A page fault can complete the mapping or convert the access to EFAULT
  • 6. Strings and atomic words have different completion contracts
  • 7. Worked partial-copy example and caller responsibilities
  • Inspection boundary
• ARM64 thread switching, first entry, continuations and exit
  • 1. The objects and the three forms of saved state
  • 2. From a scheduler decision to the machine switch
  • 3. The C wrapper changes address space and extended context
  • 4. Switch_context: the complete register-transfer body
  • 5. Current-thread registers and conditional CPU state
  • 6. First dispatch: manufacture the return that has never happened
  • 7. Continuations discard a call chain, not the thread
  • 8. Stack handoff: execution continues while stack ownership changes
  • 9. Kernel entry, preemption and user return
  • 10. Termination: stop execution before reclaiming its storage
  • 11. Idle, CPU shutdown and architecture limits
• EL1, EL2, and Apple protected execution
  • Which path is actually present?
  • Architectural EL1 → EL2 → EL1 contract
  • A concrete guest hypercall
  • SPTM has a distinct, partly external transition interface
  • Legacy PPL: read the state machine, recognize the missing crossing
  • SMC and Mach exceptions are separate routes
  • What this page establishes
• Hardware mappings and pmap backends
  • Separate VM policy from installed translations
  • Follow one SPTM mapping installation
  • PPL is a different implementation boundary
  • TLB completion is part of correctness
  • Physical addresses, aperture addresses, and I/O mappings
• Platform services, power, and shared interfaces
  • Platform Expert connects early data to later drivers
  • Sleep and resume cross the same machine boundaries
  • Hibernation joins VM, storage, and restricted restore code
  • Commpage publishes selected kernel information to userspace
  • Virtualization interfaces are several different boundaries
• ARM64 CPU startup, offline, idle, and system sleep
  • 1. Initial startup establishes prerequisites in explicit phases
  • 2. Platform registration supplies CPU-specific callbacks
  • 3. Starting a CPU is serialized, but completion is asynchronous
  • 4. Warm entry restores an idle-thread context
  • 5. Offlining transfers execution to the reserved idle thread
  • 6. Timer migration and IPI draining precede power loss
  • 7. Ordinary idle saves context but keeps a different availability contract
  • 8. System suspend coordinates all CPUs and preserves time semantics
  • 9. Hibernation adds VM and image-provider boundaries
  • Inspection scope
• Hibernation image creation and polled I/O
  • 1. Three different kinds of state
  • 2. Prepare resources while blocking remains possible
  • 3. Flushing reduces the image; it is not the final snapshot
  • 4. A bitmap bit means exclusion, not inclusion
  • 5. Discard, metadata compaction, and scratch eligibility
  • 6. Image layout and page encoding
  • 7. Encryption has several distinct boundaries
  • 8. Polling replaces the ordinary completion environment
  • 9. Completion, errors, and what remains alive
  • Sources inspected and limits
• Hibernation restore: physical memory, VM state, and wake resources
  • 1. Restoration has several completion points
  • 2. Early restore starts with an image in physical memory
  • 3. Physical collisions are deferred without losing input
  • 4. Restore mappings differ from normal pmap operations
  • 5. SPTM reentry consumes restored state and borrowed handoff pages
  • 6. Rebuilding VM metadata before ordinary allocation
  • 7. Late restore reads all remaining page runs
  • 8. Normal-context cleanup and delayed file disposal
  • Sources inspected and limits
• x86 sleep, resume, CPU context, and time
  • 1. The caller supplies the hardware transition
  • 2. Temporary mappings bridge the wake entry
  • 3. Exactly what the sleep assembly saves
  • 4. Ordinary wake and image restore converge
  • 5. Image-writer outcomes are not identical to platform outcomes
  • 6. Absolute time is rebased before normal timer use
  • 7. CPU facilities are restored in a deliberate order
  • 8. Secondary CPUs have fast and full restart paths
  • 9. Deep idle is a different path
  • Sources inspected and limits

15. Paths and protocols across subsystems

• Operations across subsystem boundaries
  • 1. Open a file, then read it
  • 2. Map a file and fault its contents
  • 3. Fork and then exec
  • 4. Send and receive a Mach message
  • 5. Receive data and deliver readiness
  • 6. A user process asks a driver to operate on memory
  • 7. Memory pressure crosses from pages to processes
• A mapped file from descriptor lookup to an ARM64 private write
  • 1. Fix the addresses before following the code
  • 2. The fd disappears from the fault path
  • 3. MAP_PRIVATE establishes two distinct COW obligations
  • 4. The first read: user VA becomes an object request
  • 5. Pager dispatch and filesystem completion preserve the file coordinate
  • 6. Revalidation precedes the first CPU translation
  • 7. The private write changes the top object and the physical page
  • 8. Checkpoints distinguish failure, cleanup and persistence
  • 9. Reuse this trace when investigating a fault
• A user buffer from virtual memory to DMA completion
  • 1. Select the client address space before interpreting an address
  • 2. One unaligned descriptor, one smaller DMA interval
  • 3. Descriptor preparation resolves VM ownership before device use
  • 4. Command association adds a separate resource interval
  • 5. From three VM pages to addresses in a device domain
  • 6. genIOVMSegments advances a prepared-range cursor
  • 7. Hardware completion is an external prerequisite to memory release
  • 8. Keep a resource ledger at each return
  • 9. What this operation establishes
• One Skywalk channel operation: descriptors, mappings, packets and readiness
  • 1. Name every identity before tracing the first packet
  • 2. Open publishes several things before the application gets a handle
  • 3. Skywalk reaches VM through an actual IOKit mapping implementation
  • 4. Publishing the user head does not yet transfer a slot
  • 5. Follow the test's two batches through backpressure
  • 6. Readiness can perform synchronization
  • 7. Close unwinds the fd, mapping and peer graph separately
  • 8. Failure checkpoints and evidence limits
• From a Mach-O executable to a runnable image
  • The input and result contracts
  • Build a new map before publishing it
  • Parse load commands in four passes
  • Segments connect the executable to VM
  • Signature handling precedes decisions based on it
  • The first user instruction may belong to dyld
  • Reading and verification limits
• Ownership, synchronization, and execution context
  • Four different guarantees
  • References are subsystem-specific protocols
  • A handle may be recycled
  • Locks often protect fields, not entire objects
  • Registering a wait is a state transition
  • Dropping a lock creates a revalidation obligation
  • Execution context constrains the path
  • Atomics, sequence counters, and deferred reclamation
  • A useful final check
• SMR, pointer publication and deferred reclamation
  • Domain, reader and callback state
  • Entering and leaving a non-preemptible reader
  • Pointer publication and list removal
  • How a grace period is detected
  • Sleepable readers become scheduler-visible dependencies
  • Deferred callbacks are batched separately from reader progress
  • synchronize and barrier answer different questions
• SMR hash tables: lookup, migration and storage retirement
  • 1. Keys, intrusive links and client-defined lifetime
  • 2. Two table layouts and synchronization contracts
  • 3. Insertion, duplicate races and removal
  • 4. Shrinking a simple table joins existing chains
  • 5. Growing a simple table needs repeated reader grace periods
  • 6. Scalable lookups detect a chain that migrated
  • 7. Scalable mutations lock one bucket, then follow migration
  • 8. Growth, shrink and reseed are scheduled policy decisions
  • 9. Scalable rehash moves nodes before retiring the array
  • 10. Real clients and teardown obligations
  • 11. Local checks and limits
• Completion, cancellation and partial failure across subsystems
  • The questions to ask at every handoff
  • Mach RPC: a receive retry must not resend the request
  • Socket I/O: local acceptance, remote acknowledgment and copyout
  • A copyout failure sometimes preserves the result
  • Writeback: the device result is not the last cleanup step
  • DMA and channels: publishing addresses is not completing their use
  • Cancellation removes a particular kind of pending work
  • Teardown closes discovery, drains users and releases storage
• Concurrent operations: revalidation, namespace death and callback teardown
  • 1. A physical VM copy meets a replacement destination mapping
  • 2. IPC table growth meets namespace termination
  • 3. A workqueue call rearms while its owner begins exit
  • 4. What the local tests establish, and what this chapter leaves open

16. Build, tests and observation

• Build selection, generated code, and tests
  • A source tree is larger than one kernel
  • How to decide whether a file is present
  • Generated source is part of the interface
  • Build products and environment boundary
  • Five useful test layers
  • Tests as executable explanations
  • Sources inspected and limits
• An ARM64 configuration and MIG contract walkthrough
  • 1. Fix the inputs before interpreting a guard
  • 2. doconf selects one architecture master, then expands attributes
  • 3. Source selection and header generation take different routes
  • 4. The selected VM server is generated from a declaration
  • 5. MIG types express capability and untrusted-data contracts
  • 6. The build-time adoption check has a precise limit
  • 7. A mach_vm_read request reaches three independent checks
  • 8. Map cleanup and copy transport end different lifetimes
  • 9. What local tests and missing artifacts establish
• Tracing, accounting, debugging, and diagnostics
  • Map the question to the mechanism
  • ktrace controls; kdebug records
  • kperf: trigger, action, sample
  • Recount: accounting tied to execution transitions
  • Stackshot and kcdata
  • Debugger navigation
  • Sysctl: a typed control tree with handler lifetimes
  • Other instrumentation and diagnostic paths
  • Sources inspected and limits
• Kdebug storage, timestamp merging and consumer readout
  • 1. The objects between an event site and a reader
  • 2. Session ownership, allocation and enabling
  • 3. Admission before touching a storage unit
  • 4. Reservation is not a post-payload publication counter
  • 5. Allocating, wrapping and recording a gap
  • 6. Coprocessors, delayed timestamps and flush callbacks
  • 7. Reading a bounded interval while producers continue
  • 8. Copyout, direct file output and partial failure
  • 9. Worked interleavings and loss examples
  • 10. Disable, reset, boot and wake lifetimes
  • 11. Configuration and tests mapped to mechanisms
  • 12. Reading route and remaining boundaries
• DTrace providers, validated actions and consumer lifetime
  • 1. A probe ID, an enabled probe ID and a consumer are different identities
  • 2. Registration supplies sites; open establishes authority and state
  • 3. ENABLE copies DOF, validates DIF and may leave partial attachment
  • 4. GO activates recording; STOP does not dismantle the provider
  • 5. The ARM64 syscall provider interposes a real dispatch slot
  • 6. Firing runs with interrupts disabled and commits one ECB at a time
  • 7. DIF has temporary execution state, persistent storage and fault reporting
  • 8. Recording, aggregation and wakeup have separate completion points
  • 9. A switched snapshot is consumed before copyout can fail
  • 10. Close retracts descriptions, detaches ECBs and releases storage
  • 11. Evidence, failure checkpoints and remaining scope
• Sanitizer runtime, allocator hooks, and reporting
  • 1. Establish the compiled model before interpreting a report
  • 2. Shadow bytes describe virtual ranges
  • 3. Access callbacks, memory wrappers, and inline failures
  • 4. Classic allocation state and delayed reuse
  • 5. TBI allocator hooks use software tag storage
  • 6. Suppression and reporting depend on the entry path
  • 7. Full UBSAN records sites; minimal UBSAN handles traps
  • 8. Local tests and verification boundaries
• Coverage instrumentation: device, thread and buffer lifetime
  • 1. Runtime availability and compiler instrumentation are separate
  • 2. The device is a control endpoint, not the trace itself
  • 3. Configuration selects one primary representation
  • 4. The mapping ioctl installs a shared VM alias
  • 5. Attachment holds a thread reference; start only changes a bit
  • 6. Compiler callbacks pass context and recursion gates
  • 7. Trace head reserves space before the record is written
  • 8. Detach and close establish different lifetime boundaries
  • 9. On-demand gates control callback invocation, not attachment
  • 10. What the supplied tests establish
• Kernel logging: encoding, retry queues, Firehose and live readers
  • 1. Separate the three outputs and their objects
  • 2. Admission, execution context and log identities
  • 3. From a format string to a binary payload
  • 4. The small allocator backing encoding and retry storage
  • 5. Retry queues: copied data, movable execution and delayed reclamation
  • 6. Firehose chunks: reservation is not publication
  • 7. The Firehose reader uses mapping and feedback
  • 8. Live streaming: reservations, wraparound and reader isolation
  • 9. Message-buffer text, unsafe replay and dmesg
  • 10. Other producers, failures and evidence limits
• Stackshot capture, parallel collection and kcdata records
  • 1. Entry separates permission, request validation and capture
  • 2. A capture owns preallocated memory and global/per-CPU state
  • 3. Preflight selects a collection mode
  • 4. Parallel queue completion is different from an empty queue
  • 5. kcdata is a typed stream with explicit capacity and padding
  • 6. Capacity failure, retries and output ownership
  • Inspection boundary
• Corpses, crash information and process core files
  • 1. Separate the artifact from the event that produced it
  • 2. Corpse admission reserves resources before building objects
  • 3. Full corpse construction transfers several kinds of ownership
  • 4. Lightweight capture owns a data object and exception rights
  • 5. Process core creation starts with the current execution context
  • 6. VM regions become segment commands and file bytes
  • 7. Completion is not identical to persistence or crash reporting
  • Inspection boundary
• ARM64 panic coordination and persistent diagnostic records
  • 1. Entry records intent before collecting diagnostics
  • 2. Two ownership decisions protect the panic path
  • 3. CPU synchronization has acknowledgments, timeouts and fallback
  • 4. The panic region is a bounded record with offsets and a checksum
  • 5. Extensible logs reserve storage before the failure
  • 6. Failure paths are part of the diagnostic contract
  • Inspection boundary
• Building and maintaining the HTML handbook
  • Source checkout
  • Build and open
  • Reading tools
  • Structure layout inputs
  • Updating Markdown and source
  • Build components
  • Offline ZIP packaging
  • Documentation license
  • Compact static storage
  • Verification limits

Listed: 350 pages, excluding this contents page.