Kernelgoeroe ontkracht geruchten Linux-sabotage door Foxconn

Matthew Garrett, werkzaam als kernelontwikkelaar bij Red Hat, heeft op zijn weblog de claims van een Ubuntu-gebruiker ontkracht dat Foxconn bewust Linux kapotte acpi-code voorschotelt. Foxconn lijkt geen schuld te hebben.

Eind vorige week schreef een Ubuntu-gebruiker op het forum van zijn Linux-distributie dat zijn moederbord last had van vastlopers en kernelfouten. Na het disassembleren van de bios leek het er sterk op dat dit te maken had met acpi: Linux zou verkeerde data voorgeschoteld krijgen, omdat problemen met het moederbord opgelost leken als de Windows-code geladen werd. Al snel liet Garrett weten dat de gebruiker zijn conclusies op verkeerde informatie baseerde. Dit bevestigde hij nadat hij de relevante acpi-tabellen geanalyseerd had.

In de acpi-data wordt gecontroleerd of het besturingssysteem de zogenoemde '_osi'-methode ondersteunt. Als dat het geval is wordt een bepaald codepad gevolgd, als dat niet het geval is valt de tabel terug op de oudere '_os'-code. Linux ondersteunt dezelfde acpi-features als Windows en laat de acpi-tabellen daarom weten Windows te zijn. Het resultaat daarvan is dat dezelfde variabele wordt ingesteld als in wanneer dat daadwerkelijk een recente Windows-editie gestart zou zijn.

Als er onverhoopt toch wordt teruggevallen op de oudere '_os'-methode, dan wordt er echter een andere variabele ingesteld. Deze situatie kan echter niet voorkomen onder recente Linux-distributies, omdat de Linux-kernel al sinds de release van versie 2.6.9 vier jaar geleden zich voor de acpi-code als Windows voordoet. Er is geen mogelijkheid om vanuit de acpi-tabellen te ontdekken dat Linux wordt gebruikt. Van sabotage kan dan ook geen sprake zijn, stelt Garrett, temeer daar elk codepad in de acpi-tabellen ook door op zijn minst één Windows-versie gevolgd wordt.

Al met al lijkt Foxconn weinig te verwijten: het bios levert geen kapotte code aan Linux en de acpi-specificatie wordt nergens genegeerd. De veranderingen die de Ubuntu-gebruiker in de code heeft doorgevoerd zorgen er alleen maar voor dat waarschuwingen niet meer voor de gebruiker zichtbaar zijn: de onderliggende fouten bestaan nog steeds. Het oplossen van die fouten in de Linux-code is niet zo eenvoudig, omdat er toegang tot de hardware voor nodig is en die heeft Garrett niet. In ieder geval is het geen fout van Foxconn, hoogstens in de manier waarop Linux code geïmplementeerd heeft.

Reacties (51)

[Golodh]

Mijn complimenten aan Tweakers.

Een goede en snelle berichtgeving in een ondoorzichtige situatie die nog verder verstoord wordt doordat degene die problemen had met het Foxconn bordje uitgebreid is gaan moddergooien.

Ik vermoed dat de meesten hier toch net iets meer geloof hechten aan de analyse van Garrett dan aan die van de klager. Het is naturlijk heel aannemelijk dat fabrikanten van moederborden er altijd wel voor zorgen dat de Windows ACPI tabellen in orde zijn, en het is een feit dat Linux zich in dit geval tegenover het BIOS simpelweg voordoet als Windows en de voor Windows bedoelde tabellen gebruikt.

Waarom het Foxconn bordje dan problemen geeft? Garrett geeft heel eerlijk toe dat hij dat niet weet omdat hij de hardware niet bij de hand heeft, maar dat hij het sterke vermoeden heeft dat dit een bug in Linux is. Hij noemt dan meteen een gerelateerd probleem met Dell hardware dat volgens hem zeker op een Linux bug berust, maar warvoor hij nog geen tijd gehad heeft om het op te lossen. Dat is tenminste een integere ontwikkelaar die duidelijk weet waar hij het over heeft.

En de klager? Een open oog houden voor een mogelijk doelbewuste poging om de Windows ACPI tabellen voor Linux onbruikbaar te maken is tot daar aan toe, maar je moet dan wel heel erg goed weten wat je zegt voordat je begint met beschuldigingen.

[JoJo_nl]

ik heb zo'n flauw vermoeden dat dit te maken heeft met ACPI 2.0 welke extra tabellen en onderdelen toevoegd aan de standaard ACPI.. dit zou kunnen betekenen dat er een foutieve waarde in het register van een van de acpi2.0 tabellen staat . Gezien linux hier niet mee overweg kan, kan dit ook resulteren in een ddst foutcode.

linux krijgt data van devices terug die niet bestaan kennelijk.. en omdat deze devices dus niet reageren zal het os een foutmelding teruggeven. Ik gok er op dat deze gebruiker een oude versie van SLUB heeft .. zie : http://kerneltrap.org/taxonomy/term/205
en dat deze timeouts veroorzaken waardoor een foutmelding onstaat welke met een flexibelizering van de timeout waardes opgelost kan worden ..

al met al is dit weer een duidelijk voorbeeld in hoeverre linux achterloopt vergeleken met windows.. de open source gemeenschap zou wat meer invloed moeten krijgen op al deze standaards van micro$oft zodat deze ook in deze netjes geimplementeerd kunnen worden..

[kozue]

Hoe kom je er bij dat linux niet met acpi 2.0 overweg kan? Dat zit er echt al jaren in. Sterker nog, het zou me niks verbazen als ze er in linux eerder mee waren dan MS, aangezien XP niet echt veel verandert is sinds 2001, en vista toen nog niet bestond. Er is btw ook al een acpi 3.0 specificatie, ik weet alleen niet in hoeverre er OS support voor is.

[MadEgg]

Wat ik mij dan direct afvraag is waarom Linux zich als Windows voordoet. Wat heeft de ACPI-specificatie daarmee te maken? Waarom vraagt het BIOS niet gewoon aan het OS of het de betreffende instructie ondersteund, ja of nee? Het daadwerkelijke OS heeft daar toch niets mee uit te staan?

In ieder geval mooi dat er geen sabotage plaats heeft gevonden, al kan ik mij eigenlijk ook niet echt een reden verzinnen waarom Foxconn Linux zou saboteren...

[dmantione]

ACPI-implementaties detecteren vaak het OS en schakelen bepaalde functionaliteit voorwaardelijk in. Als Windows 2000 bijvoorbeeld een bug heeft dat een bepaalde functionaliteit niet werkt, wil een moederbordfabrikant nog wel eens een test inbouwen dat alleen indien Windows XP gedetecteerd wordt bepaalde functionaliteit wordt geactiveerd.

Als Linux zich als Linux zou voordoen zou het in veel gevallen onnodige functionaliteit van het moederbord moeten ontberen. Vandaar dat het zich als Windows voordoet. Elk nadeel heeft zijn voordeel, moederbordfabrikanten kunnen zo niet om gebreken van Linux heenwerken, zoals in dit geval blijkbaar gebeurd is (waarbij niet overigens geenszins gezegd is dat als Linux zich als Linux zou voordoen dat de fabrikant daadwerkelijk Linuxspecifieke omweggetjes ingebakken ozu hebben).

[MadEgg]

Probeer je hiermee nu serieus te beweren dat moederbordfabrikanten hun hardware gaan aanpassen om om bugs in een besturingssysteem heen te werken? Als Windows ergens problemen mee oplevert is het toch aan Microsoft om dat op te lossen? Software is sowieso veel makkelijker te patchen dan een BIOS...

Rare praktijken dat.

[IStealYourGun]

Vaak hebben moederbord fabrikanten geen keus, ACPI is ontwikkeld door o.a Microsoft en Intel, partijen die zeker en vast eisen stellen aan de fabrikant.

[mae-t.net]

Ik denk dat het nog iets genuanceerder ligt dan dat het (alleen) om bugs gaat. Het zal ook zo zijn dat een oudere windowsversie minder ondersteunt dan een nieuwere. In de war raken van functies die je niet kent is dan wel een teken van een slordig ontwerp maar hoeft niet direct op bugs te wijzen.

[Reactie gewijzigd door mae-t.net op 5 augustus 2024 23:09]

[Pietervs]

tja, het zou niet de eerste keer zijn dat Microsoft fabrikanten financiële voordelen geeft als ze de concurrentie een voetje dwars zetten. Dus in die zin is het niet eens ondenkbaar dat er hier ook zoiets gaande was (tenminste, als je de beschuldigingen van TheAlmightyCthulhu gelooft en weet wat MS in het verleden allemaal geflikt heeft richting de concurrentie)...

Tegelijkertijd vraag ik me wel af: heeft TheAlmightyCthulhu nu wel of niet aangetoond dat met de juiste ACPI-tabellen er geen problemen meer zijn? Want als ik Garret goed begrijp, zouden altijd de juiste tabellen gebruikt worden (wat ik vreemd vind, want waarom worden er dan nog verschillende tabellen voor Linux en Windows "meegebakken"?).

Hmmm. Complottheorie of niet, er zitten wat rare kantjes aan het verhaal...

[Verwijderd]

Sterk punt MadEgg, was ook mijn eerste gedachte.
Moet gewoon OS onafhankelijk zijn. Als een specificatie open is dan zal het via het OS gewoon aangeroepen worden, of dit nu OS a of OS b betreft

[CAPSLOCK2000]

Windows is zo dominant dat veel fabrikanten nooit de moeite nemen om hun spul met iets anders te testen dan Windows, iets wat in het geval van ACPI meer regel dan uitzondering is, onder andere omdat het vreselijk moeilijk is om het goed te deon.
Aangezien de kans erg groot is dat de "niet-Windows" versie bomvol fouten zit, en niemand behalve de fabrikant daar echt iets aan kan doen, kan het verstandig zijn om maar te doen alsof je Windows bent, dan zijn de meeste fouten er in ieder geval uit.

[onetime]

wie van degene die commentaar geven heeft de oorspronkelijke threads gelezen?

• er gaan dingen onverklaarbaar catastrofaal fout in Linux
• als de bios wordt aangepast om Linux de zelfde data als Vista terug te geven verdwijnen de meeste fouten en kan er gewoon met het systeem gewerkt worden

wat is jullie conclusie?
terwijl ACPI OS onafhankelijk moet zijn...

overigens schijnt een britse manager van foxconn er dit weekend bovenop gesprongen te zijn.

[rickiii]

overigens schijnt een britse manager van foxconn er dit weekend bovenop gesprongen te zijn.

Inderdaad. Je kunt de Blog van de oorspronkelijke klager erop nalezen: http://izanbardprince.wordpress.com/

Hier houdt hij uitvoerig bij wat de voortgang is van deze zaak. Hij verdedigt zich tegenover de beschuldigingen van de kernel goeroe en je krijgt er een goed beeld van de situatie.

[Verwijderd]

Volgens de links in het Tweakers artikel worden er helemaal geen fouten opgelost, maar worden alleen de foutmeldingen verwijdert...

[elmuerte]

Waarom bevat de embedded software van ACPI een controle op een OS string!?
ACPI is toch een standaard? Waarom zou de hardware leverancier dan OS specifieke routines in zijn embedded software gebruiken?

Of lees ik die blog post nu verkeerd?

[Miki]

De reden is heel simpel, er zijn namelijk maar een aantal ACPI compilers in omloop. De bekendste zijn die van Intel en Microsoft en laat nou de meest gebruikte de Microsoft compiler zijn

Mobomakers zijn ook niet gek en zorgen dat hun hardware werkt voor het OS wat het meest gebruikt word. Zodoende dat de linux-kernel acpi aanvraag zich voordoet als windows, puur om en alleen om de juiste ACPI verwerking te krijgen. In principe is het dus gewoon heel slim van de kernel ontwikkelaars om dit "truukje" toe te passen.

[Verwijderd]

Leuk uitleg voor hoe het technisch in elkaar zit. Maar het feit blijft, als Foxconn zeggen dat Linux niet wordt ondersteund op die mobo en ze firmware uitleverd wat expliciet Linux in zich heeft maar niet getest, dan zou dat op het minst vermeld moeten worden op de doos. Of haal je dat stuk Linux eruit. Maar niet een kapot stuk firmware in laten zitten.

[Verwijderd]

@TurboTortoise.

Misschien dat je die technische uitleg ook eens even moest gaan lezen?!

Er zit helemaal geen specifieke Linux code in die Foxconn borden. Alles wordt aan de hand van Windows versie identificatie gedaan. Linux wordt gewoon als één van de vele windows varianten herkend, en zodanig behandeld.

Als zijn Ubuntu niet als moderne Windows (XP, Vista) herkend wordt, dan wordt het als een oudere versie herkent... (2000, NT ) Zouden er fouten in die schema's zitten, dan zouden die oudere Windows versies daar net zo hard mee te maken krijgen.

[SuperDre]

Maar misschien werken de linux tabellen wel met een versie van linux waarmee ze bij foxconn (of de makers van de bios) getest hebben.. dat is dus weer het nadeel van linux, je hebt zoveel verschillende distro's....

[mae-t.net]

Van Windows zijn er ook veel verschillende distro's. In de oorspronkelijke discussie over het Foxconn probleem kon je al zien dat er zelfs afhankelijk van de servicepackversie nog keuzes werden gemaakt door het bios. Daar staan regels als "Windows 2001" en "Windows 2001 SP1".

[kozue]

Vind het maar een raar idee, dat de BIOS keuzes maakt voor het OS wat er op draait

[Rob Coops]

Toch wel leuk om te horen dat de linux gemeenschap nog steeds netjes op dit soort dingen reageert, er zijn wel wat groepen die dit toch op een andere manier zouden hebben behandeled.

Ik kan me niet voor stellen dat foxconn met opzet Linux of welk ander OS dan ook zou tegen werken, hoe meer verschillende OS'en hoe meer kans dat je ook aan die gebruikers je moederbordjes kan verkopen.
Dat foxconn zegt dat Linux niet gecertificeert is op dit board zou wel eens heel goed kunnen zijn omdat ze zelf ook de nodige problemen hadden toen ze probeerde linux te draaien op een systeem met dit type moedrbord. Wat ik dan wel jammer vind is dat foxconn niet even contact op neemt met de linux kernel gemeenschap en hun vraagt om te helpen dit probeem op te lossen. Dat had in mijn ogen de meest ideaale oplossing geweest. Maar goed dat hoeven zij natuurlijk niet te doen.

[mjtdevries]

Ligt er een beetje aan wat je bedoelt met "de linux gemeenschap"

Als ik kijk hoe er hier op de FP werd gereageert en de klager zelf, dan kreeg ik daarvan geen goed gevoel over "de linux gemeenschap"

Dat er vervolgens één persoon is die wel netjes hierop reageert, dan geeft mij dat dan niet meteen weer een goed gevoel over de linux gemeenschap in het algemeen.

Netto denk ik dat er op dit moment vooral schade is aangericht. Hopelijk kan die schade herstelt worden. Wellicht dat sommigen van al die mensen die zo hard meeschreeuwen met samenzweringstheorien nu een lesje geleerd hebben. Dan kan het uiteindelijk toch een positief resultaat hebben.

[Fryske_Apoc]

een hoop drukte en geschreeuw om niks dus.

Jammer zou wel leuk geweest zijn als het wel waar was geweest.

Maar maby werkt Garret wel voor Foxcom.
Weer een complot erbij

[Ramoncito]

Hoeveel van ons hebben ooit na veel gezoek in de pc/software niet eens een verkeerde conclusie getrokken die zeer overtuigend leek en door een collega/kennis in een oogwenk ontkracht? (opeens valt dat kwartje (eurotje..) als je je het bespreekt met een collega).

Het enige verschil met nu is dat je je conclusies deelt op internet en het door nieuws sites snel overgenomen wordt (ook niet gek).

Ik heb van het onderwerp (Linux/kernels etc) geen verstand, maar hoe een misverstand (?) ontstaat kan ik wel begrijpen

[Verwijderd]

Er is toch wel een iets groter verschil.

Het is één ding om een fout te maken. Het is nog iets heel anders om dan gelijk tot de conclusie te komen dat er een groot samenswerings komplot is, en dat bedrijven bewust een OS saboteren. Voor je dat soort uitspraken doet, moet je toch eens even bij jezelf te rade gaan of dat niet erg onwaarschijnlijk is, en of je wel dusdanig zeker bent van je bewijzen...

Als je dan ziet hoe de vork in de steel steekt, dan wat dit geen eerlijke vergissing, die iedereen kan maken, maar gewoon een MS-hater, die dacht een stok gevonden te hebben waarmee hij kon slaan.

[Verwijderd]

Wat bazel je nou?

Ik heb nergens iets anti-microsofts gelezen in het vorige nieuwsitem hoor. Deze persoon was wellicht zelfs groot fan van microsoft, wie weet. Hij heeft alleen gezegd dat foxconn linux zou saboteren. Wie haalt hier microsoft nu weer bij?

[mjtdevries]

Uit het vorige nieuwsitem:

Inmiddels heeft TheAlmightyCthulhu een klacht ingediend bij de handelswaakhond FTC. Daarin stelt hij dat Foxconn en Microsoft zouden samenspannen en dat zij doelbewust het Linux-OS proberen te saboteren, waardoor beide bedrijven zich schuldig zouden maken aan het overtreden van de Amerikaanse mededingingswetten

TheAlmightCthulhu haalt Microsoft hier dus bij!

Voordat je anderen van bazelen beschuldig, kun je maar beter even controleren of je zelf niet degene bent die bazelt!

[Verwijderd]

Zoals ik op het vorige nieuwsbericht over deze zogenaamde bios-bug ook al reageerde; Linux gebruikt gewoon dezelfde BIOS als andere OS, dus vond ik het al een vreemd verhaal. Na starten van het O.S. draait het systeem trouwens op software drivers en wordt er maar nauwelijks van de BIOS gebruik gemaakt volgens mij. Het lijkt mij stug dat BIOS fabrikanten verschillende code entries gaan maken voor verschillende OS-en omdat dan het einde echt zoek is. Als het ene OS met de BIOS overweg kan moet dat voor een ander OS ook mogelijk zijn, mits de CPU architectuur ondersteund wordt.

[ronny]

Dit is wel heel erg kort door de bocht.

Als er onverhoopt toch wordt teruggevallen op de oudere '_os'-methode, dan wordt er echter een andere variabele ingesteld. Deze situatie kan echter niet voorkomen onder recente Linux-distributies, omdat de Linux-kernel al sinds de release van versie 2.6.9 vier jaar geleden zich voor de acpi-code als Windows voordoet. Er is geen mogelijkheid om vanuit de acpi-tabellen te ontdekken dat Linux wordt gebruikt. Van sabotage kan dan ook geen sprake zijn, stelt Garrett, temeer daar elk codepad in de acpi-tabellen ook door op zijn minst één Windows-versie gevolgd wordt.

Zoals blijkt zijn er wel degelijk verschillende codes voor verschillende besturingssystemen. Hierdoor kan het dus voorkomen dat er een codepath wordt gevolgd dat niet door een OS wordt ondersteund.
Het basis systeem moet namelijk wel goed werken voordat er drivers geladen worden.

[Verwijderd]

Volgens mij werkt hij niet bij Foxconn maar bij RedHat linux

Matthew Garrett, werkzaam als kernelontwikkelaar bij Red Hat

[Verwijderd]

Nee joh, hij heeft vast banden met Apache en er is wat MS geld op zijn rekening gestord, daardoor is hij nu helemaal MS fan en helemaal over. . Maar serieus, deze man doet het netjes, kijken wat er verkeerd is en dan rustig aan de community melden. Niet gelijk gaan schreeuwen, zet je alleen jezelf maar mee voor lul zoals nu dus ook wel blijkt.

En zoals ik ook al zei voor Foxcon is er geen slechte publiciteit, overal in de wereld in het nieuws geweest, en nu zelfs een rectificatie. Wat hadden ze nog meer willen wensen als gratis media coverage .

[JoJo_nl]

lees eens wat je schrijft....
ten eerste gaat t niet om foutieve firmware (bios is geen firmware ook nog eens) maar om een foutieve waarde daarin.. dit kan ook betekenen dat de waarde die uitgegeven word door de acpi niet herkend word door linux. (dat geeft Garrett ook aan in zijn stuk)
ten tweede als je een foxconn moederbord heb wat linux NIET ondersteund maar t wel in de biostabellen heeft staan, waar bazeer je dan je claim op dat het mobo dit wel zou moeten kunnen ?

ik ben het zeker met je eens dat men geen borden moet verkopen met half afgemaakte bios er op .. maar hier hoef je niet bang voor te zijn gezien een andere firma deze bios maakt en foxconn alleen vermeld welke registers ze gebruiken

[erikdenv]

BIOS is juist een typisch voorbeeld van Firmware.

[mae-t.net]

Behalve dat een BIOS juist wel firmware is, vraag ik me af of het inkopen van een BIOS wel gaat zoals jij het vermeld. Volgens mij koopt een moederbordfabrikant een standaard- of modulair BIOS en past dat eventueel met ondersteuning van de leverancier aan voor zijn hardware.

[JoJo_nl]

mijn idee....

het probleem zal gerust bij linux liggen en niet bij foxxconn en dan met name de drivers voor de chipset...

het zou leuk zijn als ze dit probleempje kunnen oplossen met vereende krachten ipv er over te bakkeleien wat vaak gebeurd zoals je zegt..

[CAPSLOCK2000]

't probleem met ACPI is dat het bijna alleen door de fabrikant opgelost kan worden.
Ik ben ook van mening dat Foxcon niks (opzettelijk) fout heeft gedaan, maar als ze slim zijn brengen ze een nieuwe BIOS versie uit waarin de problemen zijn opgelost. Dat levert wat positieve PR op, en kunnen we weer allemaal vriendjes zijn.