System Logging (klog)

What is it?

klog is the kernel log every subsystem writes through: a level (LOG_DEBUG to LOG_FATAL), a subsystem tag ("net", "fs", "mm" and so on) and a formatted message. Each entry goes to an in-memory ring buffer, serial output and the boot framebuffer and, once a filesystem is mounted, to log files under X:\Logs\ (or C:\Impossible\System\Logs\ when the BlackBox partition is not mounted). A related surface, ETW (Event Tracing for Windows), gives providers a structured tracing channel. klog is the primary tool for diagnosing boot failures and panics.

How does it work?

klog starts in two stages that match the boot phases. klog_early_init() runs in Phase 0 before the VFS exists and starts only the 1000-entry ring buffer (KLOG_RING_SIZE in klog.h) and serial output. klog_disk_enable() runs in Phase 2 once a filesystem is mounted: it opens the log files, replays crash-recovered entries and starts disk flushing.

Every klog() call goes through one path. It checks a per-subsystem verbosity override (a 32-entry table read under a seqlock), applies a per-subsystem rate limit (32 slots, a 1000 ms window, 100 messages by default), and stamps a surviving entry with the CPU, PID and TID before writing it to the ring, serial and framebuffer.

On disk, a flush writes each entry to kernel.log and, through an 18-entry tag-to-file table in klog_disk.c, to one of six subsystem files (network.log, boot.log, fs.log, mm.log, drivers.log, security.log); an unmatched tag goes to kernel.log only. The same flush writes each entry as one JSON object per line to X:\Logs\events.jsonl. These files rotate once they pass a size threshold (4 MB by default), keeping 3 generations by default (at most 9). Rotated generations are LZ4-compressed to .N.lz4 by default, with a CRC32 and a staged rename, so a failed compression falls back to a plain .N.

A separate path survives a panic. klog_crash_persist() copies the newest ring entries, with no heap or VFS use, into a 128 KiB region reserved with pmm_alloc_contiguous() (KLOG_CRASH_PAGES) whose address is kept in a UEFI NVRAM variable. On the next boot, klog_crash_recover() validates the region's magic and CRC32 early in Phase 0 and replays it to serial with a [CRASH-PREV] prefix; once the VFS is up, klog_crash_write_to_disk() writes the entries to X:\Crash\crash_recovery.log.

ETW starts in Phase 3: etw_init() and etw_register_ssdt() register seven NtTrace* system calls at service numbers 0x01D0 to 0x01D6 (etw.h). Up to 8 sessions (ETW_MAX_SESSIONS), each with a 4 KB circular buffer, share one spinlock, and every handler copies user data in before taking it.

What are its interfaces?

How do I use it?

klog runs on every boot; there is nothing to enable.

bash scripts/test.sh SUITE=boot    # klog and LZ4 tests in test_klog.c
bash scripts/test.sh SUITE=abi     # the ETW tests, also in test_klog.c

After boot, X:\Logs\kernel.log holds every entry, the six subsystem files hold their tagged subset, and X:\Logs\events.jsonl holds the same stream as JSON Lines, readable with jq. Quiet a noisy subsystem with klog_set_level("net", LOG_ERROR) or persist that through HKLM\SYSTEM\Logs\Levels\net. After a panic, the next boot shows [CRASH-PREV] lines on serial and writes X:\Crash\crash_recovery.log. The tests are in test_klog.c.

What is not implemented yet?

• Tamper-evident, HMAC-chained events.jsonl entries are designed but not built; where the verifier key is anchored (TPM NVRAM or protected UEFI NVRAM) is an operator decision that blocks the work (Log Integrity Verification).
• ETW provider registration and per-session keyword and level filtering are not built: NtTraceEvent writes to the one session its handle names, and kernel events emitted by etw_emit_kernel_event() go to every running session unfiltered (ETW Provider Registration and Session Filtering).
• ETW stack-walk capture, a boot-persistent autologger and self-describing schemas wait on the provider model (ETW Advanced Capture).
• Section 2 of the roadmap still has open items, and several hardening items in sections 14 to 17 are parked on the kernel image-size ceiling (System Logging roadmap).
• The rate limiter fails open when its 32-slot table is full; a per-CPU lockless redesign is planned in Kernel Logging v2.
• Remote syslog forwarding is owned by Syslog Forwarding.

How does it compare with Windows 11 and Linux?

klog matches both on the core surface: a unified kernel log, five severity levels, per-subsystem files and verbosity, size-based rotation, rate limiting, CPU, PID and TID context per entry, and crash-persistent capture in reserved memory (comparable to Windows minidumps or Linux pstore). Its events.jsonl is readable as text, unlike the Windows Event Log's binary format, and parseable by tools, unlike the binary systemd journal; compressed rotation has no Windows equivalent.

It is behind Windows on ETW, where provider registration and session filtering are standard, and behind both on remote forwarding (Windows Event Forwarding, rsyslog). Tamper-evident logging would go beyond both, since the Windows Event Log has no built-in sealing and journald's Forward Secure Sealing is optional, but it is not built yet.

See also

• System Logging roadmap
• BlackBox Service Partition
• Kernel Embedded Libraries