Pár napja jelent meg a Linux 4.6 stabil kiadása, ennek örömére tekintsük át a fontosabb változásokat és újdonságokat. Röviden: USB 3.1 SuperSpeedPlus (10 Gbps), OrangeFS, az új elosztott fájlrendszer, okosodott az OOM killer, azaz mostantól megbízhatóbb lett az elfogyott memória felszabadításának mechanizmusa, valamint megérkezett az Intel memory protection keys technológia támogatása. Továbbá kernel szintű támogatás van az új alkalmazásrétegbeli protokollok egyszerűbb kifejlesztésére. Megérkezett a 802.1AE MAC-szintű titkosítás (MACsec) is, ahogy az V. B.A.T.M.A.N protokoll verzió támogatása is helyett kapott az új kernelben. Végül, de nem utolsó sorban az OCFS2 immár felcsatolva is képes ellenőrizni az inode-okat és a cgroup névtér támogatás is helyet kapott.

Nem volt tehát eseménytelen ez a fejlesztési ciklus sem, lássuk a részleteket:

USB 3.1 SuperSpeedPlus (10 Gbps) támogatás

Az USB 3.1 specifikáció tartalmazza az új, SuperSpeedPlus névre hallgató protokollt, mely akár a 10 Gbps-es sebességet is támogatja. Azokat az USB 3.1-es eszközöket, melyek a SuperSpeedPlus technológiát támogatják, második generációs USB 3.1-es eszközöknek (aka. USB 3.1 Gen2-nek) nevezzük.
Fontos: A SuperSpeedPlus technológia nem azonos a Type-C-vel vagy az energia szállítással.

Megbízhatóbb OOM killer

A 4.6-os kernelt megelőző verziókban az OOM killer (ami folyamatokat lő ki ezért, hogy fel tudjon szabadítani némi memóriát) úgy működött, hogy az adott folyamat kilövésekor abban „reménykedett”, hogy a befejeződő folyamat memóriája időben felszabadul ahhoz, hogy ne fogyjon el a memória. A gyakorlatban azonban nem nehéz olyan esetet találni, ahol ez a konvenció nem működik, mert az OOM killder „áldozata” nem tud időben befejeződni, mert épp egy megszakíthatatlan állapotban van és egy olyan eseményre vár, melyet egy másik folyamat blokkol, ami pedig a memóriára vár… Ettől a kiadástól fogva ennek vége, bevezetésre kerül egy speciális oom_reaper („kaszás”) kernel folyamat, mely egyszerűen csak elveszi az OOM killer áldozatától a névtelen vagy kilapozott memóriát, hiszen joggal feltételezheti az OOM killer, hogy a kilőtt folyamatnak már úgysem fognak ezek kelleni…

Intel memória védelmi kulcsok (memory protection keys) támogatása

Ebben a kiadásban mutatkozik be az az új memória védelmi eszköz, melyet a jövőbeli Intel processzorok támogatni fognak: védelmi kulcsok. A védelmi kulcsokkal lehetőség nyílik a felhasználó által vezérelt hozzáférési maszkok kódolására a laptábla leírókban (pte). Ahelyett, hogy a laptábla leírókban lenne meg ez a védelem (melyek módosításához laponként kell egy rendszerhívás), a felhasználó védelmi maszk tartományokat hozhat lére. A felhasználói módból immár két bittel (hozzáférés kikapcsolva, írás kikapcsolva) módosítható a thread-local register (PKRU). Ennek köszönhetően nagy méretű virtuális memóriában is rugalmasan lehet változtatni a védelmi biteket, hiszen mindössze csak a CPU regisztereit kell módosítani, és nincs szükség minden egyes memórialap módosítására az érintett virtuális memória tartományban.

Továbbá lehetőség nyílik az MMU hozzáférési bitek pontosabb kezelésére. Például a végrehajtást és olvasást engedő bit elkülönül egymástól. A 4.6-os kernel eszközöket ad ennek kihasználásához, illetve egy magas szintű API-t a védelmi kulcsok használatához. Ha a felhasználói módú alkalmazás meghívja a mmap(..., PROT_EXEC) vagy mprotect(ptr, sz, PROT_EXEC) (tehát csak PROT_EXEC, PROT_READ/WRITE nélkül) függvények valamelyikét, a kernel tudni fogja, hogy ez egy különleges helyzet és beállítja a különleges védelmi kulcsot az adott memóriatartományra. Továbbá beállítja a megfelelő biteket a PKRU regiszterben, így a megjelölt memória olvashatatlan és írhatatlan lesz. Azaz a védelmi kulcsokkal a kernel „valódi” végrehajtási védelmet tud nyújtani: ha a kód végrehajtható, de nem olvasható, az tovább növeli a biztonságot (de ne felejtsük el, hogy egy rosszindulatú kód is módosíthatja a PKRU regisztert). A munka itt nem áll meg, a jövőben tovább dolgoznak azon, hogy további magas szintű API-kat biztosítsanak a védelmi kulcsok kezeléséhez.

OrangeFS, az új elosztott fájlrendszer

Az OrangeFS egy új, elosztott, jól skálázódó párhuzamos tároló rendszer. Eredetileg PVFS-nek (Parallel Virtual FileSystem ~ Párhuzamos Virtuális Fájlrendszer) nevezték, és 1993-ban alkotta Walt Ligon és Eric Bulmer. A PVFS a NASA nagy párhuzamos virtuális gép (Parallel Virtual Machine) tanulmányához készült, melyben tanulmányozták a párhuzamosan futó programok által produkált I/O mintákat. Ez a rendszer ideális azon problémák megoldására, melyek olyan nagy tárhelyet igénylő feladatok, mint a HPC, BigData, videó stream, genetika, vagy épp a bioinformatika. Az OrangeFS elérhető a hozzáadott rendszereszközökkel, felhasználói integrációs könyvtárakkal, MPI-IO-n át, illetve használhatja a Hadoop ökoszisztéma is, a HDFS fájlrendszer alternatívájaként.

Az alkalmazások általában nem igénylik, hogy az OrangeFS VFS-ként legyen csatolva, ugyanakkor az Orangefs kernel klienssel van rá lehetőséged. A kernel kliens kommunikál a felhasználói módban lévő démonnal, mely azokkal az Orangefs szerver démonokkal kommunikál, melyeken a fájlrendszert valójában megvalósítják. Ezek a szerver démonok (szinte mindig több van, mint egy) nem szükséges, hogy ugyanazon a gépen fussanak, mint a kernel kliens. Az OrangeFS fájlrendszer FUSE-vel is felcsatolhatóak.

Kernel kapcsolat multiplexer infrastruktúra a gyorsabb alkalmazásrétegbeli protokoll fejlesztésre

Ebben a 4.6-os kernelben jelent meg a Kernel kapcsolat multiplexer (Kernel Connection Multiplexer → KCM), mely infrastruktúrát és üzenet alapú interfészt biztosít a TCP felett, hogy ezzel gyorsítsa az alkalmazásrétegbeli protokollokat. A létrehozása mögötti motiváció azon a megfigyelésen alapul, hogy habár a TCP egy byte-okat szállító protokoll, nincs egyezményes koncepció az üzenethatárok jelzésére. Az általános megoldás, hogy szeletelt alkalmazásréteg protokollt valósítanak meg a TCP felett. A legtöbb TCP stack byte stream API-t biztosít az alkalmazásoknak, mely az üzenetek határolását, atomi írását/olvasását és a terhelés elosztás terhének kezelését mind az alkalmazásra hagyják.

A KCM-nek hála azonban az alkalmazás hatékonyan tud alkalmazásrétegbeli üzeneteket küldeni és fogadni TCP datagram felületen keresztül. A kernel megfelelő bizonyosságot ad az üzenetek küldéséről és fogadásáról, így a legtöbb alkalmazásnak már nem kell egy üzenet alapú protokollt implementálnia a TCP felett. Továbbá a KCM az alkalmazásrétegbeli üzenetekkel is dolgozhat, mégpedig irányítási és időzítési célból. Ennek hála, a többszálú alkalmazások egyszerűbb hálózati modellt használhatnak. Ahhoz, hogy a KCM képes legyen a TCP folyamban értelmezni egy üzenetet, a kernelbe építettek egy BPF (Berkeley Packet Filter) alapú üzenetfeldolgozót, mely feldolgozza az üzeneteket és visszaadja azok méretét. Ily módon szinte az összes bináris alkalmazás protokoll feldolgozható, ezért a legtöbb alkalmazás számára használhatónak kellene lennie a KCM-nek.

802.1AE MAC-szintű titkosítás (MACsec)

A 4.6-os kiadásban megjelent a MACsec IEEE 802.1AE támogatás, mely ethernet feletti titkosítási képességet jelent. Titkosítja és hitelesíti a helyi hálózat teljes forgalmát GCM-AES-128-cal. Ezzel lehetővé válik a DHCP forgalom és a VLAN-ok védelme, továbbá megakadályozza az ethernet fejlécek hamisítását. A MACsecet úgy tervezték, hogy együttműködjön a 802.1X MACsec Kulcs Megegyezési (MACsec Key Agreement) protokoll kiterjesztésével, ennek hála lehetséges a csatorna hozzárendelés és a kulcs szétosztása a csomópontok között. Természetesen a kulcsokat statikusan is szétoszthatja az adminisztrátor.

BATMAN V protokoll

A B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking ~ A mobil adhoc hálózatok jobb megközelítése) immár támogatja az V. protokollt, mely a IV. továbbfejlesztése. Az új verzió két alkomponensre bontja az OGM protokollt:

• ELP-re (Echo Location Protocol ~ Visszhang meghatározó protokoll), ami a szomszédok felfedezésére és a kapcsolat minőségének megbecslésére való
• illetve az új OGM protokollra, az OGMv2-re. Az OGMv2 tartalmazza azt az algoritmust, mely a hálózaton átküldi a metrikát és kiszámolja az optimális útvonalat.

A legnagyobb változás, melyet a B.A.T.M.A.N V. tartalmaz az az új metrika: a protokoll immár nem függ a csomagvesztésektől, csak a megbecsült áteresztőképességtől.

dma-buf: új ioctl a CPU és GPU közti cache koherencia kezelésére

A felhasználói térnek időnként valamiféle cache koherencia kezelésre van szüksége, pl. mikor a CPU és a GPU területeit a dma-buffal érjük el, egyazon időben. Ezzel megkerüljük a kezdődik/végződik koherencia jelzések azon problémáját, hogy azok továbbításra kerülnek a már létező dma-buf eszköz illesztőprogram vfunc hookjának. A felhasználói térből a jelzéseket a DMA_BUF_IOCTL_SYNC ioctl-lel éred el.

OCFS2: inode ellenőrzés, felcsatolt fájlrendszernél is

Az OCFS2-t legtöbbször magas rendelkezésre állású rendszereknél használják. Ha hiba történik, az OFFS2 csak olvasható módba teszi a fájlrendszert, mellyel csökkenti a rendelkezésre állást, illetve ez nem is mindig szükséges. Az errors=continue csatolási opcióval a fájlrendszer EIO hibát dob a hívó folyamatnak, de nem csatolja újra a fájlrendszert csak olvasható módban, továbbá a problémás fájl inode száma jelentésre kerül a kernel naplózásában. Ebben a kiadásban a kernel részévé vált egy nagyon egyszerű inode ellenőrző, mellyel ellenőrizhető vagy nullázható az inode. Ne feledd, hogy ez a képesség csak az olyan nagyon kis problémák megoldására van, melyek megakadályozzák a klaszter fájlrendszer mindennapos működését azzal, hogy az csak olvasható módba kapcsol. Ugyanakkor nem való a fájlrendszer többi komponensére támaszkodó, összetett ellenőrzésére. Ha ilyen gondod van, az offline fsck javasolt.

A felcsatolt fájlrendszer ellenőrzése és javítása a fájlszintű hibák javítására vonatkozik, ott is csak a különállókra. Az ilyen jellegű hibák javítása úgy történik, hogy a dmesg-ben jelentett inode számot beírod a /sys/fs/ocfs2/eszköz_neve/filecheck/check állományba, majd a kimenetből megállapítod, hogy milyen hiba történt. Ha úgy döntesz, hogy javítod a hibás inode-ot, akkor írd az inode számát a /sys/fs/ocfs2/eszköz_neve/filecheck/fix fájlba, majd olvasd be a fájlt, hogy megtudd, az inode javításra került-e vagy sem.

cgroup névterek támogatása

A 4.6-os kernelben megjelent a cgroup névterek támogatása, mellyel lehetővé válik a /proc/$PID/cgroup fájl és cgroup csatolások virtualizálása. Az új klón jelzés a CLONE_NEWCGROUP a clone(2) és unshare(2)-vel használható, melyekkel új cgroup névtér hozható létre. Ezzel lehetőség nyílik úgy beállítani a konténereket a konténer kezelő eszközökkel (pl. libcontainer, lxc, lmctfy stb.), hogy egy teljesen virtualizált konténert hozunk létre anélkül, hogy kiszivárogtatnánk a rendszerszintű cgroup hierarchiát.

Cgroup névtér nélkül a /proc/$PID/cgroup fájl a cgroup folyamat teljes útvonalát megmutatja. Olyan konténer beállításnál, ahol a cgroupok és a névterek a folyamatok elkülönítésére vannak beállítva a /proc/$PID/cgroup csak az elkülönített folyamat esetleges rendszerszintű információit tartalmazza.