MIT-program debugger med lånt kode

1. juli 2015 kl. 10:214
Forskere fra MIT har udviklet et program, der låner kode fra anden software og bruger det til at reparere bugs i et ramt program. Vi må prøve det i praksis, før vi jubler, mener ekspert.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Lån kode i 'donor-software' til at udbedre bugs i den software, du sidder med lige nu. Det er kort sagt princippet bag programmet CodePhage, som en række forskere fra det amerikanske teknologi-institut MIT har præsenteret.

Forskerne kalder de to stykker software, som programmet kræver, for henholdsvis ‘modtager’ og ‘donor’. Dernæst indskyder CodePhage det crash-sikre input i donor-softwaren og følger de operationer, som donor-softwaren foretager. Dette oversættes til de rene logiske operationer, som opføres i en symbolsk log over, hvordan logikken i donor-softwaren virker.

Det betyder altså, at CodePhage ved begyndelsen får to inputs: ét, der får det hullede software til at crashe, og ét, der ikke gør. Dernæst går CodePhage til et andet stykke software, der kan indeholde den funktionalitet, som ville udbedre problemet i det første stykke software.

Peter Toft, der er algoritme-designer hos Fingerprints Cards og som løbende har blogget om debugging på Version2, er ikke helt oppe i skyerne over MIT's CodePhage.

Artiklen fortsætter efter annoncen

»Det er en interessant idé at afprøve. Jeg er dog lidt skeptisk, fordi man angiveligt patcher med kode, man reelt set ikke har og ikke kender, med kildekode, som man så hugger fra donor-softwaren,« siger Peter Toft og uddyber:

»Risikoen for, at de to programmer har vidt forskellig interface, er stor, og så vil jeg sige, at chancen for, at en tredjepart kan verificere den patchede kode, er tilsvarende lav.«

Debugging har brug for effektivisering

Offentliggørelsen af CodePhage fandt sted ved en programmeringskonference i USA i denne måned, hvor folkene bag også viste en række screendumps fra deres testfase. Oplægget finder du her. Peter Toft har bladret nogle af de slides igennem og beholder stadig sin skepsis.

»Vi kan se, at det stadig er meget tidligt i forløbet, og vi mangler stadig svar på, hvor meget de egentlig har testet, og hvor succesfuldt programmet har været. Men det er helt klart en interessant udvikling, vi skal følge,« fortæller Peter Toft.

Artiklen fortsætter efter annoncen

Han pointerer, at debugging trækker rigtig mange ressourcer og tid ud af softwareudviklerne, som i sagens natur kunne bruges på netop udvikling og ikke oprydning. Derfor er det især potentialet i effektivisering, som på sigt kan gøre programmer som CodePhage interessante.

Hvis CodePhadge virker optimalt, så er en anden fordel også, at programmet vil fungere, også selvom modtager- og donor-software end ikke er skrevet i samme sprog. Dernæst køres det crash-inducerende input i donor-softwaren, som CodePhage følger, indtil det identificerer en afvigelse fra det ‘sikre’ input.

MIT-forskerne hævder derfor, at programmører med CodePhage vil kunne spare store mængder tid på at lave opslidende sikkerhedstjek i koden, og på endnu længere sigt, mener de, at det kan betyde, at man fremover ikke længere behøver at skrive kode, der dækker over en funktionalitet, der allerede er skrevet.

4 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
3
1. juli 2015 kl. 18:52

Det er helt skævt at et team mener at de kan fikse kode ved at lappe kode ind fra andre projekter uden at ane en kæft hvordan de skal køre unit-, integrations- og produktionstest.

Det er interessant, men det virker på mig som et eksamensprojekt, der får lidt for meget opmærksomhed ...

2
1. juli 2015 kl. 11:44

Jeg kan slet ikke forestille mig hvor store sikkerhedsforanstaltninger der skal laves i CodePhage før det kommer i nærheden af at kunne bruges seriøst.

Det bliver da uden tvivl det nye hotte at forsøge at få noget "ondt" kode sneget ind i populært donor-software?

Og ved at rette en bug med erstattet kode finder man jo ikke ud af hvad fejlen var og i hvilket omfang buggen ellers kan have skabt ravage?

1
1. juli 2015 kl. 10:43

Det er fint at vise at det her er en teoretisk mulighed, men der er ingen ende på antallet af måder det er en helt forkert tilgang til sikkerhed.

Jeg vil meget hellere have indført produktansvar for software, så skal forsikringsselskaberne hurtigt få kvaliteten hævet dramatisk.

4
2. juli 2015 kl. 07:31

Jeg er helt enig i at man skal tage ansvar. Omvendt så viser præsentationen et meget simpelt og basalt eksempel med buffer overrun. Den slags simple ting kan måske godt automatiseres hvis codephage kan skabe kontekst.

Der findes dog allerede gode værktøjer til den slags, fx Boehms Memory Model.