بعد عام من التطوير، تم إصدار برنامج Hypervisor المجاني 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، والذي يقوم بترميز جميع الموارد اللازمة لتشغيل الضيوف مسبقًا. يتم تخصيص جميع الموارد، مثل الذاكرة المشتركة وقنوات إعلام الأحداث ومساحة الكومة الخاصة ببرنامج Hypervisor، مسبقًا عند بدء تشغيل برنامج Hypervisor بدلاً من تخصيصها ديناميكيًا، مما يؤدي إلى القضاء على حالات الفشل المحتملة بسبب نقص الموارد أثناء التشغيل.
- بالنسبة للأنظمة المدمجة المعتمدة على بنية ARM، تم تنفيذ الدعم التجريبي (معاينة التقنية) للمحاكاة الافتراضية للإدخال/الإخراج باستخدام بروتوكولات VirtIO. يتم استخدام النقل virtio-mmio لتبادل البيانات مع جهاز إدخال/إخراج افتراضي، مما يضمن التوافق مع مجموعة واسعة من أجهزة VirtIO. تم تنفيذ دعم واجهة Linux الأمامية ومجموعة الأدوات (libxl/xl) ووضع dom0less والواجهات الخلفية التي تعمل في مساحة المستخدم (تم اختبار الواجهات الخلفية لـvirtio-disk وvirtio-net وi2c وgpio).
- دعم محسّن لوضع dom0less، والذي يسمح لك بتجنب نشر بيئة dom0 عند بدء تشغيل الأجهزة الافتراضية في مرحلة مبكرة من تمهيد الخادم. من الممكن تعريف تجمعات وحدة المعالجة المركزية (CPUPOOL) في مرحلة التمهيد (عبر شجرة الأجهزة)، مما يسمح لك باستخدام التجمعات في التكوينات دون dom0، على سبيل المثال، لربط أنواع مختلفة من نوى وحدة المعالجة المركزية على أنظمة ARM بناءً على الحجم الكبير.LITTLE الهندسة المعمارية التي تجمع بين النوى القوية ولكنها تستهلك الطاقة والنوى الأقل إنتاجية ولكنها أكثر كفاءة في استخدام الطاقة. بالإضافة إلى ذلك، يوفر dom0less القدرة على ربط الواجهة الأمامية/الخلفية لأنظمة المحاكاة الافتراضية بأنظمة الضيف، مما يسمح لك بتشغيل أنظمة الضيف باستخدام الأجهزة شبه الافتراضية الضرورية.
- في أنظمة ARM، يتم الآن تخصيص هياكل الذاكرة الافتراضية (P2M، Physical to Machine) من تجمع الذاكرة الذي تم إنشاؤه عند إنشاء المجال، مما يسمح بعزل أفضل بين الضيوف عند حدوث أعطال متعلقة بالذاكرة.
- بالنسبة لأنظمة ARM، تمت إضافة الحماية ضد ثغرة Spectre-BHB في الهياكل المعمارية الدقيقة للمعالج.
- في أنظمة ARM، من الممكن تشغيل نظام التشغيل Zephyr في بيئة الجذر Dom0.
- يتم توفير إمكانية إنشاء مجموعة منفصلة (خارج الشجرة) لبرنامج Hypervisor.
- في أنظمة x86، يتم دعم صفحات IOMMU الكبيرة (الصفحة الفائقة) لجميع أنواع أنظمة الضيف، مما يسمح بزيادة الإنتاجية عند إعادة توجيه أجهزة PCI. تمت إضافة دعم للمضيفين المجهزين بذاكرة وصول عشوائي تصل سعتها إلى 12 تيرابايت. في مرحلة التمهيد، تم تنفيذ القدرة على تعيين معلمات cpuid لـ dom0. للتحكم في تدابير الحماية المطبقة على مستوى برنامج Hypervisor ضد الهجمات على وحدة المعالجة المركزية في أنظمة الضيف، تم اقتراح المعلمات VIRT_SSBD وMSR_SPEC_CTRL.
- يتم تطوير نقل VirtIO-Grant بشكل منفصل، ويختلف عن VirtIO-MMIO بمستوى أعلى من الأمان والقدرة على تشغيل المعالجات في مجال معزول منفصل للسائقين. يستخدم VirtIO-Grant، بدلاً من تعيين الذاكرة المباشرة، ترجمة العناوين الفعلية لنظام الضيف إلى روابط منح، مما يسمح باستخدام مناطق متفق عليها مسبقًا من الذاكرة المشتركة لتبادل البيانات بين نظام الضيف والواجهة الخلفية لـ VirtIO، دون منح حقوق الواجهة الخلفية لإجراء تعيين الذاكرة. تم تنفيذ دعم VirtIO-Grant بالفعل في Linux kernel، ولكن لم يتم تضمينه بعد في واجهات QEMU الخلفية وفي Virtio-vhost وفي مجموعة الأدوات (libxl/xl).
- تستمر مبادرة Hyperlaunch في التطور، بهدف توفير أدوات مرنة لتكوين إطلاق الأجهزة الافتراضية أثناء تشغيل النظام. حاليًا، تم بالفعل إعداد المجموعة الأولى من التصحيحات التي تتيح لك اكتشاف المجالات الكهروضوئية ونقل صورها إلى برنامج Hypervisor عند التحميل. تم أيضًا تنفيذ كل ما هو ضروري لتشغيل هذه المجالات شبه الافتراضية، بما في ذلك مكونات Xenstore لمحركات الطاقة الكهروضوئية. بمجرد قبول التصحيحات، سيبدأ العمل لتمكين دعم أجهزة PVH وHVM، بالإضافة إلى تنفيذ نطاق domB منفصل (مجال البناء)، مناسب لتنظيم تمهيد مُقاس، والتأكد من صحة جميع المكونات المحملة.
- يستمر العمل على إنشاء منفذ Xen لبنية RISC-V.
المصدر: opennet.ru