rm -rf / -> tegla

http://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directo…

Running rm -rf / on any UEFI Linux distribution can potentially perma-brick your system.

( jantyik | 2016. 02. 10., sze – 12:02 )

off: Arra nem is gondoltam, hogy ez is lehet sörnyitó.

( locsemege v | 2016. 02. 10., sze – 12:08 )

Nagyon tájékozatlan vagyok UEFI témakörében. Ott az nem járható, hogy partícionálok, inicializálom a filerendszert, majd telepítek? Eleve egy szűz HDD-re vagy SSD-re hogyan mászik fel az oprendszer? Nem igazán világos, hogyan zárhatja ki magát az ember örökre.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az UEFI-ről kellene többet tudnom. Ne nevess nagyon, ha hülyeséget írok. Olyasmiről van szó, hogy teszem azt, FLASH-ben tárolt digitális aláírások elérhetőkké válnak a /sys-en keresztül, a kernel file-ként láttatja, ez írásra is használható, s ha az ember szétbarmolja, akkor már addig sem fog eljutni, hogy USB-ről lehessen boot-olni az alaplapot? Valami ilyesmiről van szó?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( after | 2016. 02. 10., sze – 12:22 )

Ha jól értelmeztem a helyzetet, ez nem a systemd vagy a linux hibája, hanem az alaplap hibás UEFI implementációja. Windowson is "megsüthető" így egy olyan alaplap, mely ilyen hibás UEFIt tartalmaz, systemd-vel csak egyszerűbb kihasználni (akár véletlen is) a problémát, mert az efivars partíció fel van csatolva RW módban a fájlrendszerre. Megfelelő UEFI-t nem szabadna brickelnie.

Eleve miért kellene a felhasználó felé elérhetővé tennie olyan információt, ami nem azon az absztrakciós szinten van. Pont azért hozunk létre kernelt, azért van hardverabsztrakciós réteg, hogy a felhasználó ne is tudja azt, hogy a kernel alatt mi van. UEFI/BIOS/Coreboot, whatever.
Azzal, hogy van /sys meg efivars, és még írható is, teljesen keresztbeszarják a kernel hardverabsztrakciós feladatkörét, pedig ez lenne az egyik lényeges feladata a kernelnek.

Ja, csak epp ha valamit tekerni akarsz a hardveren, jo ha van ra mod. A kulonbozo valtozokat meg mifeneket /sys ala kitenni egy egyszeru modja ennek (KISS, illetve everything is a file mantra ismeros lehet). Pont ilyesmire van a sys, hogy a rendszer kulonbozo tuningolhato cuccait matatni lehessen.

Az ember neha szeretne az UEFI bizbazokat is matatni.

--
|8]

( sj | 2016. 02. 10., sze – 13:00 )

"Lennart Poettering had initially responded and simply said, "Well, there are tools that actually want to write it. We also expose /dev/sda accessible for root, even though it can be used to hose your system. The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root. But beyond that: root can do anything really." He then closed the ticket."

ennek a tagnak engedelye van arra, hogy full debil legyen?

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szerintem a Red Hat egyik vezető fejlesztőjének elég sok mindenre van engedélye, lehetősége.

Amúgy ez a szemlélet már a pulseaudio fejlesztésénél is kibukott belőle. Amikor recsegett-ropogott a hang, elszállt 100 % CPU idő felhasználásával a pulseaudio, debugolta, s kiderült, néhány alsa driver rosszul ad vissza pointert vagy buffer hosszt. Ez eddig senkinek sem tűnt fel, mert az alsa azon függvényét senki sem hívta korábban, az alsa fejlesztők egyes driver-ekben nem is implementálták normálisan.

Itt Lennart-nak lett volna lehetősége hibát elfedni, de inkább azt logolta be, hogy kedves felhasználó, cseszegesd az alsa fejlesztőket ezzel. Mai napig van ilyen a pulseaudio logokban.

Úgy látom, részben igaza van Lennartnak. Azért, mert ha a hibát nem annak keletkezési helyén kezeljük, más rétegben fedjük el, attól a konkrét eset megjavul, de ha más használja az adott szolgáltatást, az ugyanúgy rossz lesz. Ezen felül elfedhetünk olyan hibát, amit ezért nem veszünk észre, esetleg egész máshol burjánzik elő, ahol nem számítunk rá. Különben is, rétegek fölött nem nyúlunk át.

Mindamellett apróbb értelmezési tartomány ellenőrzéseket szerintem hasznos megtenni, ha az nem fáj senkinek, ilyeneket vagy javítani, ha lehet, vagy hibával visszatérni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

probald meg magyarra leforditani a google translate-tel, hatha akkor meg fogod erteni a problemat...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ez egy örök vita mert a felhasználó meg megoldást akar, őt nem érdekli melyik rétegben jön. Régebbi cégemnél volt ilyen eset hogy csak egy sima simlinket (ha nyelvtanilag helytelen elhiszem de lendületből irtam) kellett volna létrehozni és valami deployment ment volna de a 3rd level azt mondta nem, javitsák ki a toolban, különben mkinek használni kell a workaroundot. De a másik oldal meg nem értette meg ha meg tudom csinálni miért nem teszem és inkább várunk... Valahol mindkét oldlalnak igaza van és mégse.

Valahol mindkét oldlalnak igaza van és mégse.

nem. A 'masik oldal' hozzaallasa erosen nem professzionalis, mert nala van a hiba, tudja, de ennek ellenere nem akarja megoldani.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Eleve az a lényeg, hogy ha van egy X-ik absztrakciós réteged, annak minden alatta lévő rétegben lévő implementációs dolgot, így a hibát is, el kell, hogy rejtse.
Miért kéne tudnia például a pulseaudio felhasználójának, hogy a pulseaudio alatt egy hibásan implementált ALSA van? Ha tudja, akkor a pulseaudio rossz absztrakció.

A 20-25 évre visszamenő API és bináris kompatibilitásban a Windows a győztes, nem véletlenül használják üzleti alkalmazások. A 3 éves kompatibilitást sem tudó Linux meg csodálkozik, hogy nem árad felé az üzleti pénz dögivel, és mindent alkalmazáskonténerekkel kell megoldani.

Az API ha jól van megcsinálva, akkor független attól, hogy hogyan van implementálva. Fejlődött a Windows nagyon is sokat (például a komplett grafikus alrendszert kicserélték DirectX alapúra framebuffer alapról), mégis működik a visszafelé kompatibilitás. A gyakori változtathatóság nem ok arra, hogy eldobjuk a kompatibilitást. Persze ehhez jó tervezés kell, és mérnöknek kell lenni rendesen, nem csak hobbikóderkedni, valamint figyelembe venni a kliensek (az API felhasználók) szempontjait. Ilyen téren a Linux kernele egész jól teljesít, a userland viszont pocsékul. Csak egy dolog: glibc. Red Hat 6-ban (ami még sok-sok évig támogatott) 2.12-es glibc van, viszont sok alkalmazás frisebbet igényel.
Viszont Linuxon nem igazán támogatott annak a lehetősége, hogy több C runtime-ot is használj gond nélkül. Míg Windows alatt tök alap, hogy egyes szoftverek hozzák magukkal a megfleelő Visual C/C++ Runtime-ot.
Ne feledjük: változás != fejlődés.

( wachag | 2016. 02. 10., sze – 13:54 )

Kíváncsi vagyok, hogy ha nem systemd v. L.P. lenne mögötte, _akkor_ mekkora hiszti lenne a dologból.

off

Fedorát használok, és ugye Fedorában jelent meg először a systemd, hiszen Lennart illetve a Red Hat követték ezt el. Kezdettől fogva apróbb problémáktól eltekintve semmi bajom sincs vele, működik, teszi a dolgát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A systemd-nel altalanossagban egesz biztosan van ilyen.
De elsore (pl. nekem), kevesbe arrol szolt. Sokkal inkabb csak a teny, hogy nem vart modon tonkrevaghatja az ember a gepet, ahogy nem varna.

Aztan amit idezett sj, az alapjan van olyan vonala is az ugynek, hogy egy futobolond a csavo. Kicsit arra emlekeztet a nyilatkozata, mint amikor par eve a fovarosi utakert felelos akarki nyilatkozott, hogy ha szarok az utak, nem rinyalni kell, hanem lassan menni (pont).

Nalam az ilyesmi kiveri a biztositekot. Nem erzi a szerepet.

Aztan amit idezett sj, az alapjan van olyan vonala is az ugynek, hogy egy futobolond a csavo. Kicsit arra emlekeztet a nyilatkozata, mint amikor par eve a fovarosi utakert felelos akarki nyilatkozott, hogy ha szarok az utak, nem rinyalni kell, hanem lassan menni (pont).

Azért nem egészen. Ha útépítő munkáshoz akarjuk hasonlítani, akkor L.P. hozzáállása a Pulse vs. alsa ügyben inkább azé a betonozóé, akinek azt mondták, hogy ki van egyenesítve a föld, jöhet önteni a betont, aztán odament, ráöntötte a betont, és látta, hogy rohadtul de nem vízszintes alatta a talaj. Csinálhatta volna, hogy nekiáll vízmérték híjján ránézésre egyengetni maga alatt a földet (ez a beküld patcheket az ALSA-ba úgy, hogy nem feltétlenül rendelkezik a megfelelő hardware-rel...), csinálhatta volna, hogy leönti az egészet a francba, rádob egy vas lemezt, azt megpróbálja kiegyengetni, aztán még egy réteg betont (ez a körbetaknyolja PA-ban megoldás), vagy csinálhatta azt, amit tett, hogy visszaszólt, hogy ez így nem oké, nincs lehetősége _jól_ megoldani, és jöjjön vissza a talajegyengető-munkásember és végezze el a dolgát.

(egy kicsit másfelé terelve: ha van egy keverőpultod, amiből kiviszed a jelet egy erősítőbe, és az erősítő csatlakozója kontakt-hibás és nagy jelveszteséggel dolgozik [nem tartja magát az interfész definícióhoz, pont, mintha hibás pointereket adnál vissza], akkor a keverőpultod gyártójánál kezdesz panaszkodni, hogy de oldják meg?)

Hosszúra nyúlt metafórába csomagolt rejtett subscribe rovatunkat olvasták.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jogos, összefutottak a dolgot, egy fentebbi szálban jött elő a Pulse... egyébként ugyanarról van szó, egy hibás (a specifikációt nem tartó) implementációt nem akar saját rétegben elfedni; ami egy érthető álláspont (mert akkor innentől kezdve MINDEN hibás implementációt el kéne fedni, és gyakorlatilag az örökkévalóságig támogatni, mert még van valahol egy ember, aki ilyen alaplappal használ Linuxot...)

--
A linkelt cikkben egyébként:

Matthew Garrett who is also often involved in the UEFI Linux situation tweeted, "systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware. I think you get to blame me instead." ... He points out that mounting EFI variables as read-only could break some user-space applications and isn't the solution to the problem. He does have some ideas for addressing this issue, but didn't elaborate or issue any new patches yet.

Le akarják vinni a kernel szintre...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( Nyosigomboc v | 2016. 02. 10., sze – 20:34 )

Asszem UEFI-t is kerulni fogom amig tudom. Addig talan kiforrja magat. Sima BIOS-szal eddig nem volt problemam. Meg a secure bootot is meguszom.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

( uid_19334 | 2016. 02. 11., cs – 03:00 )

Az rm -rf / legnagyobb gondja amúgy nem az, hogy téglásítja a gépet, hanem hogy adatvesztéssel járhat.

( turul16 v | 2016. 02. 11., cs – 06:52 )

Pontosan mit kell torolni a /sys/firmware/efi/efivars/ -bol ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( thebeast | 2016. 02. 11., cs – 11:46 )

-Ezen az sem segít, ha a gépet átrakom nem UEFI módba?
-Ha átraktam nem UEFI-be korábban, akkor is megszívhatom?
-Honnan lehet kideríteni, hogy melyik alaplapok érintettek?

( carlcolt | 2016. 02. 11., cs – 14:56 )

Ezt a parancsot actually hasznaljak is az emberek? Azt hittem csak viccelnek vele. Miert torolne valaki a /-t ahelyett, hogy formazna a megfelelo eszkozt, amin meg akar szabadulni a file-oktol.

Amugy az Efi-s alaplapnak ilyenkor vissza kene allnia egy defaultra. Azt hittem ez elvarhato 2016-ban.

A parancsnak nincs értelme, de lehet demózni vele, kíváncsiságból megnézni, mi történik.

Amugy az Efi-s alaplapnak ilyenkor vissza kene allnia egy defaultra. Azt hittem ez elvarhato 2016-ban.

Ezt nem tudom értelmezni. Miért? Mi köze hozzá az alaplapnak? A kernelben implementálták, hogy a /sys alá kihozzák az EFI változóit. Mivel a piszkálására van API az EFI-ben, a kernel megmutatja file-ként, s lehet piszkálni. A gond az írhatóság, mert így el is lehet szúrni. Nem világos, miért kellene visszaállni alapértelmezettre. Mikor? Amikor megsejti az alaplap, hogy túl sok EFI változót piszkálnak, ami gyanús? Vagy mégis hogyan?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor kellene visszaállnia, amikor az "UEFI visszaállítás" jumpert felrakom, vagy valamit lenyomva tartva bekapcsolom. Az eredeti problémához visszatérve: nem tudom, hogy jó kompromisszum-e kinyírni az UEFI-változók írhatóságát, mert ezzel egyrészt megvédjük a gépet egy téglásítási lehetőségtől, másrészt ugrik egy adag hekkelhetőség. A jó az lenne, ha a hardware nem lenne olyan szar, hogy ki lehessen nyírni egy változó törlésével irreverzibilisen.

Nem jó ötlet, megmondom miért. Elvárhatjuk az operációs rendszertől, hogy a felhasználó érdekeit tartja szem előtt, és nem engedi neki felülírni ezeket a dolgokat. De nem várhatjuk el ugyanezt el egy rosszindulatú kódtól. Egyszerűen amíg maga a hardver lehetőséget biztosít arra, hogy olyan szinten meg legyen szoftverből piszkálva, hogy az végleges brick-et okoz, addig a hardver a hibás és javításra szorul.

Az egyik megoldás az volna, hogy a hardver maga ne tegye olyan dolgok megváltoztatását, ami a brick-et eredményezi. De ez nem teljes megoldás, firmware frissítést engedni kell valahogy. Viszont jó lenne, ha utolsó mentsvárként - ahogy írtad - a hardver képes lenne akármilyen halott, elrontott firmware-t felülírni egy gyári defaulttal.

( manfreed (nem ellenőrzött) | 2016. 02. 12., p – 11:08 )

Miért engedi a hardver hogy az user/oprendszer olyan módosítást végezzen, ami használhatatlanná teszi? Nekem nagyon nem úgy tűnik, hogy jó irányba fejlődünk.

Az, hogy mitől használhatatlan valami, azt maga a firmware nem tudja eldönteni. Egy érték egy adott szituációban értelmes lehet, míg máskor meg nem.
A firmware updatet pedig engedni kell - magából a firmwareből.
Annak nincs semmi értelme, hogy a hardverabsztrakciós réteg a hardvert kiengedi a felhasználói felületre (és a FS is felhasználói felület). Akkor mi értelme van a hardverabsztrakciónak?

Lehet, hogy nincs értelme a funkcionalitást a felhasználói felületre engedni, de még ha el is lenne rejtve, nem tudod garantálni hogy más szoftver, akár kártékony kód nem teszi meg valamilyen formában. Amíg a firmware lehetőséget ad arra hogy szoftverből ezek a dolgok felül legyenek írva, addig a firmware rossz.

És a firmware tényleg nem tudja eldönteni mitől használhatatlan valami, de nyilván a firmware-t is el lehet úgy készíteni, hogy ne lehessen szoftverből tönkrevágni. A döntés pedig a firmware készítőinek a kezében van. Az upgrade-t engedni kell, igazad van, de semmi nem akadályozza meg a hardver készítőjét, hogy az upgrade mechanizmust úgy készítse el, hogy legrosszabb esetben is egy gombnyomással, jumperral, akármivel vissza legyen állítható egy gyári változat. Miért is ne legyen egy extra read only chip, ami bizonyos feltételek mellett faék egyszerűséggel felülírja a firmware-t, és minden beállítását, hogy legyen mivel helyrehozni a brickelt eszközöket?

Ez rendben is van, de eleve tervezési hiba az UEFI írhatóságát kiengedi a kernelből.
Ha valaki fw-t akar frissíteni, arra meg ott az UEFI shell és az okos UEFI-k. Nem kell ahhoz operációs rendszert sem bootolni, hogy fw-t frissíts.
Nem az a baj, hogy a FW írható, az is baj. Az a baj, hogy a hardverabsztrakciós réteg engedi átcsordogálni azt, amit absztrahálnia kéne.

Ez mindig is lehetseges volt, es szerintem legyen is az !

Amit en elvarnek, az az hogy az alaplap leirasa tartalmazza,
hogyan lehet egy 12$ eszkozzel ill. egy masik szamitogeppel a gyari allapatot eloallitani.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor nézd meg, hogy a Unix-os filozófia mit mond... A hw-t a kernel teljesen elfedve ad egységes felületet a hardver lehetőségeinek a kihasználására. Persze, a fájlrendszerbe beemelt EFI-s dolgokat is lehet magyarázni, de az irány nagyon nem jó. Ilyen alapon a CPU mikrokódját is egy fájlként kéne reprezentálnia az OS-nek, és ha a júzernek úgy tetszik, hát írhassa már felül véglegesen tetszőleges szeméttel.

A linux odaadja a usernek rw-ben a teljes EFI-s területet, más OS-ek vélhetően nem tesznek így, úgyhogy a leírásba max. annyi kerülhetne, hogy a linuxszal tessen vigyázni, mert képes a hardvert tönkretenni, amire nem vonatkozik a garancia. Nagyjából ugyanolyan kiemeléssel/megjelöléssel, mint a túlfeszültség, sztatikus feltöltődés és hasonló dolgok veszélyére hívják fel a figyelmet.

A filo, azt mondja hogy a root az mindent tud utni,
ha hulye vagy rootkent akkor naprendszerek vagy akkar galaxisok pusztulasat is okozhatod.

A nem tudom mi a pontos konkret eset, igy nem tudom hogy mostani unlink -re break menyire logikus interface szempontbol vagy sem...
A cikk szerint Mas Os -ne is megteheted, csak nem ennyire egyszeruen.
(Egyes rendszereken a datum atallitas is teglasodast okoz :))

Nem szeretnem azt latni, hogy a boardokoat meg zartabba taszik csak azert,
mert user-ek letezeknek.

Firmware vissza tetele fizikalig minden boardon megoldhatonak kene lenie. (Az ennyim (elvileg) vissza irja backupbol, ha valami elcseszi. De egy backup az nem backup!)

Nem ertem miert nem mondjak el a gyartok a usernek, hogyan lehet vissza tenni valami gyari
firmewaret teglasitas utan ? (Meg ha garancia vesztessel jaro akcionak is nevezik)

Nem csak user PEBKAC miat mehet el a firmware !

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Firmware vissza tetele fizikalig minden boardon megoldhatonak kene lenie. "
Lattal te mar X86-os tabletet vagy telefont? Ahol eleve hozza sem fersz a boardhoz, es nincs semmilyen mas interfeszed a telefon fele, mint egy ki/bekapcs gomb, egy hang fel/le gomb es a touchscreen.

"Nem csak user PEBKAC miat mehet el a firmware !"
Normalis esetben de, csak amiatt.

Es nem, nem azert teszik zartta a firmwaret, mert userek leteznek. Arrol van szo, hogy ha egy kernel a firmware parametereit kiengedi userlandbe, akkor nem latja el a hardverabsztrakcios feladatat. Nem szabadna kiengedi a platform parametereit, plane nem allithatoan az operacios rendszernek a felhasznalo fele. Ha birizgalni akarja a platformot, arra ott az UEFI shell/BIOS setup, az pont arra valo. Az operacios rendszer meg nem.

"Lattal te mar X86-os tabletet vagy telefont? Ahol eleve hozza sem fersz a boardhoz, es nincs semmilyen mas interfeszed a telefon fele, mint egy ki/bekapcs gomb, egy hang fel/le gomb es a touchscreen."

Eleg valoszinutlen, hogy nem ferek hozza :)

"Normalis esetben de, csak amiatt."
(All cap) Root -kent hulyenek lenni, nem normalis eset !

Majdnem mindig emberi hiba, ha elveszeted a boot kepeseget, de nem mindig
az eszkozoz tulaja tehet rola elsosorban.

"firmware parametereit kiengedi userlandbe,"

Az altalad emlittett eszkozon is kell firmewaret frissiteni,
ill. a gyarto/szolgaltato adhat teglasito firmwaret.

Szerinted az OS -nek meg kene tagadni, hogy next fw -t lementse a user olyan helyre
amit next bootkor figyelmbe vesz a rendszer ?
Meg kene tagadni root-tol (local god admin) is ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A firmware frissítés kell, valóban, de ezt lehet ésszel is megvalósítani (például egy kernelmodul, amin keresztül elérhető a firmware, nem pedig odarakni az userland-be fájlként a firmmware-t tartalmazó komponens elérését).
A root az OS-en belül létező entitás, a hardverhez lehet, hogy semmi köze sincs (hint: virtualizáció: a vm-ek rendszergazdáinak nem kell szükségszerűen vmware adminoknak lenni).

'EFI variable filesystem' (pseudo fs) forgathato modul-kent,
es kulon kell explicite mountolni is.

Akar hogy forgatod modulba valamilyen file descriptor kellesz
a funkcionalitas eleresehez, nem feltetlenul egy teljes pseudofs.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"(All cap) Root -kent hulyenek lenni, nem normalis eset !"
Haha, lattunk mi mar olyan installert, ami legyakta a /usr-t, mert miert szar volt. Szoval lehetsz te total elovigyazatos root-kent, ha egy telepitendo szoftver bugos, es brickelheti az eszkozodet amiatt, mert a kernel nem rejti el eloled a hardvert, az bizony nagyon nagy baj.

"Majdnem mindig emberi hiba, ha elveszeted a boot kepeseget"
Ez tautologia, minden szoftveres hiba emberi hiba, ezzel nem mondtal semmi ujat.

"Az altalad emlittett eszkozon is kell firmewaret frissiteni,
ill. a gyarto/szolgaltato adhat teglasito firmwaret."
Es erre valo az EFI Firmware Management API. De attol, hogy meg updateljuk a firmware image-t API-n keresztul, nem jelenti azt, hogy filerendszerszinten irhatoaknak kene lennie az EFI runtime valtozoinak. Ne keverjuk a ket dolgot.

Igen, a sátántól való. A kernelnek nem szabadna elérhetővé tenni a hardver részleteit a felhasználó felé. Mert akkor nem végzi el jól a feladatát: nem tudja absztrahálni a hardvert.

Vagy hogy egy másik példát mondjak: alaplap hőmérsékletének kiolvasása.
Ahelyett, hogy userland eszközfüggetlen API lenne rá, elfedve a hardvert, van a /sys alatt megbúvó, eszközfüggő fileban egy adott érték, ismeretlen mértékegységben. Nálam most éppen a /sys/class/thermal/thermal_zone0/temp alatt kell keresni ezt az értéket, kiolvasva 50000-t kapok. Mi ez? Tizedcelsius? Ezredfahrenheit? Tízezredreamur? Nincs dokumentálva a userland számára, ofkorz a kernel dokumentációjának része. Egy userland dolog, és kernel dokumentáció van róla csak. Zseniális.
De pár éve még más néven szerepelt ez. Nagyszerű. És itt el is bukik a nagy hardverabsztrakciós réteg, ami a kernel lenne.

Az hogy kapsz egy redvas pseudo filet hatalmas abstrakcio, pl. BUS tipusa is el van fedve.

Az emlitett dev boardon, default opcio volt, a default kernelel, hogy flash azon reszet nem latom,
de nekem nem tetszet igy.

A logikadat kovetve, az OpenGL -nek nem kene szamottevo userland reszenek lenie,
ill. nem kene lati tudnod a binarist amit futat a GPU...

'Egy userland dolog, és kernel dokumentáció van róla csak.',
/sys: kernel interface a userland szamara.

Linux-on eleg nehez osszebanyaszi doksikat arrol, hogy hogyan is kene a kernelel beszelgetni
user oldalrol spec HW temaban :(.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"A logikadat kovetve, az OpenGL -nek nem kene szamottevo userland reszenek lenie,
ill. nem kene lati tudnod a binarist amit futat a GPU..."
Kevered a userlandet meg a hardverabsztrakciót. OpenGL esetén pontosan kevés helyen (sőt, sehol) sincs meg az, hogy te pontosan milyen szközön futsz, viszont van API arra, hogy az eszköz lehetőségeit lekérdezd. Elabsztrahálja előled azt, hogy ez egy NVidai Quattro vagy egy Intel GMA vagy éppen egy AMD. Cserébe le tudom kérdezni azt, hogy az adott eszköz mire képes.
Hasonló példa: Javascriptben sem kell tudnom, mi a user agent (azaz nem user agent stringet parzolok), hanem megnézem, milyen API-k elérhetőek.
Ez jó absztrakció, hiszen elrejti a konkrét platformot, de platform képességeit le tudja írni a felhasználó felé.

Miért is kéne látnom, hogy milyen binárist futtat a GPU? Az a GPU-ra tartozik, senki másra. Ugyanúgy, ahogy nem látom a relokált, ASLR-erezett binárist sem, amit a CPU futtat, és ez így van jól.

"/sys: kernel interface a userland szamara."
Nem. A /sys filerendszer hardvereszközök infóit is kiengedi a userland számára, device driverek adatait manipulálhatod vele. Egyáltalán NEM rejti el a platformot. Ez hatalmas hiba.

"Linux-on eleg nehez osszebanyaszi doksikat arrol, hogy hogyan is kene a kernelel beszelgetni
user oldalrol :(."
Csak és kizárólag a man(2) kell, hogy erre szolgáljon, nem a különféle sysfs leírások stb. Hiszen az a kernel API a userland felé. És nem hw-specifikus API kell, hanem a rendszer képességeinek (például van hőmérsékletszenzor benne, GPS szenzor benne stb) leírása kell API szinten.
Nem pedig az, hogy van egy STMicroelentronics STM213235345FOOBAR chip benne, amiből a 0xCFAB regiszterből kiolvasva kapunk egy valamilyen értéket. Kit érdekel? Nézd meg, az Android ezt meg tudja oldani szenzorfüggetlenül. Sokkal jobb a programozói API-ja, mint a bare Linuxnak, kell is rajta sokat dolgozni Google oldaláról. Nem véletlenül találtak ki ők maguknak saját Camera HAL-t, Input Device HAL-t, stb. A Linux HAL egyszerűen nem jó.

A psuadofs + EFI elott, kozvetlen memoria irassal tudtal hasonlot csinalni (titkos kopogas..),
vagy nem tudtad egyaltalan megteni. zero dokumentacio minden szinten.
pseudofs -el kaptal egy kvazi vendor fuggetlen interfacet.

'Miért is kéne látnom, hogy milyen binárist futtat a GPU',
Miert ne ? Pl. Mert tudni akkarod miert lassu az a szar amit irtal.

'Ugyanúgy, ahogy nem látom a relokált, ASLR-erezett binárist sem,'
De latom, es az alkalmazas maga is latja.

'Csak és kizárólag a man(2) kell, hogy erre szolgáljon'
'Hiszen az a kernel API a userland felé. '
A sensorok ugyan abba a kategoriaba tartoznanak mint a tcp,
vagyis man(7) lene.

Ha minden eszkozre vonatkozna a man 2 ioctl, akkot tobb mint 10 konyvet kene megtoltenie a pagenek.

man 2 nem a teljes api spec, csak az alacsony szintu reszet irja le.
A magasabb reszek meg eleg ossze vissza vannak dokumentalva, neha RTFS szinten,
folog azok a reszek eleg szegenyes dokumentaltak amit mezei programozo nem szokott jol imsert seged lib nelkul hasznalni.

'Android ezt meg tudja oldani szenzorfüggetlenül. Sokkal jobb a programozói API-ja, mint a bare Linuxnak, kell is rajta sokat dolgozni Google oldaláról.'

Arrol az API -rol beszelsz, ami Linux kernel felett fut es java-ban van irva?

A Sensoros peldadnal sem kellett tudnom register offsetet,
es a dokban bene van 'millidegree Celsius'.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"pseudofs -el kaptal egy kvazi vendor fuggetlen interfacet."
Olyan dologra, amit a kernelnek elrejtenie kéne, nem kvazi-vendorfüggetlenül megmutatni.

"Miert ne ? Pl. Mert tudni akkarod miert lassu az a szar amit irtal."
Erre való a debug board, és a tracelés.

"A sensorok ugyan abba a kategoriaba tartoznanak mint a tcp,
vagyis man(7) lene."
És van man(7) sensor API?

"Ha minden eszkozre vonatkozna a man 2 ioctl, akkot tobb mint 10 konyvet kene megtoltenie a pagenek."
Nem, ez csak akkor lenne, ha a Linux kernel nem tudná elfedni a hardver különbségeket.
Az egyes eszközosztályokat pedig igen is le kell dokumentálni. A Windows dokumentációja sem véletlenül sok-sok ezer oldal.

"man 2 nem a teljes api spec, csak az alacsony szintu reszet irja le.
A magasabb reszek meg eleg ossze vissza vannak dokumentalva, neha RTFS szinten,
folog azok a reszek eleg szegenyes dokumentaltak amit mezei programozo nem szokott jol imsert seged lib nelkul hasznalni."
És csodálkozunk, hogy nem akarnak vendorok fejleszteni Linuxra?

"Arrol az API -rol beszelsz, ami Linux kernel felett fut es java-ban van irva?"
Nem, hanem erről:
http://source.android.com/devices/index.html
Meg erre:
http://source.android.com/devices/halref/index.html

Itt leírják, hogy a device vendoroknak mit kell implementálnia ahhoz, hogy a programozók és a felhasználók számára kevésbé legyen probléma a hardverabsztrakció.

'Olyan dologra, amit a kernelnek elrejtenie kéne, nem kvazi-vendorfüggetlenül megmutatni.'

Ha nem lene, akkor az lene a baj hogy buta binuxban meg ez sincs,
bezzeg bazfoo mar reg tudja. Meg kulonben is a spec resze. !!!11!!!44

Szerencse hogy nem kotelzo resz :)

'És van man(7) sensor API?'
Az enyim nem talalja.
Sot az 'apropos thermal' sem megy.

'És csodálkozunk, hogy nem akarnak vendorok fejleszteni Linuxra?'
Igen, mert a total szopas -e miatt 2-3 nap google. Es csak egyszer kell megteni,
ezen nem kene elbukni.

'Itt leírják, hogy a device vendoroknak mit kell implementálnia ahhoz, hogy a programozók és a felhasználók számára kevésbé legyen probléma a hardverabsztrakció.'

Aha szoval egy nativ userland lib a Linux felett, tehat kernel nem hasznalhatatlan,
csak az userland lib nincs vagy rossz?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.