io_uring - a Linux kernel következő nagy dobása

Kernel

A eBPF után az io_uring lehet a Linux kernel következő nagy dobása. Prominens fejlesztők szerint az AIO alrendszer leváltását célzó io_uring "game changer" és ráadásul Linus szerint is "elég józan" (ismerve, hogy milyen szűkmarkúan bánik a dicséretekkel, ez nála azt jelenti, hogy kurva jó). Részletek itt.

( turul16 v | 2022. 09. 20., k – 09:50 )

Tud automatikusan atteni  adatot disk -rol tls offloaded socketbe ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

https://lwn.net/Articles/810482/

https://unixism.net/loti/ref-liburing/submission.html
"However, one of the file descriptors must represent a pipe."
file,socket kene

szerk:
src/include/liburing.h

 * This splice operation can be used to implement sendfile by splicing to an
 * intermediate pipe first, then splice to the final destination.
 * In fact, the implementation of sendfile in kernel uses splice internally.
 *

itt is ugy nez ki pipe kell.

Hasonlo kerdes:
https://stackoverflow.com/questions/48033320/is-there-an-asynchronous-v…

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A halozati reszen non-blocking lehet,
de az NVMe -re varni kellhet.

Van neheny workaround, amit linkeltem.
aio dev/shm teruletre (nem masol user memoriaba),
sendfile onnan, shm nem blockol.

sendfile -hoz belsoleg pipe lesz hasznalva,
kerdes az hogy jobb e nekem ha van egy managelt pipe -om mintha implicit letrehozza elpusztitja belul,
vagy mas implementacio kene.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( szekelyk | 2022. 09. 20., k – 09:56 )

A "Részletek itt" link ugyanerre a cikke mutat.

( denesb | 2022. 09. 20., k – 09:57 )

Mi mar hasznaljuk egy ideje (Glauber Costa dolgozott az io-uring supporton aki a cikkben is emlitve van), ha jol emlekszem meg javitasokat/fejleszteseket is szponzorizaltunk hozza.

:wq

( BaT | 2022. 09. 20., k – 10:43 )

allows you to load some simple program into the kernel and execute it all asynchronously and just get the result when they happen

Hmm, mintha láttam volna már ilyet valahol. JavaScript aszinkron I/O ugyanígy működik "néhány" szinttel feljebb.

( XMI | 2022. 09. 20., k – 11:51 )

Spectre és társai likeolják ezt :)

(Hint: Spectre v1-et gyakorlatban kihasználni eddig csak úgy sikerült, hogy eBPF-el szándékosan injektáltak gadget-et a kernelbe)

Régóta vágyok én, az androidok mezonkincsére már!

( persicsb | 2022. 09. 20., k – 14:01 )

Szerkesztve: 2022. 09. 20., k – 14:01

De ez nem olyan feature, ami évek óta benne van a kernelben? Legalábbis az io_uring 2019 óta része a vanilla kernelnek. Mi változott?

( Botond | 2022. 09. 20., k – 17:08 )

"io_uring uses a memory ring buffer shared between user space and the Linux kernel"

Csodálkoznék, ha ebből nem lenne nagyon hamar exploit.

Nem feltétlenül. Illetve nem úgy és nem azért.

Az eBPF-nél sem tetszőleges kódot injektálnak a kernelbe, hanem egy JIT fordítón keresztülmegy előtte és elég erősen sandboxolva van. Bár nem olvastam még nagyon bele, de meglepne, ha az io_uring nem az eBPF-nél már kitalált alapokra építene, hanem elkezdenék újrafeltalálni a kereket.

Ami ténylegesen bajt okozott, azok a nyomorult spekulatív CPU sebezhetőségek. Itt ugyanis elvileg teljesen hibátlan és logikailag tökéletesen sebezhetetlen kódot is lehet a támadáshoz gadget-nek használni, hiszen arra épít, hogy a CPU egy logikai kifejezés (Spectre V1 példánál maradva) kiértékelése előtt megtippeli az eredményt és annak megfelelően előredolgozik. Gyakorlatilag a kódban egy hibátlan logikai feltételt hibásan kiértékel és ezzel dolgozik tovább, aztán a végén rollbackeli az egészet, de maradnak sebességben kimutatható mellékhatások. A fejlesztők mindenféle toolokkal folyamatosan keresnek olyan kódrészleteket a kernelben, amik a támadót segítő gadgetként használhatóak lennének és körbevédik spekulációt átmenetileg letiltó utasításokkal (IPBP). Emiatt nem nagyon van gyakorlatban kihasználható spectre v1 sebezhetőség. Ha viszont user spaceből be lehet tölteni - egyébként logikailag hibátlan, sebezhetőséget nem tartalmazó - kódot a kernelbe, akkor a támadó tudhat magának gyártani saját gadget-et.

Ez ellen elvileg raktak védelmet a JIT fordítóba (link), de a másik bagázs meg azon dolgozik, hogy ezeket hogy lehet kijátszani.

Régóta vágyok én, az androidok mezonkincsére már!

Elso kozelitesben inkabb a virtio-ra hasonlit ez a ring bufferelgetes.

Semmi olyan gonoszra nem kell gondolni,
mas gonosz dologohoz lehet jo ha ismert cimen van kernel altal lathato adat, de onmagaban az nem veszelyes.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( asch v | 2022. 09. 20., k – 23:42 )

Szerkesztve: 2022. 09. 20., k – 23:42

\o/

Méregettem ilyen üzenet küldözgetést processzek között, hogy mennyi oda-visszát tud csinálni. Kis üzenetek esetén a szűk keresztmetszet a kernelbe belehívás overheadje lesz jelenleg. Jól értem, hogy például ilyen processzek közötti kommunikációt lehet úgy csinálni, hogy nem kell kernelhívást csinálni minden üzenetnél? Teszek kis programot a kernelbe, ami megcsinálja az üzengetést, és ennek csak feladom az adatokat egy ringbufferbe és már csinálja is?

Tehát meg lehet azt csinálni, hogy egy processzormagon csak a programom fut, ami a kernellel kommunikál, de a kernel csak egy másik magon fut, tehát nem történik process ütemezés és userspace-kernel átlépés sem, ameddig nem megy a processzünk várakozásba? Ezzel végre ki lehet hozni azt ami benne van a modern processzorokban de a folytonos taszkváltások miatt jelenleg csak RAM-ban történő számításoknál lehet kihozni a maximumot, amint kernelhez kell nyúlni, azonnal jön a performance penalty.

SPDKnal mar regota ugy hasznaljuk, hogy rabindeljuk Xdb fix magra, a kernelt meg eltiltjuk attol, hogy azokon a magokon barmit csinaljon.

 

de mondok egy sokkolot: egy 128 lanes PCI-e v5 szerveren 512GB/s IO megy at - a jelenlegi 7763 pedig "csak" 2x 204.8GB/s-et tud. ez azt jelenti, hogy IO-ban versenykepes lesz a halozat lassan. arrol ne is beszeljunk, hogy szerintem jovore jon a PCI-e v6 a szerverekben, 800Gbit/s-es SmartNIC-cekkel, ott mar 1TB/s-rol beszelunk.

Még a PCIe 4-es is csak alig 2-3 éve jött ki, el sem tudott terjedni, de már az 5-öt nyomják, ha jövőre tényleg jön a 6-os, akkor dögöljenek meg. Szép dolog a fejlődés, de az ilyen szabványokat nem szokás évente upgrade-elni. Pedig a fejlődésnek én nem lennék ellene, de ez már kapkodásnak tűnik, ha tényleg igaz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”