linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

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: <c4974be6-6076-4833-bada-3012d3660a8c@lucifer.local>
Date: Mon, 28 Jul 2025 14:13:01 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Sasha Levin <sashal@...nel.org>
Cc: Greg KH <greg@...ah.com>, corbet@....net, linux-doc@...r.kernel.org,
        workflows@...r.kernel.org, josh@...htriplett.org, kees@...nel.org,
        konstantin@...uxfoundation.org, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Mon, Jul 28, 2025 at 08:45:19AM -0400, Sasha Levin wrote:
> On Mon, Jul 28, 2025 at 11:52:47AM +0100, Lorenzo Stoakes wrote:
> > One thing to note is that I struggled to get an LLM to read MAINTAINERS
> > properly recently (it assured me, with absolute confidence, that the SLAB
> > ALLOCATOR section was in fact 'SLAB ALLOCATORS' + provided me with
> > completely incorrect contents, and told me that if I didn't believe it I
> > should go check :)
>
> Heh, I wouldn't trust LLM with anything more than mechanical
> transformations or test writing at this point :)

I'm glad we are aligned on this :)

>
> > So at all times I think ensuring the human element is aware that they need
> > to do some kind of checking/filtering is key.
> >
> > But that can be handled by a carefully worded policy document.
>
> Right. The prupose of this series is not to create a new LLM policy but
> rather try and enforce our existing set of policies on LLMs.

I get that, but as you can see from my original reply, my concern is more
as to the non-technical consequences of this series.

I retain my view that we need an explicit AI policy doc first, and ideally
this would be tempered by input at the maintainer's summit before any of
this proceeds.

I think adding anything like this before that would have unfortunate
unintended consequences.

And as a maintainer who does a fair bit of review, I'm likely to be on the
front lines to that :)

>
> Right now the "official" policy of our project is that we accept agent
> generated contributions without any requirements beyond what applies to
> regular humans, which most LLMs promptly skip reading and go do their
> own thing...

Well, that's rather implicit. I'm not sure there's _many_ who read the LF
page on this and saying 'aha! I will go and send some AI-generated stuff to
the kernel'.

I think people are probably wary of what kind of response they'll get.

Merging changes like this will inevitably result in people thinking we're
all good with taking whatever.

It's silly, it's not logical, but it's a human psychology thing. And I'm
_very sure_ you're aware of just how... 'delightful' some of the press
coverage of the kernel can be, and just how 'accurate' :)

Sadly we do need to account for this.

>
> So I wanted to at least force LLMs to go RTFM before writing code.

Right, and important to get their authors to too!

>
> > >
> > > > In addition, it's concerning that we're explicitly adding configs for
> > > > specific, commercial, products. This might be seen as an endorsement
> > > > whether intended or not.
> > >
> > > Don't we already have that for a few things already, like .editorconfig?
> >
> > Right, but I think it's a whole other level when it's a subscription
> > service. I realise we have to be practical, but it's just something to be
> > aware of.
> >
> > Perhaps an entry in the AI doc along the lines of 'provision of
> > configuration for a service is not advocating for that service, it is
> > simply provided for convenience' or similar might help.
>
> It also gives us the option of dropping some of these if we find them to
> be either horrible at their job or just being abused.

By implication this is saying that not dropping is a sign we're ok wtih
it... this is the issue here, policy can be perceived to exist implicitly.

I mean as I said to Greg, we have to be practical here.

It's tricky, I guess simply saying in the policy doc it's not an
_endorsement_ per se, but rather provided for tooling that isn't
egregiously broken, maybe something like this.

Cheers, Lorenzo