● news.bsdnet.hu

Greg Kroah-Hartman megnyitó előadása az Open Source Summit India rendezvényen: AI-átirat: 0:00Üdv, Greg vagyok. Kernelfejlesztő vagyok, és olyan kódokról fogok beszélni, amelyek ténylegesen működnek, méghozzá determinisztikusan. 0:08Eredetileg a Rust és a Linux volt a téma. Linus tegnap beszélt egy keveset a Rustról. Én a C-ről és a Rustról fogok beszélni a Linuxban, mert a kernel a Rust felé halad. A Git is a Rust felé halad. Rengeteg projekt kezd el a Rust felé mozdulni. 0:23Mindezt azzal vezetném fel, hogy néhány évvel ezelőtt az egyik barátom azt mondta: – Ki kell próbálnod ezt az új nyelvet. Rustnak hívják. Én meg: – Mi? Nem, a C nagyszerű. Mire ő: – Nem, nem, nem. Újra szórakoztatóvá teszi a programozást. Én pedig: – Ugyan, C-ben is teljesen jó programozni. Igaza volt. Már akkor hallgatnom kellett volna rá. A Rust tényleg szórakoztató. Szórakoztatóvá teszi a programozást. Sok olyan dolog miatt nem kell többé aggódnod, amelyet a fordító megoldhat helyetted, és egy kicsit jobbá teszi a kódot. 0:48Ezért azzal kezdem: ha még nem próbáltad a Rustot, és a C-hez vagy a C++-hoz szoktál, próbáld ki. Lehet, hogy tényleg jó lesz. 0:55Tehát beszéljünk a Linuxról. A Linux ott van középen, alul. A Linux teljes feladata a hardver elvonatkoztatása. Ezt az emberek nem veszik észre. Hardverfüggetlennek láttatja a rendszert. 1:09Bármit betehetsz alá: ARM-ot, RISC-V-öt, x86-ot, S390-et. A legapróbb eszközöktől a világ legnagyobb szuperszámítógépeiig skálázódunk. Fölötte pedig megírhatod ugyanazt az alkalmazást, és Linuxon egyszerűen működik. 1:22A Linux a közvetítő réteg középen. Hardverfüggetlen. A mi feladatunk kijavítani a hardver összes hibáját, hogy nektek ne kelljen foglalkoznotok velük. Tehát középen egy kisebb káoszban vagyunk. 1:34Nagyok is vagyunk. A közösségünk tudomásom szerint a legnagyobb nyílt forráskódú közösség. Ezek a tavalyi számaink: több mint 5000 fejlesztő és legalább 375 vállalat. Nem igazán követtük pontosan. Valószínűleg már 450 körül járunk. Ezt alaposabban meg kellene vizsgálnunk. 1:49És gyorsan is haladunk. Ez a változtatási ütemünk. A legtöbb szoftverprojekt változtatási üteme kezdetben nagyon magas, mert próbálják megoldani a problémát. Ezután visszaesik, mert megoldották a problémát, és átállnak egy kellemes karbantartási üzemmódra. Ez a hagyományos modell. 2:03A Linux nem ilyen. Már 10–15 éve közel óránként kilenc változtatással haladunk. Ez őrület. Nagyon-nagyon gyorsan haladunk. 2:14Ennek oka, hogy a világ változik. Rengeteg munkába kerül létrehozni azt a kis hardverfüggetlen réteget, amely a felhasználói tér számára hardverfüggetlennek mutatja a rendszert. Új hardverek, új hálózati sebességek, új felhasználási módok és új energiagazdálkodási problémák jelennek meg. Rengeteg munkát végzünk odalent, és ezt újra meg újra elvégezzük. 2:33A Linux addig nem készül el, amíg a hardver fejlődése meg nem áll. 2:38A stabil ágainkon még mindig napi 40 változtatás történik. Az idők során sok különböző stabil ágat tartottunk fenn. Próbáljuk csökkenteni a stabil ágak számát, mert fontos, hogy idővel frissítsetek és naprakészek maradjatok. 2:51Napi körülbelül 13 CVE-nél járunk. Azt hiszem, mostanra talán már 14-nél. Ez nagyjából normális. Más operációs rendszereknél ugyanez a helyzet. Mi valójában egy kicsit ez alatt vagyunk. 3:02És ahogy Linus mondta, nyolc-kilenc hetente adunk ki új verziót. Ezt már több mint húsz éve így csináljuk. Nagyon determinisztikus. Órát lehet hozzá igazítani. Egyszerűen sorra gyártjuk a kiadásokat. Óraműpontossággal működik, lehet rá számítani. 3:17Erről tartottam egy teljes, nagy előadást, illetve volt egy 90 perces interjúm is. Keressetek rá: „Pragmatic Engineer Linux”. Nagyon jó interjú egy kiváló podcasterrel arról, hogyan csináljuk mindezt. 3:27És természetesen a Linux mindenhol ott van. Mindenben benne van. Android: eszközök milliárdjain és milliárdjain fut Linux. A világon minden más szinte csak kerekítési hiba. A szerverek apró kerekítési hibát jelentenek. 3:36Debian. A Debian futtatja a szervereket. Tehát két nyílt forráskódú projekt, az Android és a Debian működteti a világot. 3:43Chrome OS: azt hiszem, körülbelül 15 éve a legnagyobb példányszámban eladott laptopplatform. A Linux a desktopon már régóta itt van, csak senki sem vette észre. 3:52Az összes Wi-Fi-routeretek, az én mosógépem, és a kedvenceim, az automata tehénfejő gépek is Linuxot futtatnak. 4:02Rendben. Tehát ezt csináljuk. Most beszéljünk a kódról. 4:03Itt van némi C-kód. Ez valódi kernelkód. Hibás kernelkód. 4:12Gond nélkül lefordul, gond nélkül működik, és már régóta fut. A legfelső sorban azonban fogunk egy pointert, majd dereferáljuk anélkül, hogy ellenőriznénk, valóban érvényes-e. 4:24Itt a javítás. Hozzá kell adnunk egy ellenőrzést: ha nincs p, akkor hibát adunk vissza, elengedjük a lockot, és megyünk tovább. 4:32Ez egy CVE. Az operációs rendszer általunk kezelt rétegében – vagy az egész stackben – található hiba sebezhetőséggé válik, mert ha össze tudod omlasztani a rendszert, az sebezhetőség. Ha újra tudod indítani a rendszert, az sebezhetőség. Ha dereferálni tudsz egy pointert, az sebezhetőség. Ez egy CVE. Ezt még 2024-ben javítottuk. 4:50Ez azonban gyakori. Naponta 13 ilyet javítunk. Folyamatosan ilyen apró, triviális kis hibákat. Ostoba, parányi dolgokat. Ezeket javítjuk. 5:00Amikor tehát látjátok ezt a rengeteg CVE-t és ezt a sok nagy ügyet, valójában nincs szó semmi komolyabbról. Egyszerűen ilyenekről van szó. 5:07És a lock elengedéséről is. Emlékeznünk kell arra, hogy elengedjük a lockot, oda ugorjunk, majd továbbmenjünk. Ez egy másik nagyon gyakori problémánk. 5:14Itt van egy másik, 2024-es CVE. A Xen egy nagyon elterjedt virtualizációs megoldás, amelyet az AWS még mindig használ. Elfelejtették elengedni a lockot. Ha hiba történt, a rendszer megakadhatott. Ez megint sebezhetőség. 5:30Itt egy másik. Egy Wi-Fi-driver. 5:36A lockok elengedése miatt folyamatosan fejben kell tartanunk: dereferáltam ezt vagy sem? Elengedtem azokat a lockokat, amelyeket megszereztem? 5:45A kernelben és a fordítókban ezért olyan módszereket dolgoztunk ki, amelyekkel ez automatikusan kezelhető. Amikor kilépsz a hatókörből, a lockok automatikusan elengedésre kerülnek. 5:51A Rust ezt nagyon-nagyon jól csinálta. Átvettük az ötletet a Rustból, és beletettük a C-be. Most már van egy guard nevű megoldásunk. 5:58Ez a kód kijavítja a hibát. Ha elfelejtettük elengedni a lockot, akkor utána egyszerűen megfelelően elvégzi a takarítást. 6:08Ezt vettük át a Rustból. Ha a Rust holnap eltűnne, akkor is jobbá tettük vele a C-kódot. Ez fontos. A Rust ezt automatikusan elvégzi helyetted. 6:17Itt van néhány további, hasonló takarítás, egy másik típusú driverben. Lefoglalunk valamennyi memóriát, majd elfelejtjük felszabadítani. Vagy lefoglaltuk, és fel is szabadítottuk. Ezeket most már automatikusan kezelhetjük. 6:30Használhatunk például automatikus felszabadítást, majd visszaadhatjuk a pointert, miközben közben egyszerűen megfelelően elvégzi a takarítást, és kész. 6:39Ezt csináljuk most a kernelben: olyan automatikus felszabadítási megoldásokat, amelyekkel más nyelvek már régóta rendelkeznek. Most végre a C-ben is megvannak. A Rust arra késztetett bennünket, hogy újraértékeljük ezt, és jobban csináljuk. 6:50Most tehát a C-ben is vannak hatókörhöz kötött lockjaink és erőforrás-foglalásaink. Ez jó dolog. 6:55Megtanultuk, hogy ezek az apró, triviális hibák mindig megtörténnek. Vissza kell mennünk, és ki kell javítanunk őket. Amikor hibás kódot találunk a kernelben, hozzáadjuk ezeket a megoldásokat. Az újonnan érkező kódban pedig már eleve ezeket használjuk. 7:05Nem írjuk újra a régi kódot. A régi kód változatlan marad. Nem akarjuk folyamatosan felforgatni és módosítani. Az új erőforrás-kezelési megoldásokat azonban használjuk. Egyszerűbbé teszik a kódolást. 7:15Reviewerként nem kell folyamatosan fejben tartanom, hogy valóban elengedted-e ezt a lockot, vagy megfelelően felszabadítottad-e az erőforrást. 7:21Ez fontos, mert ennyi fejlesztő mellett a legértékesebb erőforrásaink a karbantartók és a reviewerek. Sokkal több fejlesztőnk van, mint reviewerünk, és több reviewerre lenne szükségünk. 7:32Ha egy reviewer feladatainak egy részét automatikussá tudod tenni, az jó. Könnyebben befogadhatom a változtatásaidat, és a kód ismét bekerülhet. 7:40Könnyebb review, kevesebb hiba, mindenki boldog. Azt akarjátok, hogy a karbantartók boldogok legyenek. Van nélkülük is elég más problémánk. 7:48Térjünk vissza ahhoz a régi Bluetooth-kódhoz. Ez C-ben van. Ha Rustban írnánk újra, így nézne ki. Szinte teljesen azonos, kivéve azt a kis kérdőjelet az első sor végén. 7:58Ha az a kérdőjel nincs ott, a fordító megáll. A kérdőjel azt mondja: ha hiba történik, kezeld. Visszaadja a hibát, és ennyi. 8:08Ha nincs ott a kérdőjel, a fordító megáll. Ez fontos. Olyan kódot akarunk írni, amely fordítási időben fogja meg a hibákat – nem a review során, nem futási időben, hanem fordítási időben. 8:21Ezt teszi meg nekünk a Rust. Kijavítja a kódot. Így ezekbe az apró, ostoba hibákba egyszerűen lehetetlen belefutni. Ha lefordul, működik. 8:30Lehetnek benne logikai hibák, de az összes ilyen apró hibánál, amelyben folyton elbotlunk, egyszerűen működni fog. 8:36A Rust a lockoknál is ezt teszi. Itt van némi Rust-kód. A struktúrában található értékhez kizárólag a lock megszerzésével férhetsz hozzá. 8:47A fordító nem engedi, hogy a lock megszerzése nélkül hozzáférj az értékhez. Egyszerűen megáll. Nem fordul le. 8:54Így tudod, hogy megfelelően megszerezted, majd megfelelően elengedted a lockot, és minden működik. Ez jó. Ezt akarjuk látni. 9:04E két dolog miatt teljes alrendszerek kezdik használni a Rustot. Az összes apró hibánk többségéért ez a két dolog felel: az erőforrás-foglalás és a lockkezelés. Lényegében ezeket csinálja egy kernel, és ez most megfelelően kezeli őket helyettünk. 9:14A Rust mindezeket a biztonsági problémákat már fordításkor megelőzheti, nem csak a review során. Ez nagyon-nagyon fontos. 9:22Ha lefordul, reviewerként tudom, hogy rendben van. Foglalkozhatok a logikával. 9:27Örülnék, ha logikai hibáink lennének. Örülnék, ha a biztonsági problémák valóban logikai hibák lennének. Az annyira kedves és kellemes lenne. 9:34A Rust esetében tehát ismét ugyanaz a mantra: egyszerűbb, könnyebb a review, kevesebb a hiba, és szórakoztatóbb. Mindenki boldog. 9:43Ahogy mondtam, sokkal több fejlesztőnk van, mint karbantartónk. Több mint 5000 fejlesztőnk van. A listán 700 karbantartó szerepel. Valójában körülbelül 150 központi karbantartónk van, akik a kód nagy részét átnézik. 9:57Ez rengeteg munka. Nagy az aránytalanság a reviewerek és a fejlesztők száma között, ezért egyszerűbbé akarjuk tenni a munkát. 10:03A reviewerekre optimalizálunk. Nem a fejlesztőkre optimalizálunk, mert fejlesztőből rengeteg van. 10:10Tehát ismét: ezért haladunk a Rust felé. Ki tudja kényszeríteni a nem megbízható adatok teljes ellenőrzését. Ez szintén nagyon fontos. 10:18Minden adat gonosz. Ez a mantra. Minden bemenet gonosz. A Microsoft ezt már régen megfogalmazta. A biztonság érdekében ellenőrizned kell az adatokat. A Rust ezt ki tudja kényszeríteni. 10:28Kikényszerítheted a memória-élettartam szabályait, a lockkezelési szabályokat, a hibakezelést és a típusbiztonságot. Ismét: fordítási időben. Nem futási időben, nem a review során, hanem fordítási időben. Ez nagyon-nagyon fontos. 10:40És íme az én állításom. Teljesen tudománytalan. Láttam a kernel összes CVE-jét az elmúlt 25 évben. Szerintem ezek 80 százaléka egyszerűen eltűnne, mert a Rust megfogná őket. 10:50Ezért akarom a Rustot. A valódi logikai CVE-ket jelentő 20 százalékot akarom. Azokat nem fogjuk kijavítani a Rusttal, mert logikai hibák. 10:58A Rust is teljesen jól össze tud omlani. Rustban is lehet elképesztően ostoba dolgokat csinálni. A Rust azonban kezeli helyettünk az összes apró, ostoba, triviális dolgot. 11:07A Rust valójában ugyanolyan csúnyán összeomolhat, mint a C. A Rust nem csodafegyver. 11:11Ez a memóriabiztonság valójában nem jelent megoldást a kernelben, mert ha túlcsordítasz egy puffert, vagy túlfutsz egy vektor végén, a kernel összeomlik. 11:22Amikor a Rust kezeli ezeket, a memóriabiztonság összeomlást jelent. Ez rendben van. Az összeomlás jó. Jobb, mint egy kompromittált gép, de attól még összeomlik. Továbbra is sebezhetőség, továbbra is CVE. 11:33Ez azonban logikai hiba. Örülnék, ha már csak logikai hibáink lennének. Sokkal egyszerűbbé tenné az életemet. 11:39Hadd összpontosítsak kizárólag a logikai hibákra, ne pedig a többi triviális hibára. 11:42A Rust tehát már ma is benne van a kernelben. Rengeteg munkát fektettek bele. 11:47Az emberek eredetileg azt mondták: – Írjunk egyszerűen egy drivert Rustban. Szép, önálló egység lesz. 11:53Csakhogy a driverek olyanok, mint egy fa levelei: minden mást felhasználnak. 11:57Egy drivernek foglalkoznia kell a lockkezeléssel, az erőforrás-kezeléssel, az interfészekkel, a felhasználói tér felé biztosított API-val – mindennel. 12:04Ezért C–Rust kötéseket kellett írnunk, hogy működjön. Sokunkat ez aggasztott igazán. 12:09Attól tartottunk, hogy nem fog megfelelően illeszkedni egymáshoz a C-s drivermodellünk és referenciaszámlálásunk, valamint a Rust referenciaszámlálása. 12:17A Rust-közösségből néhány igazán, igazán okos ember csatlakozott hozzánk, és segített elvégezni ezt a munkát. Jól oldották meg. A kötések ma már rendelkezésre állnak. 12:24Ma 113 000 sornyi Rust van a kernelben. Ennek többsége egyszerűen olyan kötés, amely a C-kódot a Rust-kódhoz illeszti. 12:34Egyes alrendszerekben az új drivereket már csak Rustban fogjuk elfogadni. Nézzétek meg a grafikus alrendszert. Ma ott vannak a létező legösszetettebb driverek. Azok kizárólag Rustban készülnek majd. Ez jelenti a munka nagy részét. 12:46A Binder, amely az Android része – az Android pedig működteti a világot –, most már Rustban van megírva. 12:52Jelenleg egyszerre két verzió található a kernelben. Egy időben futtatják őket, hogy ellenőrizzék, minden megfelelően működik-e. 12:57A C-verzió hamarosan eltűnik. A Rust-verzió marad, és a jövőben ez lesz az összes Android-eszköz alapja. Ez Rustban van. Eljutunk oda. 13:09Az idővel bekerülő új dolgokat tehát már Rustban lehet megírni. 13:13A Google készített erről egy nagy tanulmányt. Azt mondják: hagyjátok békén a régi kódot. Az új dolgokat írjátok memóriabiztos nyelven, például Rustban. Biztonsági szempontból ez a legjobb. 13:20Nem akarjátok megérinteni azt, ami már régóta létezik és működik. Ne írjátok újra. 13:25Mi sem fogunk semmit újraírni. Egyszerűen fokozatosan fejlődünk. 13:28Ahogy új driverek érkeznek, a régi dolgok eltűnnek, mert a hozzájuk tartozó hardvert már nem használják. A kernel idővel fejlődni fog, és működni fog. 13:35A Rust szinte az összes olyan architektúrához elérhető, amelyen a Linux működik. 13:39Azon a néhány architektúrán pedig, amelyhez nincs Rust-támogatás, a GCC-n dolgoznak. Van GCC-alapú Rust-fordító. A céljuk az, hogy le tudják fordítani és el tudják indítani vele a Linux kernelt. Azt hiszem, már majdnem eljutottak idáig. Ennek egy részhalmazán dolgoznak majd. 13:55Maga a Rust-közösség is felvette a Linuxot a tesztcsomagjába. A nyelvbe bekerülő minden egyes commit lefordítja és elindítja a Linux kernelt, majd ellenőrzi, hogy megfelelően működik-e. 14:03A Rust-közösség csodálatos. Ezek az emberek igazán, igazán okosak. Használjuk ki a segítségüket, amíg itt vannak. Rengeteg nagyszerű munkát végeznek nekünk. 14:11A változás nehéz. Sokan panaszkodnak ezekre a dolgokra. 14:15Szeretem a C-t. Nagyon-nagyon-nagyon sok éve programozom C-ben. Régebb óta, mint amióta az itt jelenlévők közül sokan egyáltalán élnek. 14:24Nehéz, de ahogy a barátom már régen mondta: szórakoztató. A Rust újra szórakoztatóvá teszi a programozást. 14:30Azt tapasztaltam, hogy nem kell többé azon aggódnod: hol vannak a referenciáim? Megfelelően szereztem meg a lockokat? Ezt megcsináltam? Azt megcsináltam? 14:39A logikára összpontosíthatok. Ez benne a nagyszerű. 14:41A logikára összpontosíthatsz, azokra a dolgokra, amelyekben programozóként jó vagy, mert tudod, milyen problémát kell megoldanod. A többivel nem kell foglalkoznod: a fordító elintézi helyetted, vagy szól, amikor elrontottad. 14:51Gyakran elrontod, de fordításkor szól róla. Ez fontos. 14:55Fordításkor kijavítod, és ha lefordul, akkor rendszerint talán még működni is fog. Ez igazán jó dolog. 15:01Újra szórakoztatóvá teszi a programozást, és erre egyre többen jönnek rá. Mi pedig fokozatosan fejlődünk. 15:08A Rust azonban arra is rákényszerített bennünket, hogy újraértékeljük a C-kódunkat. 15:11Rengeteg kód azért van bizonyos módon megírva a kernelben, mert az egész C-ben készült. 15:17Amikor megpróbálták ezt leképezni Rustra, kiderült, hogy vannak benne bonyodalmak. Egyes dolgokat egyszerűen azért csináltunk úgy C-ben, mert ott egyszerű volt. 15:23Kiderült, hogy ugyanehhez több ezer sornyi Rustot kellene írni. 15:27Leültünk a fejlesztőkkel, és azt mondtuk: – Nem. Hozzáadhatunk még egy sor C-t, és megszabadulhatunk attól a több ezer sortól. Mire ők: – Rendben, nagyszerű. 15:32Így közösen fejlesztettük tovább ezeket az API-kat. 15:36A kernel Rust API-jainak célja az, hogy ne lehessen helytelenül csinálni a dolgokat, ha a kód megfelelően lefordul. Ha megfelelően lefordul, akkor tudhatod, hogy rendben leszel. 15:44A C-ben rengeteg implicit dolog van. Például: rendben, ezt meg kell vizsgálnom, vagy ahogy korábban mutattam, megfelelően kell kezelni a lockokat. 15:51Ahhoz azonban, hogy ezek a kötések megfelelően működjenek, meg kellett vizsgálnunk a C API-jainkat. 15:53Mára rengeteg C-kódot módosítottunk a kernelben, és a kernel jobb lett tőle. 15:59Hozzáadtuk a guardokat és a hatókörhöz kötött referenciaszámlálást a C-hez, mert a Rust megmutatta, hogy ezt megtehetjük. 16:05Rengeteg típusbiztonsági megoldást adtunk hozzá. Sokkal több memóriabiztonsági megoldást építettünk a kernelbe és más API-kba, mert a Rust ráébresztett bennünket arra, hogy ezt megtehetjük. Megbízhatóbbá és jobbá tettük a C-kódot. 16:17Ha a Rust holnap eltűnne, a kernel akkor is jobb helyzetben lenne miatta. 16:21Ez a kísérlet tehát már nem kísérlet. 16:24A kernelközösség karbantartói tavaly összegyűltek. Minden évben találkozunk, és azt mondtuk: a Rust-kísérlet véget ért. Ez valódi. A jövőben elfogadjuk. 16:32A kernelközösségben jelentkeztek emberek a karbantartására, és nem fognak eltűnni. 16:38Csináljuk meg, haladjunk előre, és fejlődjünk megfelelően az idők során. 16:43A változás lehet jó. Szerintünk ez jó ötlet. 16:46Szerintem ez jó irány a Linux jövője számára, mert biztonságosabbá teszi a dolgokat. Erősebbé, biztonságosabbá és megbízhatóbbá teszi. 16:55A Linuxnak változnia kell az új hardverek miatt. A változás megtörténik. A Linux változása tehát jó dolog. Rendben leszünk. 17:02A változás megkönnyítheti a karbantartást, ami sokkal fontosabb. Ismét: kevesebb a karbantartó, mint a fejlesztő. A karbantartás egyszerűbbé válik. 17:10Azt akarom, hogy a fordító végezze el a munkát. A fordító a védelem első vonala. Ebben nagyon jól teljesít. 17:17A Rust tehát szórakoztatóbbá teheti a karbantartók munkáját, a felhasználók számára pedig biztonságosabbá teheti a Linuxot. Összességében ez a legfontosabb. 17:24És természetesen a világuralom a tervek szerint halad. 17:28Nagyon szépen köszönöm. trey @ gépház