Reid Sutherland <[email protected]> writes: > On 2026-07-27 3:47 p.m., Sam James wrote: >> Reid Sutherland <[email protected]> writes: >> >>> On 2026-07-27 12:25 p.m., Solar Designer wrote: >>>> On Mon, Jul 27, 2026 at 09:46:12AM -0400, Reid Sutherland wrote: >>>>> For your information. >>>>> >>>>> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?id=a204badd8432f93b7e862e7dac6db0fe3d65f370 >>>> Thanks, but can you please explain why exactly you think this is >>>> noteworthy for oss-security? >>>> >>>> I see there's a recent Phoronix story: >>>> >>>> https://www.phoronix.com/news/KVM-Chainsaw-Linux-7.3 >>>> >>>> and the patch series had been tracked and archived by LWN. >>>> >>>> This is definitely noteworthy for KVM project development, but even >>>> seeing all those other resources, I do not see why bring this in here? >>> >>> Core changes to virtualization should receive examination. Changing >>> data structures around because they're too big.. it's concerning, >>> following that patch is tricky because of its size. Would feel better >>> about it if changes like this were passed through a reliable LLM, but >>> even that requires relevant experience. And naming it chainsaw, what >>> purpose does that serve? I have very little trust. >> Paolo has been a maintainer for a long time and in FOSS even longer than >> that. Big refactoring can introduce bugs but I've no reason to doubt him >> and I don't really see why this change is any different from any other >> refactoring. > > > The refactor doesn't seem necessary, the original data structure > appears to be fine, now we have surface risk for something that > doesn't solve a bug or implement a feature. > > I don't care what someone's street cred is, it's their result. > >>> >>>> In general, posting a link without explanation is inappropriate here. >>> >>> The 16+ year local root vulnerabilities in the kernel is enough of a >>> bruising to be extra cautious. >> This could be used to post all sorts of large kernel changes here, >> though, and I don't think we want to do that. >> >> Now, with regard to what you said above: I don't particularly want to >> encourage people to just put things into an LLM and see what they say, >> but if you were to ask an LLM, find it had something useful to say (and >> you're qualified to assess that), then sharing it here might be >> appropriate depending on context. > > > Again, steering an LLM to properly search for bugs in C is for the > experienced. If you have a problem with LLMs, you're fighting the > calculator. It's very clear that LLMs are finding bugs that have gone > undiscovered for almost two decades.
I think speculation to this degree is offtopic for the list.
signature.asc
Description: PGP signature
