# LCS and sources _Peios / Using Peios / Administration_ > Underneath, the registry is two components — LCS, the kernel authority, and userspace sources that only persist data, with loregd as the default. Every page until now has treated the registry as a single thing, and that was the right altitude to learn the model. This page pulls it apart, because at the implementation level "the registry" is two cooperating components — and the division between them is clean, deliberate, and worth knowing once the concepts are solid. ## The split, in one sentence **The registry is a kernel subsystem (LCS) that is the sole authority for the data model, access control, layer resolution, and change notification — plus one or more userspace *sources* that do nothing but persist and return data; the base source, `registryd`, is `loregd` by default and backs the `Machine` and `Users` hives.** ## Who does what The dividing line is sharp, and it is the principle the whole design rests on: **the kernel decides meaning; sources only store.** | The kernel subsystem (LCS) owns | A source owns | |---|---| | The data model — keys, values, types | Persisting entries to disk and returning them | | Path resolution and routing | Nothing about *who* is asking | | [Access control](/peios/using-peios/registry-security/access-control.md) — running AccessCheck | No security decisions at all | | [Layer resolution](/peios/using-peios/registry-layers/layers.md) — choosing the effective value | No idea which write is effective | | [Watch](/peios/using-peios/registry-concepts/watches.md) dispatch and transaction coordination | Executing storage operations it is told to | A source never sees a caller's identity, never evaluates a security descriptor, and never resolves a contest between layers. It stores writes tagged with layer names and hands *all* of them back when asked; the kernel does the deciding. That is why earlier pages could say "the registry checks", "the registry resolves" — it is always the kernel doing it, never the store. ```mermaid flowchart LR P["Any process"] -->|registry system calls| L["LCS (kernel): access control, layer resolution, watches"] L -->|private protocol| S["Source — e.g. loregd (userspace): storage only"] S --> DB["On-disk database"] ``` Userspace never talks to a source directly. Every registry operation goes through the kernel; the source talks only to the kernel, over a private protocol on a dedicated device. This is what lets the registry carry the same identity model, access control, and auditing as everything else — the kernel is unavoidably in the path. ## Why split it this way Storage is a separable concern. Putting it in userspace means the backing store can be replaced, or different stores can back different hives, without changing the kernel — and the store can be developed, tested, and hardened as an ordinary (if privileged) service. The kernel keeps the parts that *must* be trusted and uniform — the data model and the security model — and delegates the part that is "just a database". Hives are how the work is parcelled out: each hive is backed by exactly one source, and a source may back several hives. In practice the base source registers `Machine` and `Users`; other sources could register additional hives. ## The base source: registryd The standard hives have to exist before anything can read configuration, so one source is always started at boot. **`registryd` is that base source — the registry store [peinit](/peios/using-peios/services-and-jobs/overview.md) starts in early boot**, and the first thing to register hives with LCS so the rest of startup has configuration to read. Its interface is deliberately minimal: one `HiveName=path` argument per hive, naming the hive and the on-disk database that backs it. ``` registryd Machine=/var/state/registry/machine.regdb Users=/var/state/registry/users.regdb ``` That is the whole of its configuration — `registryd` *is* the configuration store, so it takes what it needs from its arguments rather than from a config file of its own. `registryd` is a **role**, not a fixed program. `loregd` — the Local Registry Daemon, which backs each hive with a SQLite database — is the **default** implementation, and the one running on a stock system. But the name is a swappable slot: another source can ship a `registryd` claim, and installing it puts that source in loregd's place with no change to anything that depends on the registry. Whatever holds the role starts the same way and answers to the same name. (Writing an alternative source is a developer task — the [Peios SDK](/peios/developing-for-peios/registry-sources/overview.md) covers the protocol one speaks to the kernel.) ## The trust boundary It is worth being blunt about the security boundary, the same way the rest of these docs are. **A source is part of the trusted computing base.** The kernel runs AccessCheck, but it runs it against the security descriptor the *source* hands back — so a compromised source can return a permissive SD for a key and cause access that should have been denied, or fabricate the precedence of a layer and tilt every contest in the system. The kernel validates that a source's responses are *structurally* well-formed and rejects malformed data, but it cannot detect a well-formed lie. This is not a gap so much as a fact about where the boundary is: trusting the store to tell the truth about what it stores is inherent in having a userspace store at all. The mitigations are operational — a source runs with tightly scoped privileges, is protected by the security descriptors on its own service definition, and is managed as a critical service (with process-integrity protection where available). The honest summary is: the store is small, privileged, and trusted, and protecting it is part of protecting the system. ## Two operations the kernel coordinates Two registry capabilities are the kernel *orchestrating a source* rather than features of the data model: atomic [transactions](/peios/using-peios/registry-advanced/transactions.md), and [backup and restore](/peios/using-peios/registry-administration/backup-and-restore.md). In both, the source does the storage work — committing a batch atomically, or reading out and replacing a subtree — while the kernel coordinates it and enforces the rules around it. Each has its own page; the point here is only that the same division of labour holds: the kernel decides, the source stores. ## When a source goes away Because the store is a separate process, it can crash or restart. When a source goes down its hives become unavailable: open key handles stay valid (they hold identity and a granted mask, neither of which needs the store), but operations that need to reach the store return an error until it is back. [Watches](/peios/using-peios/registry-concepts/watches.md) stay armed across the outage, and when the source re-registers, watchers receive an overflow so they re-read and resynchronise. The registry treats a store restart as a disruption to recover from, not a reason to lose state. ## Where to go next You have now seen the whole model — data, meaning, layers, security, change notification, and the parts underneath. For the tool you will reach for most when configuring a system — looking up what any key or value means — read [The registry manual (regman)](/peios/using-peios/registry-administration/regman.md). Three advanced topics remain: For grouping several writes into one all-or-nothing change — how a role installs without ever being half-applied — read [Transactions](/peios/using-peios/registry-advanced/transactions.md). For complete per-caller isolation — hives and layers visible only to one sandboxed process — read [Private hives and layers](/peios/using-peios/registry-advanced/private-hives-and-layers.md). For keys that point at other keys — the one place the registry follows a value — read [Registry links](/peios/using-peios/registry-advanced/registry-links.md). Related content: - [The registry](/peios/using-peios/registry-concepts/overview.md) - [Layers](/peios/using-peios/registry-layers/layers.md) - [Access control on keys](/peios/using-peios/registry-security/access-control.md) - [Backup and restore](/peios/using-peios/registry-administration/backup-and-restore.md) - [How the registry boots and configures itself](/peios/using-peios/registry-administration/bootstrap-and-self-configuration.md) - [Transactions](/peios/using-peios/registry-advanced/transactions.md) - [Private hives and layers](/peios/using-peios/registry-advanced/private-hives-and-layers.md) - [Registry links](/peios/using-peios/registry-advanced/registry-links.md)