These docs are under active development and cover the v0.20 Kobicha security model.
§1.1 1 Introduction

Scope

This specification defines loregd (Local Registry Daemon), the primary registry source for the Peios operating system. loregd implements the Registry Source Interface (RSI) defined in PSD-005, providing persistent storage for one or more registry hives using SQLite.

loregd is the first and reference source implementation. Any process implementing the RSI contract can serve as a registry source; loregd is not architecturally special. It is operationally special: it is the source that provides the Machine\ and Users\ hives at boot, making it the critical path to a running system.

This specification covers:

  • The command-line interface and startup sequence
  • The SQLite database schema (one database per hive)
  • Volatile key storage via attached in-memory databases
  • Connection pool model and concurrency
  • Transaction handling and write serialisation
  • Crash recovery (orphaned GUID cleanup)
  • First-boot initialisation (hive root creation)
  • The RSI request processing loop
  • Case-insensitive storage via stored folded forms
  • Shutdown and hive unload behaviour

This specification does not cover:

  • LCS (the kernel subsystem) -- PSD-005
  • The RSI binary protocol (wire format, message framing, op codes) -- PSD-005 §7 and §11.3
  • Registry key schemas (those belong to the subsystems that own them)
  • Other source implementations
  • peinit's service management of loregd (PSD-007)
§1.2 1 Introduction

Terminology

Terms defined in PSD-005 (LCS, RSI, hive, source, key, value, layer, SD, AccessCheck, token, SID, GUID, watch, TCB) are used here with the same meaning and are not redefined.

Additional terms specific to loregd:

  • Hive database: A SQLite database file backing one hive. Each hive registered by loregd has its own database file. The file path is provided on the command line.

  • Volatile store: A SQLite in-memory database (:memory:) ATTACHed to a hive database connection. Volatile keys are stored here. The volatile store is lost when loregd exits.

  • Folded name: The Unicode Simple Case Folded form of a key name, value name, or child name. Stored alongside the canonical (case-preserving) name for case-insensitive lookups.

  • Read connection: A SQLite connection used for read-only operations. Multiple read connections may be open concurrently (WAL mode).

  • Write connection: A SQLite connection used for mutating operations. Only one write connection exists per hive database. All writes are serialised through this connection.

§1.3 1 Introduction

Conventions

This specification conforms to PSD-001.

This specification uses the same normative keywords (MUST, SHOULD, MAY) as PSD-005, per RFC 2119.

SQL examples use SQLite syntax. Column types use SQLite's type affinity system (INTEGER, TEXT, BLOB, REAL). All SQL is illustrative -- the schema is normative, the exact DDL is guidance.

loregd is specified against SQLite. The specification names SQLite features (WAL mode, ATTACH, SAVEPOINT, PRAGMA) directly. An implementation using a different storage engine would need to provide equivalent semantics but is not the target of this spec.

§1.4 1 Introduction

Prior Art

§1.4.1 SQLite

loregd uses SQLite as its storage engine. SQLite provides the transactional semantics, WAL-mode concurrency, and crash recovery that loregd relies on. loregd is specified against SQLite directly — the schema, concurrency model, and operational behaviour all name SQLite features (WAL mode, ATTACH, SAVEPOINT, shared-cache URIs, PRAGMA).

An alternative storage engine would need to provide equivalent semantics but is not the target of this specification.

§1.4.2 Windows registry hive format

The Windows registry stores hives as binary files (REGF format) managed directly by the kernel's Configuration Manager. loregd diverges from this model entirely: storage is in SQLite databases managed by a userspace daemon, not kernel-managed binary files. The data model (keys, values, SDs) is shared via the LCS specification (PSD-005), but the storage format has no relationship to REGF.

§1.4.3 LCS RSI contract

loregd implements the Registry Source Interface defined in PSD-005 §7. The RSI defines the operations, message format, error model, and source obligations. loregd's request handling (§5.1) is a direct mapping of RSI operations to SQLite queries. The RSI contract is normative for loregd's wire behaviour — where this specification and PSD-005 §7 disagree, PSD-005 §7 is correct.