Hoofdcategorieën

Kernelgoeroe ontkracht geruchten Linux-sabotage door Foxconn

Door Harm Hilvers, maandag 28 juli 2008 11:00
Submitter: smoking2000, views: 13.353

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.

Tux (medium)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.

Volgende 11:13
Vorige 10:33

Reacties

«  1  2  »



En wie z'n profiel is dat?? Die van Matthew Garrett? Dat is niet degene die het punt heeft aangekaart, dus wat doet dat er toe?
Het gaat me er om dat er iedere dag dingen op forums worden gezet die onjuist blijken. Ook al had Linus zelf erop gereageerd, dat maakt het nog geen nieuws als het vervolgens niet waar blijkt te zijn.

[Reactie gewijzigd door MaZeS]



Volgens mij werkt hij niet bij Foxconn maar bij RedHat linux
Matthew Garrett, werkzaam als kernelontwikkelaar bij Red Hat

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 ;).

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 ;)

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.

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?

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!

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.

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.

Was dit zo'n grote issue in Linux-land dan? Ik heb er niets van meegekregen in ieder geval. In de discussie onder het artikel van Garrett is men volgens mij nog niet helemaal overtuigd.

In de discussie onder het artikel van Garrett is men volgens mij nog niet helemaal overtuigd.
Het grote nadeel van de open source community is dat het nagenoeg onmogelijk is om anderen te overtuigen van je gelijk, of hun ongelijk. Helaas wordt dat ook niet makkelijker gemaakt doordat een aantal 'grote' ontwikkelaars nog grotere ego's hebben. (bijvoorbeeld Theo de Raadt van OpenBSD is daar een erg klinkend voorbeeld van, maar binnen de linux comunity kan ik er ook wel een aantal noemen).

Daar hoef je echt geen Open Source Community voor te hebben hoor. Het is iets wat je terug vindt in welke community dan ook. Ook de mensen die bij commerciele bedrijven werken zijn overtuigd dat alleen zij het juiste product hebben. Het is nu eenmaal een karakter trekje van de mens. Om dat nu direct heel specifiek richting de Open Source Community te projecteren alsof het juist en alleen daar voor komt, is wel tamelijk stigmatiserend.

in commercieele bedrijven komt dat alleen lang niet zo vaak naar buiten, omdat er dan nog 30 lagen van managers, spinn controll e.d. tussen zit.

behalve als Steve Ballmer weer eens een bureaustoel door z'n kantoor heen smijt natuurlijk ;)

Het valide onderdeel van mijn punt is echter wel, dat dit voor commercieele bedrijven juist de aanleiding is om niet voor open source oplossingen te kiezen. Ongeacht of dit nu wel of niet ook voorkomt bij IBM, Sun, Novell, HP, etc, etc, etc, nergens wordt het in plain public uitgevochten op internet. En dat zouden de mensen binnen open source land nu eens heel goed tussen de oortjes moeten krijgen.

Je bent ongetwijfeld alle electronica-oorlogen vergeten (als klein voorbeeld) BR versus HD-DVD, DVD+ versus DVD-. Er zijn vele zaken waarbij bedrijven claimen dat hun oplossing het beste is, waarbij ze in geen geval willen kijken of ze niet samen met het bedrijf tot 1 standaard kunnen komen. Je kunt dit overigens ook op vele andere vlakken tegenkomen naast de electronica. Enfin, commerciele bedrijven gooien net zo gemakkelijk met modder als Open Source ontwikkelaars.

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...

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... :)

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

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).

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.

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.

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]


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.

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?

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.

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.

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..

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.

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.

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....

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".

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

@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.

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

BIOS is juist een typisch voorbeeld van Firmware.

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.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 11:13
Vorige 10:33
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: