linux-kernel - Re: Follow-up on Linux-kernel code accessibility

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251219170945.GA32430@macsyma.lan>
Date: Fri, 19 Dec 2025 12:09:45 -0500
From: "Theodore Tso" <tytso@....edu>
To: Julia Lawall <julia.lawall@...ia.fr>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
        Gabriele Paoloni <gpaoloni@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Chuck Wolber <chuckwolber@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Sasha Levin <sashal@...nel.org>, Chris Mason <clm@...a.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Follow-up on Linux-kernel code accessibility

On Fri, Dec 19, 2025 at 07:51:47AM +0100, Julia Lawall wrote:
> 
> Maybe we're not looking for an instant understanding methodology.  Rather
> a machine checkable way to document the invariants that exist in the head
> of the developer, and for some bounded amount of time in the head of the
> person who has tried to reconstruct them.

One of the things that I found really interesting with Chris Mason's
kernel review prompts is that it documents some of these invariants
which are not otherwise covered in the kernel documentation.  And
while Chris originally created those prompts for Anthropic's Claude
LLM, we've successfully used them with Gemini 2.5 and 3.

I wonder if we should consider folding them into the kernel sources,
so they can be updated alongside the kernel.  It might also mean that
as the invariants change, the documentation / prompts in an LTS kernel
and for the latest upstream kernel can be up to sync with the relevant
kernel versions.

> Maybe the low-level ones could be made
> automatically in many cases, or regenerated automatically from some hints.
> But the low-level ones may be needed to make the bridge between the code
> and the high-level specification.

Sasha's API specification framework patches might be something that's
worth considering in this context.  The thing that we need be careful
though, is that we might need to have a way of tagging kernel
functions in terms of the priority for the first set of high-level
interfaces for a newcomer to the kernel should look at first, and
those that might be less important, so that the newcomer won't get
overwhelmed with a vast number of low-level definitions.

Cheers,

							- Ted