Xen hypervisor 4.17 vrystelling

Na 'n jaar van ontwikkeling is die gratis hiperviser Xen 4.17 vrygestel. Maatskappye soos Amazon, Arm, Bitdefender, Citrix, EPAM Systems en Xilinx (AMD) het aan die ontwikkeling van die nuwe vrystelling deelgeneem. Die generering van opdaterings vir die Xen 4.17-tak sal tot 12 Junie 2024 duur, en die publikasie van kwesbaarheidsoplossings tot 12 Desember 2025.

Sleutelveranderinge in Xen 4.17:

  • Gedeeltelike voldoening word voorsien aan die vereistes vir die ontwikkeling van veilige en betroubare programme in die C-taal, geformuleer in die MISRA-C-spesifikasies wat gebruik word in die skepping van missiekritieke stelsels. Xen implementeer amptelik 4 riglyne en 24 MISRA-C-reëls (uit 143 reëls en 16 riglyne), en integreer ook die MISRA-C statiese ontleder in samestellingsprosesse, wat voldoening aan die spesifikasievereistes verifieer.
  • Bied die vermoë om 'n statiese Xen-konfigurasie vir ARM-stelsels te definieer, wat alle hulpbronne wat nodig is om gaste te selflaai, vooraf hardkodeer. Alle hulpbronne, soos gedeelde geheue, gebeurteniskennisgewingskanale en hiperviseerderhoopspasie, word vooraf toegewys by die aanvang van hipervisor eerder as dinamies toegewys, wat moontlike mislukkings weens hulpbrontekorte tydens werking uitskakel.
  • Vir ingebedde stelsels gebaseer op ARM-argitektuur, is eksperimentele (tegniese voorskou) ondersteuning vir I/O-virtualisering met behulp van VirtIO-protokolle geïmplementeer. Die virtio-mmio-vervoer word gebruik om data met 'n virtuele I/O-toestel uit te ruil, wat versoenbaarheid met 'n wye reeks VirtIO-toestelle verseker. Ondersteuning vir Linux frontend, toolkit (libxl/xl), dom0less mode en backends wat in gebruikersruimte loop, is geïmplementeer (virtio-skyf, virtio-net, i2c en gpio backends is getoets).
  • Verbeterde ondersteuning vir die dom0less-modus, wat u toelaat om die ontplooiing van die dom0-omgewing te vermy wanneer u virtuele masjiene in 'n vroeë stadium van bedienerselflaai begin. Dit is moontlik om SVE-poele (CPUPOOL) by die opstartstadium (via toestelboom) te definieer, wat jou toelaat om swembaddens in konfigurasies sonder dom0 te gebruik, byvoorbeeld om verskillende tipes SVE-kerns op ARM-stelsels te bind wat gebaseer is op die big.LITTLE argitektuur, wat kragtige, maar energieverbruikende kerns kombineer, en minder produktiewe maar meer energiedoeltreffende kerns. Boonop bied dom0less die vermoë om paravirtualisering-voorkant/agterkant aan gasstelsels te bind, wat jou toelaat om gasstelsels te begin met die nodige paravirtualiseerde toestelle.
  • Op ARM-stelsels word geheue-virtualiseringstrukture (P2M, Physical to Machine) nou toegewys vanaf die geheuepoel wat geskep word wanneer die domein geskep word, wat vir beter isolasie tussen gaste moontlik maak wanneer geheueverwante foute voorkom.
  • Vir ARM-stelsels is beskerming teen die Spectre-BHB-kwesbaarheid in verwerker-mikro-argitektoniese strukture bygevoeg.
  • Op ARM-stelsels is dit moontlik om die Zephyr-bedryfstelsel in die Dom0-wortelomgewing te laat loop.
  • Die moontlikheid van 'n aparte (buite-boom) hipervisor-samestelling word voorsien.
  • Op x86-stelsels word groot IOMMU-bladsye (superbladsy) vir alle soorte gasstelsels ondersteun, wat 'n groter deurset moontlik maak wanneer PCI-toestelle aangestuur word. Bygevoeg ondersteuning vir gashere toegerus met tot 12 TB RAM. By die opstartstadium is die vermoë om cpuid-parameters vir dom0 in te stel geïmplementeer. Om die beskermingsmaatreëls wat op die hiperviseerdervlak geïmplementeer is teen aanvalle op die SVE in gasstelsels te beheer, word die parameters VIRT_SSBD en MSR_SPEC_CTRL voorgestel.
  • Die VirtIO-Grant-vervoer word afsonderlik ontwikkel, wat van VirtIO-MMIO verskil deur 'n hoër vlak van sekuriteit en die vermoë om hanteerders in 'n aparte geïsoleerde domein vir bestuurders te laat loop. VirtIO-Grant, in plaas van direkte geheuekartering, gebruik die vertaling van fisiese adresse van die gasstelsel in toekenningskakels, wat die gebruik van vooraf ooreengekome areas van gedeelde geheue vir data-uitruiling tussen die gasstelsel en die VirtIO-agterkant moontlik maak, sonder toestaan die backend regte om geheue kartering uit te voer. VirtIO-Grant-ondersteuning is reeds in die Linux-kern geïmplementeer, maar is nog nie ingesluit in die QEMU-agtergronde, in virtio-vhost en in die toolkit (libxl/xl) nie.
  • Die Hyperlaunch-inisiatief gaan voort om te ontwikkel, wat daarop gemik is om buigsame gereedskap te verskaf vir die opstel van die bekendstelling van virtuele masjiene tydens stelsellaai. Tans is die eerste stel pleisters reeds voorberei wat jou toelaat om PV-domeine op te spoor en hul beelde na die hipervisor oor te dra wanneer dit gelaai word. Alles wat nodig is om sulke paravirtualiseerde domeine te bestuur, is ook geïmplementeer, insluitend Xenstore-komponente vir PV-bestuurders. Sodra die pleisters aanvaar is, sal werk begin om ondersteuning vir PVH- en HVM-toestelle moontlik te maak, sowel as die implementering van 'n aparte domB-domein (bouerdomein), geskik vir die organisering van 'n gemete selflaai, wat die geldigheid van alle gelaaide komponente bevestig.
  • Werk gaan voort om 'n hawe van Xen vir die RISC-V-argitektuur te skep.

Bron: opennet.ru

Voeg 'n opmerking