Philosophy

The goal is not to predict every failure. It is to have a response ready when one matters. Everything else in this project follows from that premise.

The kernel is the trust boundary

Wrong Boot chooses the kernel as its event-detection and enforcement boundary because the events it cares about can occur before reliable user-space response is possible.

User space may be:

• Unavailable,
• Compromised,
• Intentionally stopped or
• Simply too late to respond.

For that reason, trigger detection lives entirely in kernel space and relies on existing kernel subsystems rather than long-running daemons or polling loops.

This does not mean that the kernel is assumed to be universally trustworthy or that kernel-space execution is inherently secure.

The kernel provides the detection and execution mechanism. The configured action crosses back into user space deliberately.

This boundary and its consequences and limitations are described in more detail in security model.

Detection and execution are different concerns

Triggers answer exactly one question:

Has a condition been met?

They do not decide:

• What should happen,
• When it should happen,
• Whether another trigger should win,
• Whether execution remains available.

Those responsibilities belong exclusively to the core.

Keeping triggers detection-only makes them easier to understand, audit and extend without affecting execution behavior.

The implementation details of this model, including the activation latch and workqueue execution path belong in development.

Nominal assumptions

Wrong Boot should depend on as few assumptions about the surrounding system as practical.

Every additional moving part is something that can break, add latency, or get noticed. The module relies only on kernel interfaces already present in a stock build: input notifiers, the USB core, netfilter and standard userspace-helper invocation for execution. No daemons, no third-party libraries, no configuration format beyond module parameters. This keeps the design portable and keeps the amount of code running with kernel privileges small enough to actually read.

This does not imply that Wrong Boot has no dependencies or limitations. Kernel APIs, subsystem behavior, module-loading policy, hardware, configuration and user-space execution all impose constraints.

The principle is instead to make those dependencies clear-cut rather than hiding them behind implicit assumptions.

Fail-closed robustness

Wrong Boot prefers refusing to operate over silently accepting ambiguous, incomplete or partially valid configurations.

Configuration is therefore validated before the module becomes active and trigger initialization is treated as part of the module's overall readiness.

If the module cannot establish the conditions required for its configured operation, it should not silently continue with only part of that configuration active.

This principle exists because a partially functioning trigger system can create a false sense of protection or predictability.

Fail-closed behavior does not mean that every runtime failure can be prevented. It simply means that known initialization failures should not be converted into apparently successful operation.

Predictability over cleverness

Wrong Boot rewards designs that are easy to reason about.

The project therefore favors:

• Clear ownership
• Clean state transitions
• Strict configuration
• Nominal coupling
• Straightforward control flow
• Well-defined lifecycle behavior

over code that is clever, opaque, tightly coupled or unnecessarily generalized.

This principle applies especially strongly to trigger implementations. A trigger should make it obvious what event it observes, what condition it evaluates and when it requests activation.

Extensibility without coupling

Supporting a new event source should require implementing only that trigger.

Existing triggers should not need to change.

Likewise, changes to execution policy should not require modifying trigger implementations.

This separation allows the project to grow without increasing coupling.

The specific trigger interface, lifecycle contract and contributor requirements are documented in development.

The operator decides

Wrong Boot does not prescribe what the configured action should accomplish. It defines when execution may occur, not what the operator ultimately chooses to execute.

Whether the configured action archives evidence, sends an alert, locks a system, initiate a recovery procedure, destroys data, or performs something entirely different is outside the module's scope.

The project provides the mechanism. The operator defines the policy.

This separation also prevents trigger implementations from becoming coupled to a particular operational purpose.