Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] docs: security: kap: contradictory epoch semantics for bound
tasks
--
commit 77da64268c0c9921ecf4f2c4a0222c86b4687cb2
Author: HARIHARA SUDHAN. R [off-list ref]
docs: security: Describe the Kernel Assurance Plane design
This commit adds security documentation and securityfs ABI documentation
describing the Kernel Assurance Plane (KAP) design, Intent Lineage Groups,
and control plane files.
quoted hunk ↗ jump to hunk
diff --git a/Documentation/security/kap.rst b/Documentation/security/kap.rst
new file mode 100644
index 0000000000000..e002a081c6607
--- /dev/null
+++ b/Documentation/security/kap.rst
[ ... ]
quoted hunk ↗ jump to hunk
+O1 finishes its first stage. The controller advances O1 to a new authority
+generation that is narrower: no package cache, no network. It writes the new
+authority and a higher epoch to O1's igroup. O2's igroup is untouched.
+
+From its next check, an already running O1 worker is held to the new authority.
+It cannot reach the cache or the network even though it could a moment ago, it
+was not asked to drop anything, it was not restarted, and O2 is unaffected. If
+instead the controller revokes O1, the next O1 check fails closed.
[ ... ]
quoted hunk ↗ jump to hunk
+``epoch``
+ Monotonic authority generation. Installing a higher epoch fails every task
+ still bound to an older one closed from its next check.
[Severity: Low]
Does advancing an igroup's authority_epoch hold already-bound tasks to the
new authority, or does it cause them to fail every check closed?
The motivating example above states that writing a new authority and a
higher epoch to O1's igroup holds an already-running O1 worker to the
narrower authority, whereas the epoch definition here and the
kap.authority_epoch entry in Documentation/ABI/testing/securityfs-kap say
that installing a higher epoch causes tasks bound to an older epoch to
fail KAP checks closed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110202246.274-1-harisudhan@armoriq.io?part=1