Skip to content

docs+ci: platform-support boundary + arch-aware kernel-LSM matrix (arm64/LTS scaffold) - #61

Merged
tattoosonmyskin merged 1 commit into
mainfrom
docs/platform-support-boundary-arm64-matrix
Jul 6, 2026
Merged

docs+ci: platform-support boundary + arch-aware kernel-LSM matrix (arm64/LTS scaffold)#61
tattoosonmyskin merged 1 commit into
mainfrom
docs/platform-support-boundary-arm64-matrix

Conversation

@tattoosonmyskin

Copy link
Copy Markdown
Contributor

Makes the enforcement-scope boundary explicit and prepares the CI matrix for arm64 + LTS-kernel coverage — without changing what runs today.

Docs

  • README → new "Platform support" section. The enforcement floor is eBPF-LSM (Linux-only). Non-Linux hosts get only the cooperative user-space layer with no floor (audit-only = safe-mode posture). Windows/macOS are explicitly not enforcement hosts — they'd need a separate backend (WFP/minifilters/ETW/eBPF-for-Windows), which is a different engine, not a port. aarch64 is expected to enforce identically (BPF-LSM is arch-independent) but is not yet validated.
  • THREAT_MODEL §1 → matching "Platform assumption (enforcement scope)" note.

CI

  • kernel-lsm-real matrix is now arch-aware (explicit arch key; job name includes arch). No behavior change for the 3 existing x86_64 rows.
  • arm64 + LTS-kernel (5.15 / 6.1 / 6.6) rows added as a commented scaffold. They reference self-hosted runners that aren't registered yet, so they're left commented — a workflow_dispatch never hangs on a nonexistent runner. Uncomment per runner as it comes online with BPF-LSM verified.
  • The job is workflow_dispatch-only, so push/PR CI is unchanged. YAML validated.

Companion to #60 (guarantees-table un-stale). Touches a different README region, so no conflict.

🤖 Generated with Claude Code

…m64/LTS scaffold)

Makes the enforcement-scope boundary explicit and prepares the CI matrix for arm64
and LTS-kernel coverage without changing what runs today.

Docs:
- README: new "Platform support" section — the kernel floor is eBPF-LSM (Linux only);
  non-Linux hosts get the cooperative user-space layer with NO floor (audit-only, =
  safe mode); Windows/macOS are not enforcement hosts (would need a separate backend,
  not a port); aarch64 expected to work (BPF-LSM is arch-independent), not yet validated.
- THREAT_MODEL §1: matching "Platform assumption (enforcement scope)" note.

CI:
- kernel-lsm-real matrix is now arch-aware (explicit `arch` key; name includes arch).
- arm64 + LTS-kernel (5.15/6.1/6.6) rows added as a COMMENTED scaffold. They reference
  self-hosted runners that are not registered yet, so they are left commented — a
  workflow_dispatch never hangs on a nonexistent runner. Uncomment per runner as it
  comes online (BPF-LSM verified). No change to push/PR CI (job is dispatch-only).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings July 6, 2026 07:52

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR clarifies the project’s enforcement-scope boundary (kernel-floor enforcement is Linux/BPF-LSM-only) and prepares the manually-dispatched real-kernel CI matrix to become architecture-aware (with an arm64/LTS scaffold) while keeping current CI behavior unchanged.

Changes:

  • Added an explicit “Platform assumption (enforcement scope)” note to the threat model, clarifying audit-only posture when BPF-LSM is unavailable and excluding non-Linux hosts from enforcement scope.
  • Added a new “Platform support” section in the README describing what is and isn’t an enforcement host, plus an explicit platform capability/status table.
  • Updated the kernel-lsm-real workflow matrix to carry an explicit arch key and included commented-out scaffolding rows for future arm64/LTS expansion.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File Description
THREAT_MODEL.md Adds an explicit platform/enforcement-scope assumption section (Linux+BPF-LSM enforcement; audit-only otherwise).
README.md Introduces a “Platform support” section with a platform status matrix and rationale for non-Linux non-enforcement scope.
.github/workflows/ci.yml Makes the real-kernel LSM matrix arch-aware and adds a commented scaffold for future arm64/LTS matrix expansion.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread README.md

| Platform | Kernel floor | User-space governance | Status |
|---|---|---|---|
| Linux **x86_64**, kernel ≥5.16 with BPF-LSM (`CONFIG_BPF_LSM=y`, BTF, `bpf` in `lsm=`) | ✅ Full | ✅ Full | **Validated** — Debian 13/6.12, Ubuntu 24.04/6.17, AlmaLinux 9/5.14 |
Comment thread THREAT_MODEL.md
Comment on lines +56 to +58
The kernel-floor guarantees in this document assume **Linux with BPF-LSM active**
(`CONFIG_BPF_LSM=y`, kernel BTF, and `bpf` in the active LSM list; validated on
kernels 5.14–6.17). On a kernel **without** BPF-LSM, Jinn Guard runs **audit-only**:
@tattoosonmyskin
tattoosonmyskin merged commit 4f3ba7b into main Jul 6, 2026
20 of 21 checks passed
@tattoosonmyskin
tattoosonmyskin deleted the docs/platform-support-boundary-arm64-matrix branch July 6, 2026 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants