From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wind.enjellic.com (wind.enjellic.com [67.230.224.160]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D80D1391E76 for ; Tue, 10 Mar 2026 14:11:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.230.224.160 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773151892; cv=none; b=RgxozYoCjJ2F/iPtkvOTPywZWqLYqBVMhc0D0OEyLmn/fXqMKP/KFcelIG6wXs1gcB2H+TgqLIo17QV9zmn0TdVknSMQtI8jUglsIc44giBhEkPkxez4ma5RRtUhlI+jwEbsZkAQjK/lL1uPoygrd2Z7xv3mmPTjs+YBigLCV8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773151892; c=relaxed/simple; bh=2vHVbN35P6rNfdlBRR8Lr/XLKkubRx6n1+b+rQO+MXQ=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:Content-Disposition:In-Reply-To; b=YtuMcOc0aITagwJfOwW1VJ43IxkBR9DG0E26T2DNys+of321wzHp3JG+HSOyt63PtY8+JQjsf1YtZ+guPy9skpUu+XCoO8sfBUG7VjhJ5WKZYaVE05ooZiSV3SrEMpvUHwf2FXaddJ90xDPDZwg/gg0SOMZGTek/zi+/FG14gfg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=enjellic.com; spf=pass smtp.mailfrom=wind.enjellic.com; arc=none smtp.client-ip=67.230.224.160 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=enjellic.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wind.enjellic.com Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 62AEAuqg028468; Tue, 10 Mar 2026 09:10:56 -0500 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 62AEAs63028467; Tue, 10 Mar 2026 09:10:54 -0500 Date: Tue, 10 Mar 2026 09:10:54 -0500 From: "Dr. Greg" To: Theodore Tso Cc: EJ Stinson , "H. Peter Anvin" , Jonathan Corbet , Steven Rostedt , Christian Brauner , tech-board-discuss@lists.linux.dev, linux-kernel@vger.kernel.org, ksummit-discuss@lists.linuxfoundation.org, christianvanbrauner@gmail.com Subject: Re: LLM based rewrites Message-ID: <20260310141054.GA28273@wind.enjellic.com> Reply-To: "Dr. Greg" References: <20260307-clean-room-6118793eb175@brauner> <20260309095705.7a6b6177@gandalf.local.home> <20260309121629.21cabc25@gandalf.local.home> <871phtvu7r.fsf@trenco.lwn.net> <04B897EF-DEEC-42D0-8E00-888CEEA5318E@zytor.com> <20260310045210.GA14867@macsyma-wired.lan> <20260310124721.GB14867@macsyma-wired.lan> Precedence: bulk X-Mailing-List: tech-board-discuss@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260310124721.GB14867@macsyma-wired.lan> User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Tue, 10 Mar 2026 09:10:56 -0500 (CDT) 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