{"slug": "linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso", "title": "Linux nell'era degli LLM: cosa funziona, cosa no, e cosa fare adesso", "summary": "Greg Kroah-Hartman, maintainer del Linux kernel, ha presentato un talk intitolato 'Linux in the Land of LLMs' in cui ha rivelato che almeno un terzo dei bug trovati dalle LLM è falso, ma che strumenti come Anthropic's Mythos sono efficaci nel trovare vulnerabilità note. Il kernel emette circa 14-15 CVE al giorno, uno ogni 20 minuti, e per filtrare i falsi positivi il team chiede una patch al modello. Kroah-Hartman ha anche consigliato di eseguire modelli localmente, citando che le aziende hanno sprecato 28 miliardi di dollari usando infrastrutture esterne.", "body_md": "# Linux nell'era degli LLM: cosa funziona, cosa no, e cosa fare adesso\n\nGreg Kroah-Hartman, maintainer del Linux kernel, ha presentato un talk dal titolo **\"Linux in the Land of LLMs\"** in cui racconta come il kernel stia affrontando l'ondata di bug report e patch generati da intelligenze artificiali. Il messaggio centrale è semplice: niente panico, ma lavorate.\n\n## Gli LLM trovano davvero i bug\n\nLe LLM sono pattern matcher. Il codice è fatto di pattern. Questo le rende straordinariamente efficaci nel trovare vulnerabilità note applicate a nuovi codici.\n\nAnthropic ha fatto proprio questo con Mythos: ha preso i vecchi bug di sicurezza, li ha usati come template, e li ha cercati nel codice attuale. Risultato? Funziona.\n\n\"It's not rocket science, it's just really simple pattern matching, and it works really good on standardized bodies of data like code.\"\n\nIl problema è che il tempo medio per lo sfruttamento di una vulnerabilità è crollato. Le aziende non possono più permettersi di distribuire le fix lentamente. Il kernel emette circa [14-15 CVE al giorno](https://www.openwall.com/lists/oss-security/?ref=grigio.org), uno ogni 20 minuti. Prima erano 12-13. Microsoft e Apple corrono a velocità simili.\n\n## Il lato oscuro: bug fantasma e code slop\n\nLa realtà è che almeno **un terzo dei bug trovati dalle LLM è falso**. Gli studenti che lavorano con Kroah-Hartman per bruciare questa coda di report si frustrano continuamente.\n\n\"These tools really, really want to please you. They will lie.\"\n\nLe LLM sono verbose. Generano changelog enormi. Vogliono aggiungere commenti ovunque. Una modifica di due righe diventa otto righe di commenti inutili. Se il codice è scritto bene, dovrebbe parlare da solo.\n\n## La strategia del kernel: chiedete la patch\n\nLa mossa più intelligente adottata dal kernel è semplice: quando arriva un bug report generato da AI, si chiede la patch.\n\n\"Tell the LLM fix it. And that instantly gets rid of 1/3 of the bugs because it just was lying, it couldn't figure it out.\"\n\nSe il modello non riesce a produrre una fix, di solito non c'è un problema reale. Questo filtro ha ridotto drasticamente il carico di lavoro del [security team](https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html?ref=grigio.org).\n\n## Strumenti concreti che funzionano\n\n### Review prompts di Chris Mason\n\nChris Mason, creatore di Btrfs e ingegnere Meta, ha sviluppato un sistema di [review prompts open source](https://github.com/masoncl/review-prompts?ref=grigio.org) per la revisione assistita da LLM dei patch del kernel. Il sistema funziona per il kernel, systemd, e iproute.\n\nL'approccio è stratificato: si rompono i diff in chunk, si revisionano singolarmente, si verificano i Fixes: tag, si controllano i thread passati su lore. Ogni task ha il suo contesto. Risultato: meno token usati, più bug trovati.\n\n### Sashiko\n\n[Sashiko](https://github.com/sashiko-dev/sashiko?ref=grigio.org) è un tool di review agentic donato da Google alla Linux Foundation. Revisiona tutti i patch inviati a LKML usando Gemini 3.1 Pro. È già attivo su quasi tutti i patch del kernel e sta venendo integrato nelle review tools.\n\n### KRes di Chris Mason\n\n[KRes](https://github.com/masoncl/kres?ref=grigio.org) è un multi-agent REPL per revisionare e trovare bug in alberi sorgente C. Usa modelli diversi per compiti diversi: un modello lento per l'analisi profonda, uno veloce per le operazioni correnti.\n\n## Esegui i modelli localmente\n\nQuesto è forse il consiglio più pratico del talk.\n\n\"Companies wasted $28 billion using off infrastructure models. Run them locally.\"\n\nI modelli locali sono sufficientemente buoni. Un desktop con processore AMD e tanta RAM può far girare modelli che trovano bug efficacemente. La sicurezza è critica: qualsiasi cosa si mandi a un modello esterno dovrebbe essere considerata pubblica.\n\nKroah-Hartman lo dice chiaro: vede report duplicati ogni giorno perché i modelli pubblici si parlano tra loro. I dati si leakano.\n\n## Alpha-Omega e il threat modeling\n\nL'[Alpha-Omega project](https://alpha-omega.dev/?ref=grigio.org) della Linux Foundation ha rilasciato uno strumento open source per [creare threat model](https://github.com/alpha-omega-security/threat-model?ref=grigio.org) per i progetti software. Interviewa i maintainer, legge il codice, e produce un documento che le LLM possono leggere per capire cosa è davvero un problema e cosa no.\n\nQuesto risolve un problema fondamentale: senza un threat model, le LLM non sanno come usi il tuo software e segnalano cose irrilevanti.\n\n## La guida pratica dell'OpenSSF\n\nL'OpenSSF, in collaborazione con la CNCF, ha pubblicato [Securing Open Source in the Age of AI](https://openssf.org/resources/securing-open-source-in-the-age-of-ai-a-practical-guide/?ref=grigio.org), una guida pratica che copre:\n\n- Come gestire contributi e vulnerability report generati da AI\n- Tecniche di prompting e toolkit per migliorare la postura di sicurezza\n- I rischi reali delle LLM: allucinazioni, slopsquatting, severity gonfiate\n- Perché i principi fondamentali della sicurezza rimangono validi\n\n## Il problema delle reti\n\nUna parte significativa dei bug trovati nelle reti del kernel deriva da funzionalità non comuni: [XDP](https://www.kernel.org/doc/html/latest/networking/bpf/?ref=grigio.org) e [io_uring](https://kernel.dk/io_uring.pdf?ref=grigio.org). La maggior parte delle persone non le usa, quindi i bug restano nascosti a lungo. Kroah-Hartman ha fatto appello ai maintainer delle reti per lavorarci su.\n\n## Il verdetto\n\nSaranno 18 mesi difficili. Ma il kernel ha già perso il debito tecnico. Lo sta facendo da mesi.\n\n\"We are today. We have been doing it for the past 3 months. There's nothing magic or rocket science here.\"\n\nLa strategia è chiara: esegui modelli locali, chiedi patch ai report, filtra i falsi positivi, e fai il lavoro. Non serve niente di magico. Serve grinta.", "url": "https://wpnews.pro/news/linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso", "canonical_source": "https://grigio.org/linux-nellera-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso/", "published_at": "2026-09-02 22:26:28+00:00", "updated_at": "2026-09-02 22:53:50.415011+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-tools"], "entities": ["Greg Kroah-Hartman", "Linux kernel", "Anthropic", "Mythos", "Chris Mason", "Btrfs", "Meta", "Sashiko"], "alternates": {"html": "https://wpnews.pro/news/linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso", "markdown": "https://wpnews.pro/news/linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso.md", "text": "https://wpnews.pro/news/linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso.txt", "jsonld": "https://wpnews.pro/news/linux-nell-era-degli-llm-cosa-funziona-cosa-no-e-cosa-fare-adesso.jsonld"}}