randomparity / randomparity/kdive

Add the BYO control plane: SysRq force-crash and OOB power

Open
#1,827 0 comments 0 reactions 0 assignees View on GitHub
area:control-retrieve area:security effort:M priority:P1 provider:baremetal-bmc provider:powervm status:blocked type:feature
Dominant language
Python
Stars
0
Forks
0
Avg merge
1h 26m
Merged PRs (30d)
311

Description

Part of #1814

## Problem

Two control operations complete the BYO spine, and both need the pieces built above them:

- **Power** — `Controller.power()` is a required port. On an adopted host the only reliable answer
is the OOB driver, since a wedged kernel will not honor an in-band request.
- **Deliberate crash** — force-crash is what KDIVE exists to do. On real hardware it is magic SysRq
injected through the serial console, which is why this depends on the console plane rather than
the driver alone.

Deliberately crashing a physical machine is more consequential than crashing a VM: there is no
hypervisor to reset it, and recovery runs through the same OOB path. The existing destructive-op
gate applies unchanged and must not be weakened.

## Evidence

- `src/kdive/providers/ports/lifecycle.py:251` — `Controller.power()`, whose docstring already
anticipates `TRANSPORT_FAILURE` "when a remote provider's control channel cannot connect".
- `src/kdive/security/authz/gate.py` — `force_crash` requires the allocation project's RBAC role
**and** an explicit profile opt-in (ADR-0130 removed the old `capability_scope` factor). Reused
as-is; this entry adds no new gate.
- `src/kdive/providers/core/runtime.py:82` — `supports_diagnostic_sysrq`, "Fail-closed: a provider
that cannot inject SysRq into its guests' consoles leaves it False and the tool refuses with
`capability_unsupported`" (ADR-0285/0427).
- `src/kdive/providers/core/runtime.py:87` — `supports_crash_watch` (ADR-0367/0427), whose value
here depends on the console-ownership answer from #1815.
- #1808 — both wrapped control planes refuse `interrupt`, which is why the OOB drivers in this epic
talk to the service processor directly.
- Related prior work under epic #1760: #1779 (fail-closed x86 hardware crash mechanisms) and #1780
(authenticated SysRq crash control). See #1814's overlap table.

## Expected outcome

- `Controller.power()` delegating on/off/reset to the per-host OOB driver, with a specific
`ErrorCategory` when the OOB channel is unreachable.
- `force_crash` via magic SysRq through the console channel, behind the **existing** destructive-op
gate — same RBAC role and profile opt-in, no new bypass.
- `supports_diagnostic_sysrq = True`; `supports_crash_watch` set per #1815's console-ownership
decision, fail-closed if that decision leaves the console exclusively owned during a session.
- Concurrency: power and crash serialize per-System via the existing advisory locks; a crash racing
a teardown must not interleave.
- Adversarial tests for the race paths, consistent with `tests/adversarial/`.

Blocked by #1826

Contributor guide

Open the contributing guide

Research direction

This is blocked by #1826 and depends on the console-ownership decision in #1815. Start with src/kdive/providers/ports/lifecycle.py:251, src/kdive/providers/core/runtime.py, src/kdive/security/authz/gate.py, and the existing advisory-lock code; then read tests/adversarial/. Done means OOB power operations and console SysRq crash control honor the existing gate, serialize per System, fail closed, and cover the race paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, infrastructure, operating-systems, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.