Anthropicin Frontier Red Team ja formaaleihin menetelmiin erikoistunut Theorem kertovat, että Claude tuotti koneellisesti tarkistetut todistukset 239 fuzz-testien aloituskohdalle 123 avoimen lähdekoodin kirjastossa. Todistukset koskevat käännettyjä RISC-V-ohjelmia ja rajattuja kaatumis- ja muistiturvallisuusominaisuuksia. Ne eivät osoita, että kirjastot olisivat kaikissa tilanteissa virheettömiä.
9
5
Työn mittakaava on huomattava: tiimin mukaan se kesti muutamia viikkoja, ja tuloksena syntyi noin 180 miljoonaa riviä Rocq-todistuskoodia. Laajempi merkitys voi olla siinä, että tekoälyn avulla formaalia verifiointia pystytään soveltamaan aiempaa laajemmin oikeisiin ohjelmistoihin. Väitteet on silti rajattava siihen, mitä todella määriteltiin ja tarkistettiin.
3
13
Mitä todistukset osoittavat?
Anthropicin mukaan todistusten kattamat ohjelmat päättyvät normaalisti ilman muistiturvallisuusvirheitä tai epäonnistuneita tarkistuksia, kun syöte on alle 64 megatavua. Tulos pätee mallinnettuihin Linux-käyttöjärjestelmän vastauksiin ja muistiasetteluihin sekä ilmoitettuihin oletuksiin. Todistusten kohteena ovat käännetyt RISC-V-ohjelmat, eivät yleispätevä lupaus kirjastojen kaikista versioista tai käyttöympäristöistä.
9
12
Työnkulussa hyödynnettiin Googlen OSS-Fuzz-palvelun olemassa olevia testien aloituskohtia formaaleina määrittelyinä. Fuzz-testauksessa kokeillaan suurta joukkoa syötteitä. Claude puolestaan tuotti todistuksia siitä, miten määritelty ohjelma käyttäytyy todistuksen kattamalla syötealueella.
3
13
Anthropic kuvailee työtä ensimmäiseksi laajamittaiseksi yritykseksi käyttää tekoälyä tuotantokäytössä olevan ohjelmiston formaaliin verifiointiin konekooditasolla. Tämä on yhtiön luonnehdinta työn uutuusarvosta, ei riippumattomasti vahvistettu historiallinen yksimielisyys.
7
13
Rocq-tarkistin tuo todistuksiin tärkeän kerroksen
Claude tuotti todistukset, ja Rocq-todistinkerneli tarkisti ne. Kehittäjän ei siis tarvitse luottaa Clauden päättelyyn tai käydä jokaista koodiriviä itse läpi, jotta todistus voidaan tarkistaa koneellisesti. Oletuksia jää silti: lauseen pitää kuvata juuri sitä ominaisuutta, josta kehittäjät ovat kiinnostuneita, ja formaalit mallit sekä tarkistin kuuluvat luotettaviin perustoihin.
9
5
Anthropic ja muut lähteet arvioivat Rocq-todistuskoodin määräksi noin 180 miljoonaa riviä eli keskimäärin suunnilleen 600 000 riviä ohjelmaa kohti. Määrä kuvaa työn mittakaavaa, mutta rivien lukumäärä ei yksin kerro, kuinka laajasti todistettu ominaisuus pätee tai vastaako se ohjelmiston todellisia tuotantotarpeita.
3
12
Mitä testaus voi jättää huomaamatta?
Fuzz-testaus kokeilee monenlaisia syötteitä, mutta se ei yksin todista ohjelman käyttäytymistä jokaisella määritellyn alueen mahdollisella syötteellä. Hankkeesta kertovien lähteiden mukaan Claude löysi ja korjasi satoja virheitä, myös sellaisia, jotka olivat jääneet huomaamatta trillioonien fuzz-testiajojen aikana. Nämä ovat hankkeesta raportoituja lukuja, eivät riippumaton mittaus siitä, kuinka usein formaali verifiointi voittaa testauksen muissa projekteissa.
2
11
Käytännön opetus ei ole testauksen korvaaminen. Formaalit todistukset voivat tuoda rinnalle erilaista näyttöä: määritellyn ominaisuuden ja rajatun soveltamisalan osalta ne voivat osoittaa käyttäytymisen kaikilla spesifikaation mukaisilla syötteillä, eivät vain testien aikana kokeilluilla tapauksilla.
9
2
Miksi ”verifioitu” ei tarkoita ”virheetön”?
Takuu koskee valittuja aloituskohtia ja tiettyjä käännettyjä ohjelmia. Se ei automaattisesti ulotu kirjaston kaikkiin toimintoihin, käännösasetuksiin, laitearkkitehtuureihin tai käyttötapoihin.
9
5
Myös todistusten käyttöehdoilla on merkitystä. Raporttien mukaan ne koskevat yksisäikeisiä, staattisia RISC-V-ohjelmia mallinnetussa Linux-ympäristössä ja kiinteällä muistibudjetilla. Monet käyttävät ohjelmistoista muiden arkkitehtuurien tai asetusten versioita, joten tulosta ei pidä tulkita takuuksi niiden toiminnasta.
12
27
34
Lisäksi todistus osoittaa sen lauseen, joka sille kirjoitettiin – ei kaikkia ominaisuuksia, joita kehittäjä saattaisi ohjelmalta toivoa. Todistuksen ulkopuolelle voi jäädä virheitä, ja myös tuloksen perustana olevissa formaaleissa malleissa ja tarkistuksen luotettavissa osissa voi olla rajoitteita.
5
31
Mitä kehittäjät voivat tuloksesta päätellä?
Hankkeen keskeinen anti on näyttö siitä, että tekoäly voi tehdä konekooditason formaalista verifioinnista käytännöllistä aiempaa useammissa oikeissa ohjelmistoissa. Tulos ei kuitenkaan tarjoa yleispätevää arviota kustannuksista tai takuuta siitä, että menetelmä toimisi missä tahansa koodikannassa.
7
13
Osa todistuksista on julkaistu avoimesti. Yhden lähteen mukaan julkinen aineisto kattaa 25 kirjastoa ja 60 aloituskohtaa, ei koko hanketta. Theorem on myös ilmoittanut OSS Verify -ohjelmasta avoimen lähdekoodin ylläpitäjille.
32
16
38
Kehittäjän kannattaa suhtautua todistukseen rajattuna varmistuksena: tarkista, mitä aloituskohtaa ja käännettyä ohjelmaa se koskee, millä oletuksilla se pätee ja mikä ominaisuus siinä on todistettu. Tulokset tekevät suurten kielimallien avustamasta formaalista verifioinnista arvioimisen arvoisen lisän testaukseen – eivät syytä lopettaa testaamista tai olettaa ohjelmistojen olevan virheettömiä.
9
5