A Microsoft bemutatta nemrég egy bejegyzés útján az eBPF alrendszer megvalósítása a Windows számára amely lehetővé teszi tetszőleges illesztőprogramok futtatását, amelyek az operációs rendszer kernel szintjén futnak.
eGMP beépített bytecode tolmácsot biztosít a kernelben, hogy hozzon létre felhasználói területre betöltött hálózati illesztőprogramokat, hozzáférés-vezérlést és rendszer-ellenőrzést. eBPF és a .3.18 verzió óta szerepel a Linux kernelben lehetővé teszi a bejövő / kimenő hálózati csomagok, az átirányító csomagok, a sávszélesség szabályozását, a rendszerhívások lehallgatását, a hozzáférés vezérlését és a nyomon követést.
A JIT-fordítás révén a bytecode menet közben lefordul gépi utasításokká, és a lefordított kód teljesítményével fut. Az EBPF for Windows nyílt forráskódú az MIT licenc alatt.
Ma örömmel jelentjük be a Microsoft új nyílt forráskódú projektjét, amely az eBPF működését biztosítja a Windows 10 és a Windows Server 2016 és újabb rendszereken. Az ebpf-for-windows projekt célja, hogy lehetővé tegye a fejlesztők számára, hogy a Windows meglévő verzióin felül ismerős eBPF eszköztárakat és alkalmazásprogramozási felületeket (API-kat) használhassanak. Mások munkája alapján ez a projekt több meglévő nyílt forráskódú eBPF projektet vesz igénybe, és hozzáadja a "ragasztót", hogy azok Windows rendszeren fussanak.
eBPF for Windows használható a meglévő eBPF eszközökkel és biztosít egy általános API-t, amelyet az eBPF alkalmazásokhoz használnak Linuxon.
Különösen A projekt lehetővé teszi, hogy C-ben írt kódot bájtkódokká fordítson eBPF a standard Clang-alapú eBPF fordító segítségével és futtassa a Linux rendszernek már felépített eBPF illesztőprogramokat a Windows kernel tetején, amely egy speciális kompatibilitási réteget biztosít, és támogatja a szabványos Libbpf API-t az eBPF programokkal együttműködő alkalmazásokkal való kompatibilitás érdekében.
Ide tartoznak a középső rétegek, amelyek Linux-szerű összerendeléseket biztosítanak az XDP (eXpress Data Path) számára, és a socket-összerendelések, amelyek összefoglalják a Windows hálózati veremhez és a hálózati illesztőprogramokhoz való hozzáférést. A tervek célja, hogy teljes forrásszintű támogatást nyújtsanak az általános Linux eBPF illesztőprogramokhoz.
Az eBPF for Windows megvalósításában a legfontosabb különbség egy alternatív bytecode ellenőrző használata, amelyet eredetileg a VMware alkalmazottai és kanadai és izraeli egyetemek kutatói javasoltak.
Az ellenőrzőt egy különálló folyamatban indítják el a felhasználói térben, és a BPF programok futtatása előtt használják a hibák felderítésére és az esetleges rosszindulatú tevékenységek blokkolására.
Az érvényesítéshez Az eBPF for Windows az absztrakt értelmezési statikus elemzési módszert használja, mit, A Linux eBPF-hitelesítőjéhez képest alacsonyabb hamis pozitív arányt mutat, támogatja a hurokelemzést és jó skálázhatóságot biztosít. A módszer figyelembe veszi a meglévő eBPF programok elemzéséből nyert számos tipikus teljesítménymintát.
Az eBPF egy jól ismert, de forradalmi technológia, amely programozhatóságot, bővíthetőséget és mozgékonyságot biztosít. Az eBPF-et olyan esetekre alkalmazták, mint a szolgáltatás megtagadása és a megfigyelhetőség.
Az idők során az eszközök, termékek és szakértelem jelentős ökoszisztémája épült az eBPF köré. Noha az eBPF támogatását először a Linux kernelben hajtották végre, egyre nagyobb az érdeklődés az eBPF más operációs rendszerekben történő engedélyezésének lehetővé tétele iránt, valamint a démonok és a felhasználói módú szolgáltatások kiterjesztése a kernel mellett.
Ellenőrzés után a bájtkódot átadják a kernel szintű tolmácsnak, vagy átkerül a JIT fordítón, majd a kapott gépkódot futtatják kerneljogokkal. Az eBPF illesztőprogramok kernel szintű elkülönítéséhez a HVCI (HyperVisor Enhanced Code Integrity) mechanizmust használják, amely virtualizációs eszközöket használ a kernelben zajló folyamatok védelmére, és biztosítja a végrehajtott kód integritásának digitális aláírását.
A HVCI egyik korlátja az a képesség, hogy csak az értelmezett eBPF programokat ellenőrizheti, valamint az, hogy nem képesek azokat a JIT-vel együtt használni (választhat: további teljesítmény vagy védelem).
Végül ha érdekel, hogy többet tudj meg róla, konzultálhat a következő link.