All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. Greg" <greg@enjellic.com>
To: Theodore Tso <tytso@mit.edu>
Cc: EJ Stinson <favroitegamers@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Christian Brauner <brauner@kernel.org>,
	tech-board-discuss@lists.linux.dev, linux-kernel@vger.kernel.org,
	ksummit-discuss@lists.linuxfoundation.org,
	christianvanbrauner@gmail.com
Subject: Re: LLM based rewrites
Date: Tue, 10 Mar 2026 09:10:54 -0500	[thread overview]
Message-ID: <20260310141054.GA28273@wind.enjellic.com> (raw)
In-Reply-To: <20260310124721.GB14867@macsyma-wired.lan>

On Tue, Mar 10, 2026 at 08:47:21AM -0400, Theodore Tso wrote:

Good morning, I hope the week is going well for everyone.

> On Mon, Mar 09, 2026 at 10:15:28PM -0700, EJ Stinson wrote:
> > Imagine if a rouge AI got access to rewriting the kernel, or was
> > exploited, this would lead to near certain catastrophe. LLM's
> > should not rewrite the code, as if somehow a AI were to achieve
> > singularity or go rouge/be attacked by an anarchistic/foreign
> > actor, think about the amount of code it could sneak in without
> > human suspicion, or just lead to human ignorance. I think for the
> > time being until we know for certain, there should be no reason to
> > use LLM's to help rewrite at scale any sort of code. Even if we
> > were able to prove it wasn???t stolen code; the time spent on
> > proving such fact, and ensuring the security, would already take
> > way too long tomerit this sort of use.

> And the third is whether it would really result in more secure code
> (which was their premise for why some companies might do this, since
> the people giving the presentation at FOSDEM were security
> researchers).  Given that AI generated code is generally *more* likely
> to have security vulnerabilities than human written code, this
> assumption seems dubious to me.  Also if the security vulnerability is
> inherent in the software architecture, having the first LLM generate a
> spec might result in a *spec* which is buggy / vulnerable, and so when
> the second LLM translates that spec back into C code, not only might
> it introduce new security vulnerabiities, the original security
> vulnerability present in the source implementaiton might be preserved.

It would seem that if some enterprising individual or more likely a
major technology company, with sufficient resources, told an LLM to
simply convert the entire kernel to Rust, that would be the end of
kernel security vulnerabilities as we know it, not?

Then, if said enterprising individual or corporation slapped the GPL
on the result and pushed it to GitHub, mankind would be saved as we
know it.

In the spirit of Christian's intention to inspire conversation... :-)

> Cheers,
> 
> 						- Ted

Have a good remainder of the week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

  reply	other threads:[~2026-03-10 14:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07 20:49 LLM based rewrites Christian Brauner
2026-03-09 13:57 ` Steven Rostedt
2026-03-09 15:31   ` H. Peter Anvin
2026-03-09 16:16     ` Steven Rostedt
2026-03-09 16:33       ` Jonathan Corbet
2026-03-09 16:55         ` H. Peter Anvin
2026-03-09 17:09           ` H. Peter Anvin
2026-03-09 18:19           ` James Bottomley
2026-03-09 18:34             ` Steven Rostedt
2026-03-09 18:38               ` Dr. David Alan Gilbert
2026-03-09 18:54               ` James Bottomley
2026-03-10  4:52           ` Theodore Tso
     [not found]             ` <CAMTJT3_cVaA7aJmDa6j288-qwP3jzvM_R2pdk+XmE+1U=Sovbg@mail.gmail.com>
2026-03-10 12:47               ` Theodore Tso
2026-03-10 14:10                 ` Dr. Greg [this message]
2026-03-09 16:05 ` Dave Hansen
2026-03-09 16:16 ` James Bottomley

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=20260310141054.GA28273@wind.enjellic.com \
    --to=greg@enjellic.com \
    --cc=brauner@kernel.org \
    --cc=christianvanbrauner@gmail.com \
    --cc=corbet@lwn.net \
    --cc=favroitegamers@gmail.com \
    --cc=hpa@zytor.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tech-board-discuss@lists.linux.dev \
    --cc=tytso@mit.edu \
    /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.