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: <aIpah6DTRd99mMqb@lappy>
Date: Wed, 30 Jul 2025 13:46:47 -0400
From: Sasha Levin <sashal@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 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,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Dr. David Alan Gilbert" <linux@...blig.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Wed, Jul 30, 2025 at 01:05:31PM -0400, Steven Rostedt wrote:
>On Wed, 30 Jul 2025 12:36:25 -0400
>Sasha Levin <sashal@...nel.org> wrote:
>
>> >
>> >That sounds pretty much exactly as what I was stating in our meeting. That
>> >is, it is OK to submit a patch written with AI but you must disclose it. It
>> >is also the right of the Maintainer to refuse to take any patch that was
>> >written in AI. They may feel that they want someone who fully understands
>>
>> This should probably be a stronger statement if we don't have it in the
>> docs yet: a maintainer can refuse to take any patch, period.
>
>I disagree with that. They had better have technical reasons to refuse to
>take a patch. I would have big qualms if a maintainer just said "I don't
>like you and I'm not going to take any patches from you".
>
>This is a community project, and maintainers have been overridden before.
>Luckily, Linus has been pretty good at getting changes into the kernel when
>there was no clear technical argument that they should not be accepted.
>
>I believe the policy is that a maintainer may refuse any patch based on
>technical reasons. Now, patches can and are delayed due to maintainers just
>not having the time to review the patch. But that is eventually resolved if
>enough resources come into play.
>
>My point here is that AI can now add questions that maintainers can't
>answer. Is it really legal? Can the maintainer trust it? Yes, these too can
>fall under the "technical reasons" but having a clear policy that states
>that a maintainer may not want to even bother with AI generated code can
>perhaps give the maintainer something to point to if push comes to shove.

I don't think that those are technical aspects.

The legality question is answered by the DCO where a human represents
that he is allowed to submit the code. You should have the same concerns
with humans sending in non-GPL-compatible code.

Similarily the argument around not trusting the code is equivalent to
not trusting the person who sent the code in. AI doesn't send patches on
it's own - humans do. This is basically saying "I didn't even look at
your patch because I don't trust you".

>> Maybe we should unify this with the academic research doc we already
>> have?
>
>I wouldn't think so. This is about submitting patches and a statement there
>may be easier found by those about to submit an AI patch. Just because they
>are using AI doesn't mean they'll think it's an academic research.

Not in the sense that AI is research, but more that this is code coming
from someone who is unable to reliably verify the patch that is being
sent in.

The source can be academic research, AI, or whatever else comes along.

It'll just be nice to have a unified set of rules around it. Otherwise
the amount of combinations will explode (in which category do we put in
academic researchers sending in AI generated code?).

>> Some sort of a "traffic light" system:
>>
>>   1. Green: the subsystem is happy to receive patches from any source.
>>
>>   2. Yellow: "If you're unfamiliar with the subsystem and using any
>>   tooling to generate your patches, please have a reviewed-by from a
>>   trusted developer before sending your patch".
>>
>>   3. No tool-generated patches without prior maintainer approval.
>
>Perhaps. Of course there's the Coccinelle scripts that fix a bunch of code
>around the kernel that will like be ignored in this. But this may still be
>a good start.

It'll be hard to draw a line here, so I suggest we don't try.

Are AI generated .cocci semantic patches that are then transformed into
C patches and sent in by a human ok?

-- 
Thanks,
Sasha