All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "HARIHARA SUDHAN. R" <harisudhan@armoriq.io>,
	linux-security-module@vger.kernel.org,
	"Paul Moore" <paul@paul-moore.com>, "Kees Cook" <kees@kernel.org>,
	"James Morris" <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"David Hildenbrand" <david@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Michal Hocko" <mhocko@suse.com>, "Mel Gorman" <mgorman@suse.de>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Ben Segall" <bsegall@google.com>,
	"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
	"Juri Lelli" <juri.lelli@redhat.com>,
	"K Prateek Nayak" <kprateek.nayak@amd.com>,
	"Valentin Schneider" <vschneid@redhat.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Ketan Bhardwaj" <ketan@armoriq.io>,
	bpf@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 1/6] docs: security: Describe the Kernel Assurance Plane design
Date: Tue, 10 Nov 2026 20:33:30 +0000	[thread overview]
Message-ID: <sashiko-outbox-207712@kernel.org> (raw)
In-Reply-To: <20261110202246.274-2-harisudhan@armoriq.io>

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 <harisudhan@armoriq.io>

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.

> 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

[ ... ]

> +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.

[ ... ]

> +``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


  reply	other threads:[~2026-11-10 20:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 20:22 [RFC PATCH v3 0/6] security: introduce Kernel Assurance Plane HARIHARA SUDHAN. R
2026-11-10 20:22 ` [RFC PATCH v3 1/6] docs: security: Describe the Kernel Assurance Plane design HARIHARA SUDHAN. R
2026-11-10 20:33   ` sashiko-bot [this message]
2026-11-10 20:22 ` [RFC PATCH v3 2/6] security: kap: add the LSM ID and internal headers HARIHARA SUDHAN. R
2026-11-10 20:30   ` sashiko-bot
2026-11-10 20:22 ` [RFC PATCH v3 3/6] security: add the Kernel Assurance Plane LSM HARIHARA SUDHAN. R
2026-11-10 20:51   ` sashiko-bot
2026-11-10 20:22 ` [RFC PATCH v3 4/6] security: kap: add the securityfs control plane HARIHARA SUDHAN. R
2026-11-10 20:47   ` sashiko-bot
2026-11-10 20:22 ` [RFC PATCH v3 5/6] kernel: add KAP checks for unshare and setns HARIHARA SUDHAN. R
2026-11-10 20:36   ` sashiko-bot
2026-11-10 20:22 ` [RFC PATCH v3 6/6] MAINTAINERS: add an entry for the Kernel Assurance Plane HARIHARA SUDHAN. R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-207712@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bpf@vger.kernel.org \
    --cc=bsegall@google.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=harisudhan@armoriq.io \
    --cc=jmorris@namei.org \
    --cc=juri.lelli@redhat.com \
    --cc=kees@kernel.org \
    --cc=ketan@armoriq.io \
    --cc=kprateek.nayak@amd.com \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=serge@hallyn.com \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.