Software onderzoekt broncode Linux

De Telegraaf schrijft dat het bedrijf Coverity de broncode van Linux aan een onderzoek onderworpen heeft met speciaal hiervoor ontwikkelde software. Het programma spoort fouten op in broncode die geschreven is in C of C++ en analyseert op die manier de kwaliteit en de veiligheid van het onderzochte systeem. Volgens een onderzoek van de Carnegie Mellon University zouden besturingssystemen gemiddeld 5000 fouten hebben in een totaal van 5,7 miljoen regels broncode. Volgens de software van Coverity heeft Linux op deze hoeveelheid echter slechts 985 onvolkomenheden.

Hoewel het bedrijf de broncode van Windows natuurlijk niet kon onderwerpen aan zijn software, stelt de CEO Seth Hallem dat er genoeg over de fouten in Windows gezegd is om te kunnen besluiten Linux dat minstens even goed is als het besturingssysteem uit Redmond, ook zonder de broncode zelf te analyseren. De Coverity-software, SWAT genaamd, analyseert C- en C++-broncode en onderzoekt deze op veel voorkomende fouten als null-pointers, niet geinitialiseerde variabelen en buffer overruns.

Reacties (83)

[Pwigle]

Het zou helemaal mooi zijn als een systeem dit zelf deed en een programma alleen laat uitvoeren indien deze 'goedgekeurd' is. Een extra check voor de programmeur dus.

[RwD]

Als je alle warnings in talen zoals bijvoorbeeld delphi en php ook weg wil werken moet je soms een hele omweg maken voor iets dat gewoon toegestaan is om te doen.

Soms zit zo'n "fout" er bewust in.

[Verwijderd]

Nee hoor, bijna alle warnings zijn terecht. En als iets excpliciet zo moet (e.g. range overflow: MaxInt+=1) dan moet voor dat stuk code de error checking voor dat stuk uitzetten. Als je dat doet is de beslissing gedocumenteerd (en er meestal dus over nagedacht).
In Delphi heb ik altijd alle warnings aan staan, en in PHP vaak ook.
Warnings zijn daar voor een reden.

De enige warnings die niet super boeiend zijn, zijn bevoorbeeld "unused variable\value" warnings. Dat is alleen maar geheugen optimalisatie.

[whoami]

Idd, bij mij gaat er geen code buiten waar er warnings en/of hints inzitten.

Trouwens, ik stel me toch wel vragen bij dat onderzoek. Die software zal wel zeker niet alle 'fouten' of 'mogelijke fouten' eruit halen. Ik denk dat we die software een beetje moeten beschouwen ala FxCop van MS.
Die gaat gewoon de broncode gaan inspecteren op allerhande 'rules'. Als er aan een bepaalde rule niet voldaan wordt, dan wordt dit gemeld. Echter, dit wil daarom niet zeggen dat je daarmee de logische fouten eruithaalt.

[Tuxie]

De nieuwe generatie Intel processoren gaan deze features die jij beschrijft zelfs HARDWAREMATIG doorvoeren

[Olaf van der Spek]

deze features die jij beschrijft

Nee, die processors voeren alleen een zeer beperkt aantal controles uit.

[84hannes]

Intel processoren checken de brondcode van de programma's die ze draaien?

[it0]

Dit gebeurt min of meer al,

Stel je hebt een patch voor de VM dan wordt die bv gereviewed door een kapitein zoals Ingo Molnar als deze hem goedkeurt dan gaat hij voor goedkeuring naar Linus. Bij kernel 1.x wilde code nog wel eens meteen opgenomen worden maar die dagen zijn voorbij.

[jurri@n]

Ik ben benieuwd of de gevonden fouten ook netjes gerapporteerd worden. Dat zijn meteen weer 985 fouten minder.

* 786562 jurrian

[Olaf van der Spek]

Indien ze opgelost worden en er daarbij geen nieuwe fouten geintroduceerd worden.

[Oceria]

Wat ik mij afvraag is hoeveel fouten er in de software zat met welke ze deze check hebben gedaan.
Bovendien worden alleen programmatuur in C* gecontroleerd. Ik weet niet hoeveel van linux/unix nog in andere talen is geprogrammeerd, maar het kan nooit geheel volledig zijn. Bij een vergelijking met andere OS'en moet je dus wel critisch blijven bekijken!

@ beezzthing:
Kijk, als ze in alleen de linux kernel al bijna 1000 fouten gevonden hebben is het natuurlijk wel een beetje flauw om het dan te vergelijken met windows of freebsd, aangezien die niet allleen uit een kernel bestaan.
Uit het verhaal is inderdaad niet duidelijk te halen wat ze nu precies hebben onderzocht, maar het lijkt me toch wel redelijk om dan een heel OS te onderzoeken. Als ze dat niet gedaan hebben is het wel degelijk een incompleet onderzoek.
Het feit dat dit niet echt duiddelijk is geeft alleen maar aan dat mijn waarschuwing "critisch blijven kijken" op zijn plaats is!

*edit*
Ook wat typfoutjes weggehaald

[Verwijderd]

Linux is de kernel. De kernel wordt geprogrammeerd in C aangevuld met Assembly als het om snelheidsredenen nodig is.
Nee, inderdaad niet compleet, maar niet zo incompleet als jij suggereert.

[NoControl]

Ze kunnen het natuurlijk ook over enkel de windows-kernel hebben...

"stelt de CEO Seth Hallem dat er genoeg over de fouten in Windows gezegd is om te kunnen besluiten Linux dat minstens even goed is als het besturingssysteem uit Redmond, ook zonder de broncode zelf te analyseren."

Ik weet dat uitspraken zoals deze nogal uit de lucht gegrepen zijn.

Echter, het simpele feit alleen al dat er een deel van IIS 6 (bij windows 2003) in de kernel zelf zit (om het sneller te maken) doet mij toch wel vermoeden dat die kernel meer fouten per regel zal bevatten...

Hoe je het ook draait of keert, een webserver (gedeeltelijk) in de kernel programmeren is wegens vele redenen enkel maar paniekvoetbal te noemen.

[Verwijderd]

Bij linux heb je de 'tux' een http accelerator die ook in de kernel zit indien gewenst. Deze dient bij een request van static bestanden, zoals plaatjes of html bestanden het zelf af te handelen, komt er een request naar een dynamisch bestand, asp of php of iets dergelijks, stuurt ie de request door naar de eigenlijke webserver zoals apache, die een static request langzamer kan afhandelen dan 'tux'.

Natuurlijk heb je bij linux weer de keus of je er gebruik van wil maken of niet, zover ik weet hebben alle distro's 'tux' neit standaard in de kernels zitten.

'Tux' zit trouwens standaard bij een vanilla kernel.

[MadEgg]

En dan nog wordt het per zoveel regels code vergeleken, en niet per alles. Ik weet niet precies hoeveel regels code de Linux kernel heeft en ook niet hoeveel regels daarvan commentaar zijn(in ieder geval een paar flinke boeken vol commentaar ) maar het is echt wel op een eerlijke manier vergeleken.

[fub]

Ook vraag ik me af hoe ze dat programma hebben geschreven. D'r zijn limieten aan wat je met een programma kan detecteren: terminatie is zo'n geval dat niet met een machine te bepalen is.

En ja, een correctheidsbewijs van het controlerende programma zou wel op zijn plek zijn.

[Nielson]

De Telegraaf schrijft dat het bedrijf Coverity de broncode van Linux aan een onderzoek onderworpen heeft met speciaal hiervoor ontwikkelde software. Het programma spoort fouten op in broncode die geschreven is in C of C++ en analyseert op die manier de kwaliteit en de veiligheid van het onderzochte systeem.

En wie zegt er dat in de analyse software geen fouten zitten ? Zeker weer gescand met hun eigen tooltje

[ATS]

Waarschijnlijk wel ja. Net zoals C compilers gecompileerd worden met C compilers.

[_Thanatos_]

Dit is ook een van de redenen dat ik C/C++ code gewoon erg oncharmant vind. Je kunt de gevaarlijkste truuks met uithalen met method pointers, arrays, string en weet ik wat nog meer. Je kunt alles naar alles typecasten en alles aan alles toewijzen. De compiler denkt dat de programmeur wel weet wat ie doet en dat is wrs ook wel zo, maar het een mens en die beesten maken toch weleens fouten.

Dan zie ik liever een managed taal zoals java of C#, of op z'n minst een taal die veel stricter is op dit gebied, zoals Delphi. Maargoed daar kun je geen device drivers en kernels in schrijven

[Darth Punk]

zou je kunnen uitleggen waarom je in C# in Mono geen device driver zou kunnen schrijven? Er zijn toch compilers die C# code kunnen vertalen naar machine code(dus niet via VM) Of zie ik wat over het hoofd

[Luud]

Voor zover ik weet kent C# geen pointers, alleen referenties.

Voor het schrijven van device drivers heb je pointers nodig omdat je exacte geheugenadressen moet kunnen benaderen. Veel hardware is te benaderen door naar een bepaald stuk "geheugen" te schrijven of ervan te lezen. In werkelijkheid stuur je dan gegevens naar het device of ontvang je van het device.

Dit is slechts 1 reden.

Een en ander is wellicht duidelijker uitgelegd dan ik hier heb gedaan in diverse Linux kernel boeken (e.g. Linux Device Drivers, Understanding the Linux Kernel en Linux Kernel Development. Via amazon vind je ze wel).

[Verwijderd]

Correctie: C# kent weldegelijk pointers. Dit kan wanneer je code tussen 'unsafe' code blokken gaat plaatsen.

[Dim]

Omdat C# en alle andere .NET talen een runtime nodig hebben. En daarvoor moet je eerst weer een OS en een C library hebben... Beetje een kip-en-ei probleem dus.

Overigens zitten al die fijne buffer overflows etc bij .NET talen er dus nog steeds in, alleen nu in de runtime. Dit is bij de Java VM (waar .NET van gejat/afgeleid is) ook al meerdere malen voorgekomen.

[The End]

Als je een driver schrijft, dan heb je veel minder vrijheid in wat voor soort calls je doet en op wat voor manier. Op driver niveau kan je heel makkelijk deadlocks of oneindige loops veroorzaken. Voorbeeldje:

Je gaat een disk driver maken; in die diskdriver ga je een read request afhandelen.
Begin:
Daarvoor heb je een stuk geheugen nodig. Dat vraag je aan bij het systeem. Het systeem genereerd een page fault en doet een read request aan het file systeem. Jou driver gaat die read request afhandelen. goto begin;

Als je dus in C# code schrijft heb je geen volledige controle over hoe iets gedaan wordt. Je weet bijvoorbeeld niet wat voor soort geheugen aangesproken wordt en hoe.

[Verwijderd]

Wat jij zo oncharmant vindt, is een van de sterkste punten van deze talen. Door het geheugen direct te kunnen benaderen, kan je onwijs snelle programma's maken (Ooit wel eens met pointers gewerkt?) Dat de programmeurs hier inconsequent zijn (Nouja, fouten zijn menselijk, maar in code horen geen fouten te zitten) ligt aan hen, en niet aan C/C++.

[Verwijderd]

Heel leuk maar regels code zegt niks.

Helaas is SWAT niet "free". Er zijn wel andere tools die soortgelijke features hebben.
Bijvoorbeeld Valgrid ( http://valgrind.kde.org ), maar die werkt niet op source code maar op running code (beetje lastig voor een kernel de testen lijkt me).
Of flawfinder die wel op source code level test: http://www.dwheeler.com/flawfinder/

[Verwijderd]

Concurrency (en interrupt) problemen kan je niet testen door code te scannen, multithreading is echter ook een heeeele leuke oorzaak van vele problemen Wat hier getest wordt zijn dus alleen mogelijke geheugenproblemen.

[j0bro]

...stelt de CEO Seth Hallem dat er genoeg over de fouten in Windows gezegd is om te kunnen besluiten Linux minstens even goed is als het besturingssysteem uit Redmond...

En met deze 'grote beurt' erbij zal het aantal fouten in de broncode van Linux dus nog verder tot een minimum gebracht worden; de voordelen van Open Source software komen hier wel duidelijk naar voren lijkt me.

[edit] gemodereerd? wat zullen we nou krijgen?

[Ruuddie]

Jha ik vond dit ook al bs. Omdat een OS minder fouten in zijn code heeft, is het goed/beter?
Volgens mij is je OS goed als het veel gebruikt wordt, om de reden dat het makkelijk en goed werkt en zo. Als end user zal het mij geen hol schelen hoe die code in elkaar hangt...

[Pwigle]

Ja alleen als de code goed is, brengt dat automatische een hogere veiligheid, betrouwbaarheid en snelheid met zich mee. En een gevolg daar weer van is dat meer mensen het gebruiken.
Dus uiteindelijk interesseert het je wel een hol, alleen weet je het zelf niet.

[Verwijderd]

Nou....hogere snelheid hoeft niet, want een nutteloos while-loopje of een sleep tussendoor kan een flinke hit op performance geven, terwijl het toch goede code is..
En ik neem aan dat het de kernel betreft, en niet alle programmatuur die op linux draait, en die hebben ook invloed op performance, betrouwbaarheid en veiligheid (brakke apache, ssd, ftpd, telnetd of watooit zorgt nl. voor makkelijke ingang voor beetje goede inbrekers).
Maar het is wel goed nieuws dat de kernel relatief heel weinig fouten heeft, weer een pluspuntje voor het vele-ogen-vinden-veel-bugs principe waar linux en vele andere opensource projecten op draaien.

[SPee]

Goed geschreven software != veilige software.

Een perfect geschreven virus is dus echt niet veilige software
De code is alleen geod, de werking doet ook zoals zou kunnen verwachten. Alleen wat die werking is, daar kan dit programma niets over zeggen.

[maxxware]

Precies! Telnet is feilloos geschreven, maar is by-design niet wenselijk, omdat deze alles clear text over het netwerk gooit.

[Verwijderd]

Goed geprogrameerd zegt niks over de snelheid van de code. Meestal zijn voor het oog mooi ontworpen loops niet goed voor performance.

[florizla]

Idd, maar het is wel zo dat veel programmeerfouten leiden tot veiligheidsgaten. Een voorbeeldje is de bekende buffer overflow.
Als je 'goeie' code hebt, heb je dus toch al 1 soort veiligheidsgaten minder.

[Olaf van der Spek]

Volgens mij is je OS goed als het veel gebruikt wordt, om de reden dat het makkelijk en goed werkt en zo.

Nee, dan is het populair.
Dat zegt meer over marketing dan technische kwaliteit (in dit geval).

En als een app of computer crasht, dan lijkt me dat je dat als eindgebruiker toch wel wat kan schelen.

[maxxware]

Een goed gebouwde auto hoeft niet veilig te zijn. Als bv. de vakkundig gemonteerde brandstof tank direct naast de even vakkundig gemonteerde accu onder de bestuurdersstoel zit, wil dat niet zeggen dat je een veilige auto hebt...

[MadEgg]

Maar toch is dat nog altijd veiliger dan een slecht gemonteerde lekkende brandstoftank die precies boven de accu hangt die slecht geisoleerd is en waar de draadjes te dicht bij elkaar zitten, terwijl boven dat geheel het asbakje met een gat erin gemonteerd is.

[]Byte[]

Volgens mij is je OS goed als het veel gebruikt wordt, om de reden dat het makkelijk en goed werkt en zo.

Een OS is pas "goed" als het doet waar je het voor wilt gebruiken!
Ieder OS heeft zijn sterke en minder sterke punten.
Dat dat maakt werkelijk geen h.l uit of dat nu Windows, Linux, OpenVMS, Tru64 of wat dan ook is!
Als ik 2500 interactieve gebruikers heb die ivm met een appl rechtstreeks een verbinding met die machine nodig heeft (dus geen client-server toepassing) dan zijn OS'en als OpenVMS en Tru64 veel beter als Windows.
En op andere punten is Windows weer sterker!
Kijk naar wat je er mee wilt doen! Niet hoe bekend of goed je het zelf kent.

[Verwijderd]

Iedere bugfix brengt weer andere bugs aan het licht en introduceert soms nieuwe. Er is een of andere rekensom voor...

[Verwijderd]

Ja, die heet de Wet op Behoud van Ellende, en houdt min of meer in dat als jij problemen op gat lopen lossen de rwereld er voor zorgt dat het toch weer ergens mis gaat...

[Yoeri]

...stelt de CEO Seth Hallem dat er genoeg over de fouten in Windows gezegd is om te kunnen besluiten Linux minstens even goed is als het besturingssysteem uit Redmond

Your point being? Persoonlijk vind ik dit maar een flutstelling namelijk.

Systeem 1 hebben we onderzocht en we kunnen daarvan besluiten dat het relatief veilig en kwalitatief is.

Tot daar aan toe. Maar dan zeggen dat je systeem 2 wel niet kon onderzoeken maar "dat het wel zo onveilig en slecht zal zijn als beweerd wordt" getuigt niet echt van enige objectiviteit en professionaliteit.

Zelfs àls die stelling klopt, dan is ze nog zo knullig geformuleerd dat ze de geloofwaardigheid van heel dat bedrijf onderuit haalt imo

[Verwijderd]

De resultaten: http://linuxbugs.coverity.com/linuxbugs.htm
(natuurlijk niet wat er fout is enzo, waarschijnlijk moet Linus dan eerst een licentie aanschaffen )

edit: dit was geen reactie op Yoeri maar op jurrian, komt vast door een NULL pointer fout in mijn hoofd.

[Verwijderd]

(natuurlijk niet wat er fout is enzo, waarschijnlijk moet Linus dan eerst een licentie aanschaffen )

Volgens Slashdot-commentaar waren de betreffende bugs al naar de kenrel maintainers opgestuurd, en waren een flink aantal (enkele tientallen procenten) al opgelost in nieuwere versies.

Overigens jammer dat de samenvatting niet noemt dat de zwaarte van de bugs allerzins meeviel. Zie artikel voor meer info.

[Olaf van der Spek]

> linuxbugs.htm

.htm? Draaien ze daar nog Windows 3.11?

[Kahlan]

het voldoet iig niet aan de 8.3 naming conventie.
linuxbugs.htm is namelijk 9.3

[catfish]

dat staat er toch niet?
Er staat: "dat er genoeg over de fouten in Windows gezegd is om te kunnen besluiten Linux minstens even goed is als het besturingssysteem uit Redmond"
dit wil zeggen dat Linux (welke goed door de test komt) een waardig alternatief is voor Windows en zegt dus eigenlijk niks over Windows

[F_J_K]

Er wordt een waardeoordeel over Windows gegeven (Windows <= Linux) zonder er ook maar naar gekeken te hebben, enkel op basis van een variant op "iedereen zegt dat Windows fouten heeft dus het zal wel zo zijn". IMHO dus niet serieus te nemen.

[Verwijderd]

als ms zich wilt bewijzen zouden ze ook hun source-code door die software moeten laten testen, maar ze willen dit blijkbaar niet, zouden ze schik hebben? :-)

[Darth Punk]

ik vind het een beetje raar onderzoek. Ze hebben de 2.6.9 kernel gebruikt. Nu gebruik ik zelf geen linux, maar ik zou ook graag de resultaten willen weten van een echte stable kernel. Ik bedoel als je naar diagrammen van de link http://linuxbugs.coverity.com/linuxbugs.htm (tnx El_Muerte_[TDS]) bekijkt, dan zie dat de meeste bugs gevonden worden in de device drivers en in het volgende diagram NULL Pointers. Dit zijn typische dingen van nieuwe dingen die onvoldoende zijn getest. Dus het kan maanden (mischien wel jaren :?duren) voordat (bijna) alle bugs eruit zijn gehaald.

mijn tweede vraag is: wat zijn niet geinitialiseerde variabelen Zijn dat variabelen die de programmeur achteraf gezien niet meer nodig had en is vergeten weg te halen of toch wat anders?

[Darkvater]

Dit zijn variabelen waarvan de waarde wordt opgevraagd zonder dat er eerst een waarde eraan werd toegekend. Als je geluk hebt is de waarde 0 bijvoorbeeld, maar het kan gewoon een random stukje geheugen-waarde zijn.

[Darth Punk]

beetje of topic maar zoiets dus:

int test; //beetje foute naam, maar tis maar een voorbeeldje
int buffer;

buffer = 0;

if (buffer > 0) {
test = 3;
}
in dit geval is 'test' een niet geinitialiseerde waarde als buffer <= 0 ;

[berend_engelbrecht]

Dat is een variabele die al gebruikt wordt voordat er de eerste keer een waarde aan toegekend wordt. In C heeft die dan een willekeurige waarde (en niet 0 zoals in sommige andere talen).

[Verwijderd]

Beter gezegd, C geeft aan die variabelen geen waarde. Dit betekent dat een variabele de waarde overneemt die al aanwezig was in het stuk geheugen waarop de variabele betrekking heeft.

[Carnifex]

Maar een fatsoenlijke compiler geeft dan toch een warning, of heb ik het fout?