Zircon is the core that powers Fuchsia. It is composed of a kernel and a small set of userspace services, drivers, and libraries necessary for core system functions such as booting.
Although Zircon applies many of the concepts popularized by microkernels, it does not strive to be minimal. Instead, the microkernel architecture of Zircon enables Fuchsia to reduce the amount of trusted code running in the system to a few core functions:
{: width=“799”}
User space code interacts with the objects in kernel space using system calls. Zircon has system calls to perform low-level operations such as:
User space processes access system calls through libzircon.so — a virtual Dynamic Shared Object (vDSO). The Zircon vDSO is a shared library in ELF format that the kernel maps into the address space of each new process. This library is considered “virtual” because it is exposed directly by the kernel image rather than being loaded from a file.
Most system calls operate directly with one or more handles — process-local references to objects living in kernel space represented as a 32-bit integer (zx_handle_t). Each handle declares the privileges, or rights, the holder has to perform actions on the handle itself or the referenced object.
Zircon exposes three main kernel objects for running code:
![Tree diagram illustrating Fuchsia's process hierarchy. Processes are grouped into jobs, which are ultimately owned by the Root Job.] (images/processes-jobs.png){: width=“549”}
Processes form the basis for system capabilities. Each process is granted a set of capabilities through the various handles it holds.
Fuchsia software may or may not run within the confines of a single process. Jobs allow “applications” that are composed of more than one process to be controlled as a single entity.
Since processes are isolated by default, the kernel needs to provide a way for them to securely communicate with each other. Zircon includes the following kernel object types for inter-process communication (IPC):
Among these objects, channels are uniquely suited to assist in launching new processes because they are capable of transferring handles (and therefore, capabilities) across to another process.
Channels have exactly two endpoint handles, each owned by a separate process. Only the owners may read or write messages, but ownership of an endpoint may be transferred from one process to another. When handles are written into a channel, they are removed from the sending process. When a message with handles is read from a channel, the handles are added to the receiving process.
![Diagram showing how processes communicate through shared objects found in the kernel. The most common of these connections is the channel.] (images/ipc.png){: width=“582”}
Note: You can find more of Zircon's deep technical details in the kernel documentation.
Zircon channels are the basis for service-level IPC protocols described by the Fuchsia Interface Definition Language (FIDL). FIDL protocols are the primary method of IPC used by Fuchsia programs. You will explore creating and consuming FIDL protocols in more detail later on.
Let‘s explore some of these fundamental concepts on a running system. In this exercise, you’ll see how jobs and processes interact to form a tree.
<<../_common/_start_femu.md>>
From the device shell prompt, you can use the ps command to dump the list of running jobs and processes.
ps
Below is a trimmed example of what the output looks like:
TASK PSS PRIVATE SHARED STATE NAME j: 1027 507.8M 507.4M root p: 1061 564.4k 564k 36k bin/bootsvc p: 1150 4264.4k 4264k 36k bin/component_manager j: 1479 228.4k 228k p: 1583 228.4k 228k 36k pwrbtn-monitor.cm j: 1484 532.4k 532k p: 1599 532.4k 532k 36k svchost.cm j: 1544 402.4k 304k p: 1633 402.4k 304k 232k netsvc.cm j: 1681 296.4k 296k p: 1733 296.4k 296k 36k console-launcher.cm j: 1799 7232.4k 7232k p: 1825 7232.4k 7232k 36k archivist.cm j: 1927 660.4k 660k p: 1955 660.4k 660k 36k base-resolver.cm j: 2072 1016.4k 1016k p: 2088 1016.4k 1016k 36k driver_manager.cm j: 2239 348.4k 348k p: 2252 348.4k 348k 36k device-name-provider.cm j: 2364 275.3M 275.3M p: 2380 1012.4k 1012k 36k fshost.cm p: 6544 252.1M 252.1M 36k /pkg/bin/blobfs p: 10205 9744.4k 9744k 36k /pkg/bin/minfs p: 10475 12.8M 12.8M 36k pkgfs
Let's focus on two columns in the output for now:
j) or process (p) followed by their unique id.Let‘s break down some interesting things here based on what we’ve discussed so far:
root job as the ultimate parent, forming a tree.root job. Most other processes are launched under their own parent jobs..cm extension. These refer to components, and you will learn more about them later on.fshost.cm) and drivers (driver_manager.cm) that live in user space separate from the kernel.Next, we‘ll explore how the Zircon enables the fundamentals of Fuchsia’s security model.