Grote Linux-distro's getroffen door netwerkbug

De driver voor bepaalde netwerkkaarten van Intel die in de nieuwste kernels van Linux wordt gebruikt, kan sommige netwerkkaarten fysiek beschadigen. Onder meer Ubuntu, Suse en Mandriva erkennen het probleem.

Netwerkkaarten van Intel die de e1000e -driver gebruiken, lopen het risico beschadigd te worden door de bug. De nieuwste testversie van de kernel van Linux, versie 2.6.27 inclusief rc7, zijn van de bewuste driver voorzien. Wanneer een systeem met ingebouwde of losse Intel-netwerkadapter met deze module wordt aangestuurd, bestaat de kans dat de eeprom van de netwerkkaart corrupte data te verwerken krijgt. In dit geheugen, bestaande uit nvram, wordt informatie als het mac-adres van de netwerkkaart opgeslagen. Hierdoor functioneert de netwerkkaart niet langer en dient deze vervangen te worden.

Het probleem doet zich zowel bij losse als geïntegreerde netwerkkaarten voor: losse pci-expresskaarten voor gigabit-ethernet en de bekende ICH8- en ICH9-southbridge kunnen gebruik maken van de e1000e-driver. Intel heeft een instructie hoe de netwerkadapter geïdentificeerd kan worden beschikbaar gesteld; ook is een lijst met hardware die de e1000e-driver gebruikt voorhanden. Verder waarschuwen enkele grote Linux-distributes, zoals Ubuntu, Mandrake en Suse dat bezitters van Intel-netwerkkaarten moeten oppassen met de nieuwe driver. Zo zouden de bèta 1-versies van zowel openSuse 11 als SLE 11 de driver aan boord hebben.

Ook Mandriva heeft een waarschuwing voor zijn pre-releases van 2009-versies uitgegeven en raadt gebruikers aan te controleren of de betreffende Intel 82566- of 82567-chipsets aanwezig zijn: lspci | grep 8256[67] en om te controleren of de gewraakte driver gebruikt wordt: /sbin/lsmod | grep e1000e. De nieuwe Intrepid-versie van Ubuntu is ook met kernel 2.6.27 uitgerust en derhalve doet de bug zich ook bij dit besturingssysteem voor.

Reacties (96)

[bartcramer]

Beste mensen,

de patch! Al signed-off door Andrew Morton, en geaccepteerd in -mm branch. Dat zal waarschijnlijk niet meer heel lang duren voor opname in de main tree.

@ mserver, hierboven: ?! Zelfde changelog ook:

commit 764527a1b3294b4560203979f39a3671b9a26676
Merge: 45e9c0d... e727240...
Author: Linus Torvalds <[e-mail]>
Date: Fri Sep 19 16:01:37 2008 -0700

(...)
e1000: prevent corruption of EEPROM/NVM

En daaronder ook iets dat gelijkt met mijn eerdere link. Ik denk dat dat inderdaad de -mm tree is, en dus nog niet main. Zal dus nog wel gebeuren.

[Reactie gewijzigd door bartcramer op 24 juli 2024 10:02]

[Sir Isaac]

Suggestieve kop zeg. Dit betreft in ieder geval voor Ubuntu alleen de "beta" versie van 8.10. Blijft staan dat het een erg vervelende bug is.
Sinds de nieuwe manier van nummeren van kernel versies weet ik niet meer welke kernel versie stabiel is. Vroeger kon je er gewoon vanuit gaan dat alle 2.x.y versies stable waren als x even was.

[Jesse]

Het gaat om de 2.6.27-rc7 versie, en dat is nog niet stabiel zegmaar. Als -rcX eraf is zou de kernel geschikt moeten zijn voor productie.
Zoals door anderen ook al genoemd wordt zo'n kernel alleen in alfa / vroege beta versies gebruikt. Het nieuws is hier dan ook niet dat er een bug zit in linux, maar meer dat het een bug is waarvan je nic kapoet gaat.

@disheaver: Ubuntu 8.10 is nog alfa

[Reactie gewijzigd door Jesse op 24 juli 2024 10:02]

[Verwijderd]

rc staat voor Release Candidate. Geen Alpha, geen Beta. Release Candidate. Windows van MS wordt zo tegen RC3 RTM gemaakt. (Open deur eigenlijk voor de MS bashers, maar goed).

Al met al, grote fout van de devs, die VEEL te laat is opgemerkt. Je moet er niet aan denken dat het een rtm was geworden.

[Jeanpaul145]

Vanaf het moment dat er verder wordt ontwikkeld aan de Linux kernel krijgt deze AFAIK het label "rcX" mee. De kernel devvers gebruiken geen Alpha/Beta development status (dat is altijd een persoonlijke keuze he!). De X in de "rcX" loopt steeds verder op tot ergens in de buurt van de 8-9 (zo blijkt uit het verleden althans) en daarna wordt de kernel gefreezed, waarna hij na een tijdje als stable wordt gereleased (heel simpel gezegd dan).

Er is een lullige fout gemaakt, dat zeker, maar dat is nou eenmaal menselijk. Het bewijst ook dat zelfs de strengste codecriteria af en toe onbedoeld een foutje doorlaten (je krijgt echt niet zomaar je code in de vanilla kernel, die wordt eerst goed gepeerreviewed, daarna krijg je een berg met kritiek, dan opnieuw gepeerreviewed, en dan gaat ie in een unstable branch bij iemand, misschien jezelf. Uiteindelijk komt je code er dan misschien in, als er geen beter alternatief bestaat tegen die tijd).

[kozue]

Ja... het klonk allemaal heel rampzalig... een beetje "OMG mijn server wordt straks gehacked, die draait een grote linux distro en hangt aan het netwerk" style.
Dan blijkt het ineens om een bug in een beta kernel te gaan, die alleen in alpha distros wordt gebruikt, in 1 netwerk driver, die een *kans* heeft om het ding te beschadigen... Ik schat het aantal slachtoffers rond de 5, en daar bedoel ik niet mee dat niemand linux gebruikt, maar dat dit een erg specifieke cornercase is waar alleen mensen last van hebben die er zelf om hebben gevraagd door beta software te installeren.

[n4m3l355]

Is dat zo? Juist de ICH8/9 zijn vrij vaak gebruikte chipsets en pci-express kaarten (toevallig net de pricewatch eens nagekeken) blijkt het ongeveer 50/50 te zijn. En van die 50% zijn juist de Intels vrij populair. Maw de kans dat de combinatie van een populaire chipset en nic aanwezig is indien men een kernel installeerd is vrij respectabel. Verder vragen mensen er helemaal niet om bij een beta dat hun hardware beschadigd raakt. Ik gebruik ook beta al wetende dat het niet altijd correct functioneerd maar dat de hardware daadwerkelijk beschadigd raakt is toch wel een unicum. Imo is het dan ook wel ietwat slordig dat zoiets gebeurd.
Dat terzijde ik meende juist dat RedHat oa een groot aantal computers heeft draaien puur om te testen. Nu ben ik niet bekend met hoe een alpha release gebeurd maar zou het niet prettiger zijn in dit geval om eerst een pre-alpha op deze test bakken te draaien alvorens ze in de wijde wereld los te laten met alle gevolgen van dien?

[Tjeerd]

Deed me ook nogal Telegraaf-stijl aan, maar het valt eigenlijk wel mee met de bug. Het is wel een erg vervelende bug die grote gevolgen kan hebben. Eigenlijk vreemd dat zo "makkelijk" de netwerkkaart kapot te krijgen is. Zo te zien blijkbaar iets wat alleen mogelijk is bij een Intel netwerkkaart. Bugje in de Intel hardware?

[disheaver]

Als zo'n bug echt in een beta versie van een distro zit, is er echt iets mis. Dat zo'n bug bestaat okey, maar ik mag hopen niet niets anders dan in een alpha release van de linux kernel. Dat deze optioneel te installeren is, prima. Maar standaard gebruikt wordt voor een beta release... (gebruikt ubuntu alpha kernels voor een beta release, of is de bug in een beta-kernel release gekomen?)

[_JGC_]

2.6.27-rc7 is allesbehalve alpha. Afhankelijk van de staat van de code zou dat ding van de ene dag op de andere gereleased kunnen worden als stable versie, waarna veel gebruikers zich op de nieuwe kernelversie storten omdat het ding als "af" is verklaard.

[Blokker_1999]

En ook nu nog in feite, maar wel pas wanneer een y nummering gevolgd word door het woord final en niet als alpha, beta of rc.

[bartcramer]

Ben met je eens dat het een suggestieve kop is. Let wel op je feiten: het is eergisteren op de ubuntu-devel list geweest, en de beta is pas over anderhalve week. Ik neem aan dat er tegen die tijd wel een patch beschikbaar is.

Kan iemand mij wel vertellen hoe het kan dat zo iets in nota bene een netwerkkaartdriver is gekomen? Die dingen zijn toch al praktisch uitontwikkeld?

[jealma]

Dit is gewoon een simpele bug, die notabene wordt mede-ontwikkeld door Intel's eigen medewerkers. Bovendien is alpha- en beta-software altijd error-prone. Het feit dat deze bug ook hardware damage kan opleveren is reden tot een extra waarschuwing, niet meer, niet minder.

[SuperDre]

het is dan ook geen 'gewone' bug... een 'gewone' bug heeft geen hardware schade tot gevolg.. moet je eens nagaan als je deze op je laptop hebt, dan kun je de hele laptop dus wel wegknikkeren, of met een losse netwerkkaart moeten werken....
Als jij dit gewoon vindt, dan vraag ik me af wat jij dan een extreme bug vindt..

[Mentalist]

Als jij dit gewoon vindt, dan vraag ik me af wat jij dan een extreme bug vindt..

Het is zeker een vervelende bug, maar het kan altijd erger:

http://www.thinkwiki.org/wiki/Problem_with_lm-sensors

lm_sensors prior to 2.6.5 caused the corruption of the Thinkpad's AT24RF08 EEPROM, leading to the Thinkpad not being bootable anymore.

[DukeBox]

Vraag me af of VMWare ESX hier ook last van kan hebben.. het draait dan wel niet op linux maar denk wel dat in het OS de linux driver(source) in verwerkt is ?

[Pietervs]

Ik denk dat VMWare een héél erg stabiele versie van de kernel gebruikt. Debian heeft bijvoorbeeld nog versie 2.6.18 in de repositories staan. De kans dat VMWare met test-kernels gaat werken is ongeveer 0 komma nada: ze gaan niet het risico lopen hun goede naam weg te gooien doordat ze unstabiele of testversies van de kernel gebruiken, lijkt mij...

[analog_]

Er zijn amper distro's die de 2.6.27 kernel aanbieden dus het is niet zo dramatisch. De meeste blijven steken rond 2.6.24.

[Cyphax]

Het probleem zit 'm ook meer in het feit dat de bug uberhaupt in de kernel terechtgekomen is. Voor hetzelfde geld komt zo'n bug wél via een update terecht op je stabiele OS.

En als je dan je netwerkkaart moet vervangen, of er één moet kopen omdat die van je moederbord kapot is, is dat één ding, maar als je laptop zo'n zelfde chip gebruikt, en die óók vatbaar is heb je een groter probleem. Ik weet niet of deze specifieke chip ook in laptops voorkomt overigens.

Het lullige voor die distro's is dat zij hier geen schuld aan hebben. Als het wordt aangeleverd en het is niet goed, dan moet je daar maar net op tijd achter zien te komen. Maar mensen die thuis ermee werken, en hun hardware gaat kapot, die kijken niet naar kernelontwikkelaars, dan krijgt wel de distro-ontwikkelaar de schuld.

[kozue]

Deze bug komt niet terecht op je stabiele OS, want dit is een bug in een development versie van de kernel. Ze hebben een bug in beta software gemaakt... shit happens... Ja, lullig dat het je hardware kan slopen, maar niet zo dramatisch als jij nu beweert, en dat soort dingen is nou precies waarom het grote publiek geen beta versie moet draaien en gewoon moet wachten tot de officiele release. Beta software draaien is altijd op je eigen risico.

[Verwijderd]

Maar de mensen die bèta-software draaien zijn in de Linux-wereld juist erg belangrijk voor bug-reports en dergelijke. De vooruitgang van Linux hangt voor een (groot?) deel juist af van de bèta-gebruikers.
Dit soort bugs (die je hardware om zeep helpen) kan wel eens een grote negatieve invloed hebben op het aantal van de bèta-testers en dat is weer slecht voor de ontwikkeling van Linux(distro's).

[paradoXical]

En zelfs dan is de kans dat een beschadiging als deze optreed ontzettend klein.

[kidde]

[quote]Deze bug komt niet terecht op je stabiele OS, want dit is een bug in een development versie van de kernel.[quote]

De development versie van de kernel bestaat niet echt meer; dit was op initiatief van Linus Thorvalds hemzelve. Vroeger had je 2.3 en 2.5, er zou misschien 2.7 komen, totdat Linus besloot dat er te weinig mensen de development versies probeerden. Daarom werd alle development gedaan in 2.6 en werden distro-makers gepusht om nieuwere testkernels aan de eindgebruiker te leveren: Zodat er meer mensen zouden testen. Was dat niet gebeurd geweest, was deze bug nu misschien nog niet gevonden.

Natuurlijk laat de rc1 tot rc7 zien dat het om een development-versie gaat, maar blijkbaar worden ze netjes door distro's gebruikt; zoals Linus wil. Zo'n bug hoort mijns inziens in een alpha te zitten, en niet in een beta.

[Plofkotje]

Torvalds heeft alleen besloten om van de even nummers voor de stables en de oneven nummers voor de testversie af te stappen. De development versies van de kernels worden nu aangeduid met bijvoorbeeld rc1 t/m 7. De kernels die dit er niet achter hebben staan zijn gewoon stabiele kernels die getest zijn. Het is echt niet zo dat iedereen tegenwoordig een testversie van de kernel draait.

[Jasper Janssen]

Waar een bug 'hoort' te zitten trekt ie zich meestal niet veel van aan.

Het probleem is wsch dat dit iets is dat alleen in uitzonderlijke gevallen voorkomt, en dus niet makkelijk op te testen is.

[FluoDude]

Ik heb iets vergelijkbaars gehad met een linux distro enkele jaren terug. Na het booten van de CD-drive was deze stuk , enkel bij dat model cd-rom. heb ik ook pas ontdekt nadat het op een forum te vinden was. Ik dacht dat het een mandrake as met een LG cd-drive

[Big Womly]

Indien deze versie op een virtual machine geïnstalleerd zou zijn, is dan enkel de virtuele netwerkkaart verknoeit, of wordt dit dan doorgetrokken naar de fysische netwerkkaart? Iemand hier beter van op de hoogte?

[Zsub]

Gezien dat de virtuele machine in principe als een soort laag tussen het Guest (het virtuele) OS en het Host (het daadwerkelijk op een machine geinstalleerde OS) draait lijkt het mij onwaarschijnlijk dat dit de fysieke netwerkkaart beinvloedt, omdat je Linux-guest een volledig andere driver zal gebruiken.

[killercow]

Is het dan niet meer een fout van de chip bakker dat dat stukje geheugen uberhaupt aanspreekbaar is?

Veiligheid moet ook op dat nivo geregeld zijn lijkt me.

[xppieter]

Kijk zo'n geheugencomponent is op veel verschillende manieren in te zetten. Dat het bij deze kaart net als nvram gebruikt is om mac adressen op te slaan kun je de chip bakker niet kwalijk nemen, eerder diegene die de chip toepast.

[Verwijderd]

Ter informatie. De chip zit in veel HP-laptops van 2007/2008.

Het is inderdaad erg vreemd dat het in de flash-schrijf-modus terecht kan komen door corrupte data.

[Verwijderd]

Het leuke is dat een Linux bijna nooit bij ondersteunde software staat. Dus je hangt van de goodwill van je fabrikant af hoeveel kosten je zal hebben.

[Pietervs]

Komt steeds meer hoor. Ook HP met hun servers, Dell met hun laptops, Asus met hun netbooks: allemaal fabrikanten (en niet de kleinsten!) die diverse Linux-distro's ondersteunen.

[Blokker_1999]

Maar er zijn wel enorm veel vrijwilligers die de aankomende versies testen en dus in het ergste geval hun netwerkcontroller zien verdwijnen. De schade kan dus wel vrij groot worden. Daarnaast moet de gebruiker zelf opdraaien voor de kosten, iets wat zeker bij laptops hoog kan oplopen.

Het is dus niet dramatisch, maar wel belangrijk dat het nieuws die mensen bereikt die deze kernel gebruiken

[elteck]

Dat de distro een oudere kernel heeft, wil niet zeggen dat deze buggy driver er niet in zit. Om compatible te zijn met de laatste hardware, voegen sommige distros drivers uit de nieuwste kernel toe aan hun oudere Kernel.
Wij draaien hier bijvoorbeeld nog de oude Redhat 4 enterprise, met een 2.6.9 kernel op een quadcore server, met de laatste intel chipset. We moesten daarvoor de 2.6.9-67 update van de kernel hebben i.v.m. hardware ondersteuning. Met iedere nieuwe update, wordt weer meer hardware understeund. Hoe andere distros dat doen weet ik niet, hoop maar dat ze het goed testen.

[Verwijderd]

Het is sowieso een beetje een "Telegraaf" kop. Het gaat om driver in de testversie. De unstable dus. Daarvoor dienen testversie's nou juist, om dit soort zaken op te sporen.

Een beetje ICT-er zet geen unstable editie of release candidate in voor productieomgevingen.

[Verwijderd]

Dan nog loopt het mollen van een stuk hardware zelfs voor bèta software toch een klein beetje uit de klauwen.

[CAPSLOCK2000]

Yup, maar het is ook wel een beetje eng dat het uberhaupt kan. De meeste hardware krijg je onmogelijk stuk via software, wat je ook doet.

[Bloodshot]

In tegendeel: Schroef de frequenties van je CRT maar eens te hoog op en bel de brandweer....
Eigenlijk is dit een spijtig foutje dat gelukkig ontdekt is en snel gefixt is voor het de stable-omgeving raakt. Is dit een grote fout? IMHO: Niet echt. Soms kan het namelijk handig zijn om je hardware aan te kunnen passen (zoals je MAC-adres of een image van aangepaste firmware). Ik vraag me alleen af of het ook mogelijk is om de chip te "herstellen" door het prommetje opnieuw van de juiste code te voorzien...

[thegve]

Is dat daadwerkelijk nog mogelijk met enigszins latere CRT modellen (die SVGA ondersteunen zeg maar..). Meestal als ik een onzinnige frequenty kies, dan krijg ik iets als "input error", ofwel als ik bij de eigenschappen op het OSD kijk staat daar iets veel lagers.

[Verwijderd]

Dat kon met oudere CRT monitoren ja. Mijn broer heeft het eens voor elkaar gekregen. Overigens is "bel de brandweer" ook overdreven: de monitor geeft gewoon geen beeld meer, rook kwam er niet aan te pas.

[kidde]

Soms kan het namelijk handig zijn om je hardware aan te kunnen passen (zoals je MAC-adres...

Niet nodig, doe je gewoon softwarematig via ifconfig. In Linux dan (BSD ook geloof ik); Windows weet ik niet.

[MBV]

En wat denk je dat er dan gebeurt? Dan wordt aan de driver gevraagd om het mac-adres aan te passen in het nvram van de netwerkkaart...

[Jasper Janssen]

Dat klopt niet, als je via ifconfig het mac wijzigt is dat geen persistent change en wordt dus blijkbaar niet naar de nvram geschreven.

[acemoo]

bij ubuntu is het toch een alpha waar de bug in zit.

[Verwijderd]

precies, misschien dat enkel een aantal gentoo gebruikers hier last van hebben en wat testers maar het grote publiek hoeft hier (nog) niet bang voor te zijn.

Mijn eigen ubuntu systeem
2.6.24-19

[analog_]

Gisteren nog met gentoo zitten prutsen en hun nieuwste is de 2.6.26.

[Pietervs]

Dankzij die "dommerikken" worden dit soort bugs anders toch bekend. Dus als ik jou was zou ik ze maar dankbaar zijn in plaats van ze te be-/veroordelen...

[Verwijderd]

pfffft, rustig maar, "dommerikken" was sarcastisch. ik probeer alleen een klein beetje informatie te geven over de verdeling van de gebruikers van gentoo, met name betreffende de vraag welke kernel versie ze gebruiken. sommige mensen willen blijkbaar het allernieuwste, en daar zijn we ze dankbaar voor, zeker op momenten als deze.

[Verwijderd]

Dat hangt er ook vanaf of ze stable of unstable draaien. In het eerste geval zal het zo'n vaart niet lopen.

[Verwijderd]

Belangrijk om te vermelden is dat in de alpha van ubuntu de e1000e module is uitgeschakeld.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 10:02]

[liberque]

Persoonlijk vind ik dit nogal vertontrustend nieuws. Niet vanwege Linux of zelfs nog maar vanwege Intel. maar gewoon door het feit dat je softwarematig nu wel je hardware om zeep kan helpen. Meestal stel ik nieuwe computer gebruikers gerust met het feit dat ze niet bang moeten zijn om iets te proberen en te leren. Immers als het niet meer werkt dan installeren we de boel gewoon opnieuw, de hardware kan er in ieder geval niet van kapot. Echter nu we op userlevel (bios daargelaten) wel de hardware kunnen beschadigen kan ik dat argument ook maar beter laten vallen.

Daarnaast betreft het hier momenteel een module in een linux kernel die met mogelijk corrupte informatie de nvram om zeep helpt; althans het mac adres aantast waardoor de kaart niet meer functioneert. Dit lijkt me iets wat wel te simuleren valt onder andere OS'en als Windows XP. met dien ten gevolge dat de achteloze ja klikker wel eens meer dan alleen software te verliezen heeft. Zeker nu alleen bij dit type nic's maar met alle verschillende hardware momenteel beschikbaar is het niet ondenkbaar dat Intel niet de enige is die met een soortgelijk probleem kampt.

[Verwijderd]

Het is altijd al mogelijk geweest om een trojan te schrijven die de hardware om zeep helpt. De vraag is natuurlijk: wat schiet je ermee op als virusschrijver? Het is niet zo handig voor het botnet als de netwerkkaart kaduuk is.

Om dezelfde reden zie je ook nauwelijks malware die je documenten vernietigt.

[Verwijderd]

Raar:

commit 78566fecbb12a7616ae9a88b2ffbc8062c4a89e3
Author: Christopher Li <[e-mail]>
Date: Fri Sep 5 14:04:05 2008 -0700

e1000: prevent corruption of EEPROM/NVM

Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed
it.

The EEPROM corruption is triggered by concurrent access of the EEPROM
read/write. Putting a lock around it solve the problem.

[[e-mail]: use DEFINE_SPINLOCK to avoid confusing lockdep]
Signed-off-by: Christopher Li <[e-mail]>
Reported-by: Andrey Borzenkov <[e-mail]>

Al op 5 september gefixt? zie: http://kernel.org/pub/lin...ting/ChangeLog-2.6.27-rc7

[Verwijderd]

Het gaat dus om de alpha en beta releases van deze distro's. Stabiele releases gebruiken 2.6.26 of eerder en hebben geen last van dit probleem

[iceheart]

The Real WTF is eigenlijk nog wel dat zo'n kaart door een wat corrupte datastroom gesloopt kan worden IMO.
al is het natuurlijk ook een erg vervelende bug, maargoed...

[Verwijderd]

Maar onder "fysiek" beschadigen versta ik toch een hardwarematige beschadiging....

[Blokker_1999]

ja en nee, de eeprom krijgt foutieve informatie die word opgeslagen. Hierdoor kan het OS niet meer communiceren met de controller en dient deze dus fysiek vervangen te worden.

[Klaus_1250]

Hij dient fysiek opnieuw geprogrameerd te worden, das niet hetzelfde als vervangen.

[Jasper Janssen]

Nee, hij moet vervangen worden. Hij *kan* namelijk dan niet meer fysiek opnieuw geprogrammeerd worden. Het gaat niet over een losse eeprom ofzoiets maar over een paar transistors in de chip geintegreerd, en als ie eenmaal; stuk is kun je die niet meer schrijven.

[Blokker_1999]

In vele hardware word de dag van vandaag een deel van de instructies softwarematig uitgevoerd. Daarom ook dat drivers zo belangrijk zijn en soms moeilijk na te bouwen zijn onder linux. De firmware van zo een controller word telkens bij het laden van de drivers ingeladen in de controller. Als daar iets fout gebeurd is het dus mogelijk dat je alles verknald.

[Brupje]

flawed by design idd