Nvidia lost beveiligingsprobleem in Linux-driver op

Videokaartfabrikant Nvidia heeft een fix uitgebracht voor een beveiligingsprobleem waarbij iemand die via de Nvidia-driver voor Linux toegang tot een systeem heeft, zijn rechten kan ophogen. Het bedrijf classificeert de bug als 'zeer risicovol'.

De bug werd vorige week op de Full Disclosure-mailinglijst gepresenteerd door Red Hat-medewerker Dave Arlie, die zei een proof-of-concept van het beveiligingsprobleem te hebben ontvangen. "Ik heb dit anoniem ontvangen en het is een maand geleden naar Nvidia gestuurd", schrijft Arlie, maar er kwam geen reactie vanuit de fabrikant.

De beveiligingsfout in de officiële driver die Nvidia voor Linux aanbiedt, maakte het voor een normale gebruiker mogelijk om te schrijven naar delen van het geheugen die niet voor normale gebruikers beschrijfbaar zouden zijn. Daardoor wordt bijvoorbeeld het verhogen van privileges mogelijk, zodat een normale gebruiker zichzelf root-rechten kan toe-eigenen.

Inmiddels heeft Nvidia een reactie uitgebracht, evenals een nieuwe versie van de Linux-driver. Omdat elke gebruiker het beveiligingsprobleem kan misbruiken, heeft Nvidia de kwetsbaarheid geclassificeerd als 'zeer risicovol'. Ook heeft het bedrijf een patch uitgebracht om oudere versies van drivers tegen het lek bestand te maken. De driver voor de 295-productreeks van videokaarten moet overigens nog worden bijgewerkt, aldus Nvidia.

Reacties (30)

[OddesE]

Op zich een nette reactie van NVidea, alleen jammer dat die reactie pas komt nadat het issue breed gepubliceerd is. Dit zie je toch heel vaak nog helaas, men neemt (de communicatie over) security issues pas serieus als het publiek wordt gemaakt.

Aangezien NVidea er nu zo snel bij is lijkt het alsof ze er intern wel al mee aan de slag waren. Jammer dat dat dan niet wordt doorgegeven, want dan had men het issue niet publiek hoeven te maken.

[RSpliet]

Valt mee denk ik, de patch is bijzonder magertjes. Het enige dat is veranderd is het verbieden van toegang tot de VGA-registers, plus een aantal andere engines.

Het probleem met de officiele driver ligt eigenlijk iets dieper: de complete videokaart werd gemapt naar userspace. Sinds X.org niet meer als root draait betekent dit dus dat elke gebruiker toegang krijgt tot het hele apparaat, welke op zijn beurt via diverse kanalen toegang heeft tot het systeemgeheugen. Het ontwerp van bijvoorbeeld nouveau doet dit niet en houdt registertoegang binnen de kernel. Om deze te misbruiken is root-toegang nodig, en tsja, als je die toch al hebt...

[Reactie gewijzigd door RSpliet op 25 juli 2024 00:54]

[hardwareaddict]

Nvidia drivers zijn closed source. Hoe weet je dit?

Het grote probleem met nvidia volgens Linus is juist dat zijn drivers niet open source zijn.

[RSpliet]

Nvidia drivers zijn closed source.

De patch niet!

Hoe weet je dit?

Dat krijg je als je mee ontwikkelt aan nouveau. Maar die mapping is te vinden in /dev/nvidia0.

[Reactie gewijzigd door RSpliet op 25 juli 2024 00:54]

[Verwijderd]

Nvidia drivers zijn closed source. Hoe weet je dit?

Waarom heb je de source van iets nodig om de architectuur van iets te weten ? Een hoop architecturen van software zijn gewoon gedocumenteerd ook al zijn ze closed source. Er is bijvoorbeeld plenty te vinden over hoe twitter of facebook aan de achterkant zijn zaakjes inregelt.

Bij de exploit zelf word ook al aardig wat info van de hand gedaan: http://www.phoronix.com/s...page=news_item&px=MTE1MTk

Het grote probleem met nvidia volgens Linus is juist dat zijn drivers niet open source zijn.

Dat was niet wat Torvalds zei. Het ging hem erom dat Nvidia zich niet meewerkend opstelde naar zijn idee.

[Verwijderd]

Volgens Linus komt het broeikaseffect ook omdat het niet open source is.
Het grote probleem met Linus is dat hij geen waarde kan inschatten aan intellectuele eigendommen.

Je haalt waarschijnlijk Torvalds door de war met Stallman. Linux werd bijvoorbeeld jaren lang ontwikkeld met een closed source VCS (Bitkeeper). Torvalds heeft echt geen moeite met closed source.

[Qalo]

Op zich een nette reactie van NVidia

Vind je? Als die proof-of-concept niet via andere kanalen was vrijgegeven, dan had Nvidia gewoon lekker zijn klep gehouden. Ik vind het juist een beschamende handelswijze, en het doet mij overkomen alsof ze het niet al te serieus nemen. Maar goed, dat zijn mijn "two cents"....

Dit is één van de zwakke punten van gesloten drivers: je zult moeten wachten tot de fabrikant er een patch voor wil uitbrengen. Maar blijkbaar doen ze liever niet al teveel moeite, en dus leggen ze er maar het zwijgen toe. Het valt me op dat lekken in open source programmatuur veel adequater worden opgepakt en sneller gefixt. Dus voor diegenen die mekkeren dat open source per definitie onveiliger is omdat iedereen de bron kan inlezen heeft dus bij dezen ongelijk.

Ben ik ongenuanceerd? Ja, misschien wel. Maar voorlopig spreken de voordelen van open source boven die van closed source in dit geval, in mijn bescheiden opinie.

[arjankoole]

Als die proof-of-concept niet via andere kanalen was vrijgegeven, dan had Nvidia gewoon lekker zijn klep gehouden.

dat is een beetje een slordige aanname. Het is goed mogelijk dat nVidia die maand is bezig geweest met het ontwikkelen/uitzoeken/testen van een patch. En dat is niet de quick fix die nu is vrijgegeven.

[gimbal]

Ja daar heeft iedereen een andere mening over - er is gewoon geen "juiste" manier om dit aan te pakken omdat de bron een onwenselijk doch onvermijdelijk iets is. Hoe erover gecommuniceert wordt is echt bijzaak; de driver blijft kapot totdat er een fix is.

Dus ja... dan liever dat er zo min mogelijk mensen kennis van hebben in dit specifieke geval. Als het nu opgelost zou kunnen worden door terug te rollen naar een eerdere driver versie zou ik er anders over denken.

[hardwareaddict]

Linux kernel an sich is onveilig als de pest natuurlijk.

Elke driver integreert zichzelf in de kernel en is dus in feite root en kan doen wat hij wil.

Afgezien daarvan is linux natuurlijk lek als een mandje op ander nivo. Er worden wel wat pogingen gedaan om write permissie af te schermen in linux, maar in pricnipe doen ze nooit wat tegen READ. Elk dingetje dat kernel heet is toegankelijk (read only) voor hele wereld in principe.

Dus bij het hacken van linux hoef je relatief weinig permissies te hebben om alles te zien. Dat is natuurlijk niet hetzelfde als het KUNNEN MODIFICEREN.

Je komt natuurlijk altijd wel met een paar packets binnen.

Vanuit spionage optiek gezien is het dus niet beter dan windows.

Linus geeft zelf aan dit fundamentele probleem niet te willen oplossen in linux.
De reden die hij aangeeft is dat de kernel 'langzamer' zou worden als hij het aanpakt.

Dat daarbij nvidia ook nog alleen gesloten drivers levert, dus drivers die je NIET zelf kunt compileren, is daarbij natuurlijk ook niet iets wat helpt.

[rob12424]

Je kan een driver ook als module aan de kernel haken. Dan isie niet in de kernel geprogrameerd. (dit heeft wel zijn nadelen maar wordt vaak gedaan met videodrivers)

[likewise]

Maar dat maakt voor het lek niks uit, de driver draait in kernel space.

Wanneer het ding gelinked wordt maaks niks uit.

[Blue_Entharion]

Nvidia is eindelijk weer eens serieus met linux ontwikkeling bezig, de drivers zijn nooit al te best geweest performance-gewijs (x-server drivers) Dus voor mij is dit een teken dat ze druk met de ontwikkeling bezig zijn.

Edit:

(Ik nam ook in beschouwing dat ze samen met Valve de drivers hebben geoptimaliseerd)

[Reactie gewijzigd door Blue_Entharion op 25 juli 2024 00:54]

[Noel]

Bugfixen is iets anders dan ontwikkeling imo.

[Verwijderd]

Inderdaad, maar de ontwikkeling die ze hebben gedaan in samenwerking met Valve bij het porten enoptimaliseren van Source naar Linux is wel een goede ontwikkeling.

Linux was voor het eerst sneller dan Windows in 3D! Ongerelateerd had Blue_entharion dus toch gelijk.

[VNA9216]

Die test had maar een heel marginaal verschil, 32 bit linux vs 64 bit windows kan bij games ook al een verschil maken. In theorie heeft de 64 bit variant waarschijnlijk meer geheugenbandbreedte nodig om dezelfde taken uit te voeren en zou dat in theorie het verschil al kunnen verklaren.

Ik neem aan dat valve iig wel zo vriendelijk is geweest een native 64 bit versie te gebruiken voor die benchmark onder windows, anders heb je ook de overhead van WoW64 er nog bij.

Daar komt bij dat je de situatie ook niet echt kan inschatten, wellicht hebben ze gewoon functionaliteit in de driver uitschakeld om zo meer FPS te halen en zie je daardoor af en toe kleine glitches etc ziet die ze voor lief nemen om de snelheid omhoog te gooien.

Het betekent iig niet direct dat de linux drivers beter zijn geworden of dat linux sneller is dan windows zoals sommige mensen roepen.

De grootste vriend en vijand voor linux software ontwikkeling (als in games) is het gebrek aan "standaarden".

support je als ontwikkelaar OSS, ALSA, ESD, jack en/of pulseaudio?
XFree86, Xorg en/of wayland ?
KDE,Gnome,XFce en ga zo maar door.

Het is gewoon een ramp om een applicatie neer te zetten die onder alle omstandigheden zonder distributie specifieke patches goed werkt, en je applicatie onder alle mogelijke combinaties te testen. Met als gevaar dat een hoop consumenten niet tevreden zijn over jouw product en je dus de volle laag gaat krijgen.
Ook zullen ze door de snelle ontwikkelingen in de linux wereld meer support moeten bieden. Installeer maar eens een spel als doom 3, of wolfenstein ET en dergelijke op een recente distributie en kijk eens hoe goed dat loopt. Installeer het daarna eens onder windows 7 (of straks en ik ben er redelijk zeker van dat die ervaring toch wel prettiger zal zijn.

[arendjr]

In theorie heeft de 64 bit variant waarschijnlijk meer geheugenbandbreedte nodig om dezelfde taken uit te voeren en zou dat in theorie het verschil al kunnen verklaren.

Dat lijkt me niet. Het enige datatype dat meer geheugen inneemt op x86-64 is een pointer (van 32-bit naar 64-bit gegaan). Maar pointers (die wijzen naar adressen in main memory) zijn niet echt interessant voor je GPU dus zul je daar ook niet naartoe sturen. Texture data en GL instructies zullen in elk geval niet groter worden.

Misschien dat de executable zelf in memory wel een klein beetje groter is geworden, maar dat is tamelijk irrelevant zolang je die data niet continu aan het verplaatsen bent.
Bovendien bevat x86-64 een groot aantal extra instructies en andere optimalisaties waar de 64-bit Windows-versie gebruik van heeft kunnen maken, en Ubuntu niet. Kortom, waarschijnlijk is Windows juist in het voordeel door z'n 64-bits.

Ik neem aan dat valve iig wel zo vriendelijk is geweest een native 64 bit versie te gebruiken voor die benchmark onder windows, anders heb je ook de overhead van WoW64 er nog bij.

Goed punt. Als ze dat niet gedaan hebben, zou dat mijn bovenstaande reactie grotendeels teniet kunnen doen.

Daar komt bij dat je de situatie ook niet echt kan inschatten, wellicht hebben ze gewoon functionaliteit in de driver uitschakeld om zo meer FPS te halen en zie je daardoor af en toe kleine glitches etc ziet die ze voor lief nemen om de snelheid omhoog te gooien.

Dat hebben ze in hun eigen blog al ontkracht. Beide versies waren visueel gelijkwaardig.

Het betekent iig niet direct dat de linux drivers beter zijn geworden of dat linux sneller is dan windows zoals sommige mensen roepen.

Dat ze beter zijn geworden lijkt me wel, anders zouden ze voor niets bezig zijn geweest

Wat betreft Linux vs. Windows geef ik je gelijk. Daar kunnen we op basis van 1 test case die nog een aantal onzekerheden bevat geen definitieve uitspraak over doen.

De grootste vriend en vijand voor linux software ontwikkeling (als in games) is het gebrek aan "standaarden".

support je als ontwikkelaar OSS, ALSA, ESD, jack en/of pulseaudio?
XFree86, Xorg en/of wayland ?
KDE,Gnome,XFce en ga zo maar door.

Allemaal vrij irrelevant. Voor audio gebruiken eigenlijk alle spellen OpenAL danwel SDL. (Om verdere verwarring te voorkomen, SDL verhoudt zich tot DirectX zoals OpenGL zich verhoudt tot Direct3D en OpenAL zich verhoudt tot DirectSound.)

Verschillende versies van de X server maak je je ook niet druk om, aangezien ze allemaal binair compatible zijn, en X applicaties sowieso vrijwel nooit direct met X communiceren. (Net zomin als dat je in Windows vrijwel nooit direct met GDI32 communiceert.)

Verschillende desktop environments hetzelfde verhaal. Ze draaien allemaal dezelfde applicaties, en de verschillende toolkits zoals Qt of GTK worden door games gewoonlijk geen van beide gebruikt.

Het grote voordeel dat Valve bezig is om Steam naar Linux te porten is dat Steam de spellen voor je download en installeert. Dus zowel eindgebruikers als game developer hoeven zich ook totaal niet druk te maken over vragen als gebruik ik Ubuntu Software Center of toch SUSE's YaST? Moet ik een RPM downloaden of een apt-bestand? Of moet ik misschien zelf gaan untarren en compilen? Ik ben met je eens, 3rd party software installeren die niet direct in de repository van je favoriete distro zit kan best een pain in the ass zijn. Maar die situatie wordt in ieder geval voor games zometeen keurig opgelost door Steam. Game developers zorgen dat hun game werkt met Steam, en de gebruikers weten waar ze die games moeten vinden. De rest doet er niet meer toe

[hardwareaddict]

Juist bij grote codes is 32 bits natuurlijk megasneller dan 64 bits, TENZIJ je de bits in de 64 bits goed gebruikt.

Denk aan vectors. De meeste software aansturing van games op de CPU is vrij knullig. De GPU doet het harde werk compleet gevectoriseerd, dus enig benul kunnen we wel ervan hebben dat je in principe elke 3d engine wel prima kunt VECTORISEREN.

Op het momnet dat je de zaak vectoriseert praten we niet over 64 bits maar over 128 bits of zelfs 256 bits (AVX). Dat zijn dan vectors voor graphics van 16 of 32 bits floats.

OpenGL is in principe alleen floats bijvoorbeeld.

Als we puurp raten over de 64 versus 32 bits dan is elke instructie in x64 natuurlijk 64 bits. Dat betekent dus dat processoren MINDER instructies per cycle kunnen issuen in 64 bits dan in 32 bits bij de meeste moderne processoren.

Logisch dus dat voor codes altijd 32 bits megasneller is.

Daar komt bij dat de meeste codes werken met 'integers'. Als die geport worden naar 64 bits dan ken ik weinig programmeurs die dat omschrijven.

In 64 bits moet elke 32 bits 'integer' die indexeert wel 64 bits worden. Dus dat kost een EXTRA instructie in 64 bits. Het is vrij logisch dat in dit geval dat gebeurt is.

Je moet dan dus MEER instructies uitvoeren om hetzelfde resultaat te bereiken in 64 bits.

De logica is aanwezig dat dat in dit geval 1 van de verklaringen is waarom het trager is.

Voor mijn eigen code is 64 bits voor code die geport is, ongeveer 7% tot 11% trager dan de 32 bits versie.

speciaal iets optimaliseren voor 64 bits is niet eenvoudig. ik denk dat niet 1 manager bij welk game bedrijf dan ook bereid is daarvoor te betalen. Ze slaan die engines ueberhaupt al in bij kleine bedrijfjes en bouwen ze niet zelf.

Uiteindelijk wat het meeste uitmaakt is de GPU anyway.

De meeste 3d engines zijn technisch niet erg hoogstaand. Ze hebben alle features wel, maar zijn niet bijster goed geoptimaliseerd.

You get what you pay for.

[arendjr]

Gast, je spuwt een hoop losse flarden aan informatie, maar de helft is totaal onsamenhangend, de andere helft is onjuist.

Als we puurp raten over de 64 versus 32 bits dan is elke instructie in x64 natuurlijk 64 bits.

Dit klopt niet. x86-64 bevat zowel alle 32-bit instructies als de nieuwe 64-bit instructies. 64-bit code is dus sowieso niet in het nadeel hier.

Dat betekent dus dat processoren MINDER instructies per cycle kunnen issuen in 64 bits dan in 32 bits bij de meeste moderne processoren.

Dat is zelfs volledige kolder. De 64-bits instructies zijn in dezelfde silicon geimplementeerd en worden op dezelfde kloksnelheid uitgevoerd, ze vereisen alleen 2x zoveel transistors. Het enige dat je dan kunt zeggen is dat ze waarschijnlijk iets duurder zijn om te produceren, maar er is geen enkele reden dat ze trager zouden zijn dan 32-bits instructies.

Daar komt bij dat de meeste codes werken met 'integers'. Als die geport worden naar 64 bits dan ken ik weinig programmeurs die dat omschrijven.

Behalve dan dat de default integer size op x86-64 nog steeds 32-bits is.

In 64 bits moet elke 32 bits 'integer' die indexeert wel 64 bits worden. Dus dat kost een EXTRA instructie in 64 bits. Het is vrij logisch dat in dit geval dat gebeurt is.

Behalve dat dat dus niet hoeft. Je kunt gewoon direct een 32-bits laden en de andere bits in het register op 0 zetten, in een enkele instructie.

Ik raad je aan dit eens te lezen: http://www.x86-64.org/documentation/assembly.html

Voor mijn eigen code is 64 bits voor code die geport is, ongeveer 7% tot 11% trager dan de 32 bits versie.

Misschien had je er beter gedaan je code niet te porten, en 32-bits integers lekker 32-bits te laten. Ik vermoed dat je ze naar 64-bits hebt omgezet zonder dat daar een directe aanleiding toe was, en ja, dat kan een performance penalty tot gevolg hebben.

speciaal iets optimaliseren voor 64 bits is niet eenvoudig.

Dat klopt. Maar het langzamer maken moet je zeker ook wel moeite voor doen (en het lijkt erop dat je dat nog voor elkaar gekregen hebt ook...)

[Reactie gewijzigd door arendjr op 25 juli 2024 00:54]

[blouweKip]

Linux was voor het eerst sneller dan Windows in 3D! Ongerelateerd had Blue_entharion dus toch gelijk.

Dit was vroeger (voordat direct3d werd doorgedrukt) met enige regelmaat het geval bij opengl en glide...

[arjankoole]

[...]

Dit was vroeger (voordat direct3d werd doorgedrukt) met enige regelmaat het geval bij opengl en glide...

Behoorlijk ja. Ik kan me nog herinneren dat ik de eerste Unreal Tournament zat te spelen onder Linux. (nou ja, eigelijk FreeBSD met Linux compat modus - werkte verbazingwekkend goed). Dat outperformde m'n Windows collega's toch aanzienlijk.

[BlackwaterEl1te]

Uuh is source niet nog steeds dx9 hoorde dat dx9 best slordig met resources om ging.
En dat dx10 en 11 dat al wat beter doen.

Natuurlijk als je hulp krijgt van nvidia en AMD engineers bij het poorten van je graphics engine is het logisch dat je het beter kunt optimaliseren of laten lopen.

En natuurlijk Valve heeft zijn eigen agenda die ze willen door drukken met Linux en de komst van meer concurrentie op win 8 ingebouwde app store. Valve is bang om zijn monopoly kwijt te raken op windows en probeert nu alvast voorbereidingen te maken voor linux.

Persoonlijk zie ik de games industry niet zo gauw overspringen naar Linux dat betekent dat ze complete engines moeten poorten naar openGL en denk niet dat Nvidia en AMD staan te wachten om overal engineers naar toe te sturen. Maar als linux groeit betekent het meer concurrentie en dat is beter voor iedereen.

[Dreamvoid]

? nVidia was juist jarenlang de enige met fatsoenlijke Linux drivers.

[Blue_Entharion]

Ze doen het wel goed, alleen de performance is slecht...

[hardwareaddict]

de performance van de nvidia drivers is prima, ze zijn echter niet open source, terwijl in linux verder alle software open source is.

Of je dat een probleem vindt moet je zelf afwegen - Linus vindt het wel een probleem.

Aan de andere kant wil hij niet de kernel veiliger krijgen, want dat zou de kernel trager maken. Natuurlijk om dan weer sneller te worden moet je dingen parallelliseren, maar hij is juist tegen parallellisatie.

Dus dat zit in een deadlock. Zo werkt dat bij veel geniale mensen uit verleden die nog op hun post blijven zitten en nog steeds dezelfde T-ford modellen willen produceren decennia later.

[Dreamvoid]

de performance van de nvidia drivers is prima, ze zijn echter niet open source, terwijl in linux verder alle software open source is.

Nee hoor, er zijn een heleboel closed source drivers. Op Android zijn de drivers van alle spelers (ARM, Imagination, nVidia, Qualcomm) closed source.

[kozue]

Dat ze beter zijn dan de concurrentie maakt het nog niet geweldig. Zolang de windows drivers beter werken beschouw ik de support toch als ondermaats. En dat terwijl ik als linux gebruiker net zo veel voor mijn kaart betaal dan een windows gebruiker.
Jammer dat er geen schot zit in dat nouveau. Maar eigenlijk verwacht ik daar niet zo veel van, ze lijken zich meer op de desktop te concentreren dan op performance in games.

[pe1dnn]

Nou, Linus Torvalds was anders niet echt te spreken over Nvidia...

[Verwijderd]

Klopt en geheel onterecht. Nvidia moet eigenlijk helemaal niets als er hardware word gemaakt zonder dat zel zelf werken aan de software er voor.