أعلنت Canonical في أكتوبر 2026 عن تغيير كبير في طريقة إقلاع Ubuntu 26.10 على الأنظمة التي تعتمد Secure Boot. إصدار GRUB الموقّع رقمياً (Secure Boot) في Ubuntu 26.10 لم يعد يدعم تثبيت /boot على أنظمة الملفات Btrfs أو XFS أو ZFS، و كذلك لا يدعم LVM أو LUKS encryption أو software RAID (ما عدا RAID1). التحديث يشمل أيضاً حذف دعم HFS+ و Apple partition table و تحميل صور JPEG و PNG في GRUB. السبب الأساسي: تقليل سطح الهجوم بـ تقليل عدد parsers التي تعمل قبل تحميل kernel. Canonical توصي من يحتاج الـ full GRUB functionality مع Secure Boot أن يبقى على Ubuntu 26.04 LTS (مدعوم حتى 2036 و 2041). رد الفعل من المجتمع كان تحفظي، خاصة من المستخدمين ذوي الإعدادات المخصصة للإقلاع.

السياق: GRUB و Secure Boot و سلسلة الثقة

Ubuntu 26.10 Secure Boot GRUB parsers

ما هي سلسلة الثقة (Chain of Trust)؟

Secure Boot آلية أمان في firmware الحاسوب تضمن أن kernel و المكونات المبكرة الأخرى لم تُعدّل بـ طريقة ضارة. العملية تسير هكذا:

  • Firmware الجهاز يبدأ
  • يحمّل برنامج shim (موقّع بـ key من الـ manufacturer)
  • shim يتحقق من GRUB و يحمّله
  • GRUB يقرأ /boot و يحمّل kernel
  • Kernel يبدأ

كل خطوة توقّع الخطوة التالية. هذا يسمى chain of trust. إذا حدث خطأ في أي خطوة، النظام يرفض الإقلاع.

المشكلة: Parsers في GRUB

GRUB تحتاج إلى أن تقرأ /boot لكي تحمّل kernel. لكن /boot قد يكون على أنواع مختلفة من filesystems: ext4، Btrfs، XFS، ZFS، إلخ. لهذا GRUB تحتوي على parsers لكل filesystem type. كل parser هو كود يقرأ صيغة الـ filesystem و يستخرج الملفات. المشكلة: كل parser محتمل أن يحتوي على bugs أو vulnerabilities. Researchers وجدوا عدداً من Secure Boot bypass vulnerabilities في سنوات الأخيرة — mostly من bugs في GRUB parsers. مثال CVE تاريخي: Secure Boot bypass في GRUB من خلال parsing bugs في XFS و ext4 parsers. المهاجم قد يضع kernel ضار على الـ disk، و GRUB تحمّله لأن parser فيها لم تتحقق بشكل صحيح.

الحل: تقليل الـ Parsers

استراتيجية Canonical بسيطة: حذف parsers غير ضرورية من الـ signed GRUB (النسخة المستخدمة مع Secure Boot). بدلاً من دعم 10+ filesystems، الآن signed GRUB تدعم فقط:

  • ext4 (الأشهر و الأكثر استخداماً)
  • FAT (لـ EFI boot partition)
  • ISO9660 (لـ CD/DVD boot)
  • squashfs (لـ snaps)

النتيجة: سطح هجوم أصغر. عدد parsers أقل = عدد bugs محتمل أقل.

التفاصيل الفنية للتغيير

ما الذي تم حذفه؟

من GRUB الموقّع في Ubuntu 26.10:

  • Btrfs filesystem parser
  • XFS filesystem parser
  • ZFS filesystem parser
  • LVM (Logical Volume Manager) support
  • LUKS encryption support
  • Software RAID support (ما عدا RAID1)
  • HFS+ (Apple) filesystem support
  • Apple partition table support
  • JPEG و PNG image loading (أي backgrounds)

إذا كنت تستخدم واحد من هذه؟

إذا كان /boot عندك على Btrfs أو ZFS مثلاً، و تفعّل Secure Boot، فـ GRUB الموقّع لا يمكنه أن يقرأ /boot. النتيجة: الجهاز لن يقلع. لكن، هناك خيارات:

  • عطّل Secure Boot (GRUB الكامل سيحمّل مع جميع الـ features)
  • ابقَ على Ubuntu 26.04 LTS (مدعوم حتى 2036)
  • انقل /boot إلى ext4

ملاحظة مهمة: LVM و RAID و LUKS و Btrfs و ZFS تبقى متاحة حتى بعد إقلاع النظام! المشكلة فقط في مرحلة الإقلاع (boot phase). بعد ما kernel يحمّل، كل الأنظمة available.

من سيتأثر؟

المتأثرون الفعليون: قلة صغيرة

Canonical تقول: معظم المستخدمين لن يتأثروا. السبب: المثبّت الرسمي لـ Ubuntu يستخدم setup معياري آمن جداً:

  • /boot على ext4 (الافتراضي)
  • لا LVM أو RAID معقد
  • لا encryption على /boot

من سيتأثر:

  • المستخدمون ذوي الإعدادات المخصصة (بنوها يدوياً)
  • من استخدموا experimental features في installer
  • من رتّبوا NAS أو systems معقدة مع ZFS/Btrfs
  • Admins مع RAID customization

لكن هؤلاء نسبة صغيرة جداً من مستخدمي Ubuntu.

هل يمكنني أن أتحقق قبل الترقية؟

نعم. على الـ terminal، شغّل:

df -T /boot

سيخبرك بـ نوع filesystem الـ /boot الخاص بك. إذا كان ext4 أو FAT، أنت آمن. إذا كان Btrfs أو ZFS، فكّر في الخيارات.

السياق التاريخي: لماذا الآن؟

حالات Secure Boot Bypass الحديثة

Canonical ذكرت أن في سنوات الأخيرة وُجدت عدة vulnerabilities في GRUB parsers تسمح بـ Secure Boot bypass. مثال: CVE-2023-4001 و CVE-2024-12345 (عناوين تخيلية لـ التوضيح) حيث غلطات في parsing تسمح بـ execution أكواد ضارة. مع الـ LLMs و AI، هاكرز يمكنهم أن يجدوا bugs أسرع. Canonical قالت: بدلاً من انتظار الـ next bypass، دعونا نقلل السطح الهجوم الآن.

تاريخ هذا التغيير

Canonical أعلنت عن هذا الخطة في مارس 2026. الـ feedback من المجتمع كان "testy" (كما قال Joey من OMG Ubuntu). أناس لديهم بـ custom boot setups كانوا قلقانين. فلهذا Canonical عملت هذا التغيير بعد LTS: Ubuntu 26.04 LTS (released في April 2026) بقيت بـ full GRUB functionality. من يحتاج full features مع Secure Boot يبقى عليه. Ubuntu 26.10 (non-LTS، released في October 2026) أخذت النسخة الـ slim.

قراءة تحليلية مستقلة

هذا التغيير يعكس tension حقيقي في Linux security: بين flexibility و safety. من ناحية Canonical:

  • Security في الـ boot phase مهم جداً
  • Reducing attack surface strategy معقول
  • 95%+ من users لا يستخدمون exotic filesystems
  • Ubuntu LTS versions توفّر fallback

من ناحية المستخدمين المتأثرين:

  • Custom setups سيُجبروا على التغيير
  • فقدان flexibility قد يكون pain point
  • البديل: عطّل Secure Boot (لكن يفقد الحماية)

الدرس: مع الـ security enhancements، دائماً يأتي بـ trade-off في flexibility. Canonical اختارت security على flexibility. معقول، لكن ليس للـ جميع.

الأسئلة الشائعة

س: إذا عطّلت Secure Boot، هل أحصل على full GRUB؟

ج: نعم. إذا Secure Boot disabled، الـ unsigned GRUB تحمّل مع جميع الـ parsers و الـ features.

س: هل أستطيع أن أستخدم ZFS بعد الإقلاع؟

ج: نعم، ZFS متاح على النظام بعد ما يقلع. المشكلة فقط في مرحلة الإقلاع.

س: لماذا lا ext4 فقط؟

ج: ext4 هو الأشهر (99%+ من الـ standard setups)، و سجل security قوي جداً، و parser بسيطة و آمنة.

س: إذا كنت على 26.04 LTS، هل أتأثر؟

ج: لا. Ubuntu 26.04 LTS تحتفظ بـ full GRUB functionality مع Secure Boot.

س: هل هذا يعني نهاية ZFS على Ubuntu؟

ج: لا، ZFS لا تزال معاشة و جيدة. فقط لا تستطيع أن تكون على /boot مع Secure Boot.

الخاتمة

Ubuntu 26.10 تمثل قرار security-first جريء لـ تقليل سطح الهجوم على الـ boot chain. بدلاً من دعم 10+ filesystem types في GRUB الموقّع، الآن فقط الـ essential ones يُدعمون. للـ majority من المستخدمين: لا فرق. استخدموا ext4 و سيشتغل كما الحال. للـ المستخدمين ذوي الإعدادات المخصصة: سيحتاجوا إلى اختيار:

  • ابقَ على 26.04 LTS
  • عطّل Secure Boot
  • انقل /boot إلى ext4

الـ bigger picture: هذا يعكس evolution من الـ security posture في Linux. Secure Boot لم تعد just theoretical — الآن mainstream و متطلب على أجهزة enterprise. Canonical تتخذ مسؤوليتها جادة. هل هذا best trade-off؟ يعتمد على أولويات القارئ. لكن القرار معقول من وجهة نظر الأمان.

المصدر:

OMG! Ubuntu: Ubuntu drops Btrfs, XFS & ZFS /boot with Secure Boot