پس از یک سال توسعه، هایپروایزر رایگان Xen 4.17 منتشر شد. شرکت هایی مانند Amazon، Arm، Bitdefender، Citrix، EPAM Systems و Xilinx (AMD) در توسعه نسخه جدید شرکت کردند. تولید به‌روزرسانی‌ها برای شعبه Xen 4.17 تا 12 ژوئن 2024 و انتشار رفع آسیب‌پذیری‌ها تا 12 دسامبر 2025 ادامه خواهد داشت.
تغییرات کلیدی در Xen 4.17:
- انطباق جزئی با الزامات برای توسعه برنامه های ایمن و قابل اعتماد به زبان C ارائه شده است که در مشخصات MISRA-C مورد استفاده در ایجاد سیستم های حیاتی ماموریت فرموله شده است. Xen رسماً 4 دستورالعمل و 24 قانون MISRA-C (از 143 قانون و 16 دستورالعمل) را اجرا می کند و همچنین تحلیلگر استاتیک MISRA-C را در فرآیندهای مونتاژ ادغام می کند که مطابقت با الزامات مشخصات را تأیید می کند.
- توانایی تعریف یک پیکربندی Xen ایستا برای سیستم‌های ARM را فراهم می‌کند که از قبل همه منابع مورد نیاز برای راه‌اندازی مهمان‌ها را کدگذاری می‌کند. همه منابع، مانند حافظه مشترک، کانال های اطلاع رسانی رویداد، و فضای پشته هایپروایزر، در هنگام راه اندازی هایپروایزر به جای تخصیص پویا از قبل تخصیص داده می شوند، و خرابی های احتمالی به دلیل کمبود منابع در طول عملیات را حذف می کنند.
- برای سیستم های جاسازی شده مبتنی بر معماری ARM، پشتیبانی آزمایشی (پیش نمایش فناوری) برای مجازی سازی I/O با استفاده از پروتکل های VirtIO پیاده سازی شده است. انتقال virtio-mmio برای تبادل داده با یک دستگاه I/O مجازی استفاده می شود که سازگاری با طیف گسترده ای از دستگاه های VirtIO را تضمین می کند. پشتیبانی از frontend لینوکس، جعبه ابزار (libxl/xl)، حالت dom0less و بک‌اندهای در حال اجرا در فضای کاربر پیاده‌سازی شده است (باطن‌های virtio-disk، virtio-net، i2c و gpio آزمایش شده‌اند).
- پشتیبانی بهبود یافته از حالت dom0less، که به شما امکان می دهد از استقرار محیط dom0 هنگام راه اندازی ماشین های مجازی در مرحله اولیه بوت سرور اجتناب کنید. امکان تعریف استخرهای CPU (CPUPOOL) در مرحله بوت (از طریق درخت دستگاه) وجود دارد که به شما امکان می دهد از استخرها در تنظیمات بدون dom0 استفاده کنید، به عنوان مثال، برای اتصال انواع مختلف هسته های CPU در سیستم های ARM بر اساس big.LITTLE. معماری، ترکیبی از هسته‌های قدرتمند، اما انرژی‌بر، و هسته‌های کم‌بازده اما کارآمدتر. علاوه بر این، dom0less توانایی اتصال frontend/backend paravirtualization را به سیستم‌های مهمان فراهم می‌کند، که به شما امکان می‌دهد سیستم‌های مهمان را با دستگاه‌های paravirtualized لازم بوت کنید.
- در سیستم‌های ARM، ساختارهای مجازی‌سازی حافظه (P2M، Physical to Machine) اکنون از مخزن حافظه ایجاد شده در هنگام ایجاد دامنه تخصیص داده می‌شوند، که امکان جداسازی بهتر بین مهمان‌ها را در هنگام بروز خرابی‌های مرتبط با حافظه فراهم می‌کند.
- برای سیستم های ARM، محافظت در برابر آسیب پذیری Spectre-BHB در ساختارهای ریزمعماری پردازنده اضافه شده است.
- در سیستم های ARM امکان اجرای سیستم عامل Zephyr در محیط ریشه Dom0 وجود دارد.
- امکان مونتاژ هایپروایزر مجزا (خارج از درخت) فراهم شده است.
- در سیستم‌های x86، صفحات بزرگ IOMMU (superpage) برای انواع سیستم‌های مهمان پشتیبانی می‌شوند، که امکان افزایش توان عملیاتی را هنگام ارسال دستگاه‌های PCI فراهم می‌کند. پشتیبانی از هاست های مجهز به رم تا 12 ترابایت اضافه شده است. در مرحله بوت، قابلیت تنظیم پارامترهای cpuid برای dom0 پیاده سازی شده است. برای کنترل اقدامات حفاظتی اجرا شده در سطح Hypervisor در برابر حملات به CPU در سیستم های مهمان، پارامترهای VIRT_SSBD و MSR_SPEC_CTRL پیشنهاد شده است.
- انتقال VirtIO-Grant به طور جداگانه در حال توسعه است، و با VirtIO-MMIO با سطح بالاتری از امنیت و توانایی اجرای کنترلرها در یک دامنه مجزا برای درایورها متفاوت است. VirtIO-Grant، به جای نگاشت مستقیم حافظه، از ترجمه آدرس های فیزیکی سیستم مهمان به پیوندهای اعطایی استفاده می کند که امکان استفاده از مناطق از پیش توافق شده حافظه مشترک را برای تبادل داده بین سیستم مهمان و باطن VirtIO، بدون اعطا می دهد. حقوق پشتیبان برای انجام نقشه برداری حافظه. پشتیبانی VirtIO-Grant قبلاً در هسته لینوکس پیاده سازی شده است، اما هنوز در backendهای QEMU، در virtio-vhost و در جعبه ابزار (libxl/xl) گنجانده نشده است.
- ابتکار Hyperlaunch با هدف ارائه ابزارهای منعطف برای پیکربندی راه اندازی ماشین های مجازی در هنگام بوت شدن سیستم، به توسعه خود ادامه می دهد. در حال حاضر اولین مجموعه پچ ها آماده شده است که به شما امکان می دهد دامنه های PV را شناسایی کرده و هنگام بارگذاری تصاویر آنها را به هایپروایزر منتقل کنید. هر چیزی که برای اجرای چنین دامنه های مجازی سازی شده ای لازم است، از جمله اجزای Xenstore برای درایورهای PV نیز پیاده سازی شده است. پس از پذیرفته شدن وصله ها، کار برای فعال کردن پشتیبانی از دستگاه های PVH و HVM و همچنین اجرای یک دامنه domB جداگانه (دامنه سازنده)، مناسب برای سازماندهی یک بوت اندازه گیری شده آغاز می شود و اعتبار همه مؤلفه های بارگذاری شده را تأیید می کند.
- کار بر روی ایجاد یک پورت Xen برای معماری RISC-V ادامه دارد.
منبع: opennet.ru