التصحيح المباشر لنواة VPS أم إعادة التشغيل؟

ما الذي يفعله التصحيح المباشر للنواة على VPS

يطبّق التصحيح المباشر للنواة إصلاحات أمنية على نواة جهاز قيد التشغيل، من دون إعادة تشغيل ومن دون قطع الاتصالات. تُحمَّل نسخة مُصلحة من دالة ما كوحدة نواة، وتُعاد توجيه كل استدعاءات الدالة القديمة إلى النسخة الجديدة، بينما يواصل الخادم معالجة حركة الشبكة. تفسّر هذه الآلية ما يفيد فيه التصحيح المباشر وما لا يستطيع تنفيذه.

إنه يكسبك وقتاً. لكنه لا يلغي الحاجة إلى إعادة التشغيل. يظل الخادم الذي طُبّق عليه التصحيح المباشر لمدة ستة أشهر مقلعاً من صورة النواة القديمة الموجودة على القرص، وتظل كل هذه التصحيحات موجودة في الذاكرة فقط.

غالباً ما يُقدَّم التصحيح المباشر على أنه ميزة ضمن خطة مُدارة. أما على خادم غير مُدار، فيمكنك تفعيله بنفسك باستخدام أمرين، ومن المفيد معرفة ذلك قبل أن تدفع مقابل الفرق بين VPS مُدار وVPS غير مُدار.

كيف يعمل تصحيح النواة المباشر؟

تحتوي النواة على مكوّن مدمج للتصحيح المباشر، ويُترجم معها باستخدام CONFIG_LIVEPATCH. تحقّق من وجوده في النواة قيد التشغيل:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

يعني السطر الذي يقرأ CONFIG_LIVEPATCH=y أن النواة قيد التشغيل بُنيت مع وجود هذا المكوّن. من دونه، لا يمكن لأي خدمة تصحيح مباشر أن تنفّذ شيئاً على ذلك الجهاز.

تستخدم عملية إعادة التوجيه نفسها ftrace، وهو متتبّع الدوال في النواة. تُترجم معظم دوال النواة مع تعليمة استدعاء في بداية الدالة تماماً، قبل تعديل الوسائط أو المكدس. يستخدم ftrace موضع الاستدعاء هذا كنقطة ربط. عند تطبيق تصحيح، يسجّل مكوّن التصحيح المباشر معالج ftrace للدالة المستهدفة، ثم يوجّه المعالج التنفيذ إلى الدالة البديلة بدلاً منها. توضّح وثائق النواة ذلك مباشرة: "يحتاج التصحيح المباشر عادةً إلى إعادة توجيه التعليمات البرمجية عند بداية دخول الدالة تماماً، قبل تعديل وسائط الدالة أو المكدس بأي شكل."

تترتب على هذه الجملة نتيجتان، وكلتاهما مهمتان لاحقاً. لا يمكن تصحيح سوى الدالة التي يستطيع ftrace ربطها، ولذلك لا يمكن تصحيح دالة تُرجمت من دون استدعاء الدخول هذا إطلاقاً. كما أن وحدة التصحيح هي الدالة كاملة، وليست سطراً واحداً داخلها.

الجزء الأصعب هو تبديل نظام قيد التشغيل بأمان. إذا كان الكود القديم لا يزال قيد التنفيذ على مكدس إحدى وحدات المعالجة المركزية عند تبديل الدالة، فستحصل على مزيج من السلوك القديم والجديد. تتعامل Linux upstream مع ذلك باستخدام نموذج اتساق لكل مهمة، وتصفه وثائق النواة بأنه نموذج هجين: "يستخدم اتساق kGraft لكل مهمة وتبديل حاجز استدعاءات النظام، مع تبديل تتبّع المكدس في kpatch." تنتقل المهام إلى الكود الجديد واحدة تلو الأخرى، وفقط عندما تستطيع النواة إثبات أن المهمة لا تنفّذ حالياً داخل دالة مصححة. ويظل التصحيح قيد الانتقال إلى أن تنتقل جميع المهام.

يمكنك رؤية النتيجة بنفسك. تظهر التصحيحات المطبقة ضمن /sys/kernel/livepatch، مع دليل لكل تصحيح، وتظهر الدوال المصححة داخله.

ls /sys/kernel/livepatch/

تعني القائمة الفارغة عدم تحميل أي تصحيح مباشر في الذاكرة. وهذا هو الوضع الابتدائي الطبيعي على خادم جديد.

ما لا يمكن لتصحيح النواة الحي إصلاحه

تُصحَّح أجسام الدوال. أما كل شيء آخر فلا يُصحَّح.

• هياكل البيانات المتغيّرة. إذا أضاف الإصلاح upstream حقلاً إلى struct أو غيّر معنى حقل موجود، فلا توجد طريقة آمنة لإعادة كتابة الكائنات المخصّصة والمستخدمة حالياً. يذكر مشروع kpatch الحالة المكافئة صراحةً: "لا يدعم مباشرةً التصحيحات التي تعدّل البيانات المخصّصة بشكل ثابت." توجد shadow variables وcallbacks كحل بديل، لكنها تُكتب يدوياً لكل تصحيح وليست تلقائية.
• الإصلاحات الموزعة على عدة دوال في الوقت نفسه. يحتاج الإصلاح الذي يغيّر ترتيب الأقفال عبر مجموعة من الدوال إلى تغييرها كلها معاً. كما أن نموذج الاتساق يبدّل المهام بدلاً من تجميد الجهاز بأكمله في لحظة واحدة.
• كود التهيئة. تكون الدوال الموسومة بـ __init قد نُفّذت وحُرّرت عند بدء تشغيل خادمك، لذلك لا يبقى شيء لإعادة توجيهه.
• إصدارات النواة الجديدة والميزات الجديدة. ينقلك التصحيح الحي بين مستويات التصحيح داخل سلسلة نواة واحدة. لكنه لا ينقلك أبداً من سلسلة إلى أخرى، ولا يضيف أي ميزة. إذا أردت ميزة من سلسلة أحدث، مثل التغييرات التي أُدخلت في Linux 7.1، فثبّت تلك النواة وشغّلها عند الإقلاع.
• فضاء المستخدم. توضّح Canonical الحد الفاصل نفسه: "لا يصحّح Canonical Livepatch مكتبات فضاء المستخدم مثل OpenSSL أو glibc، لأن ذلك من مسؤولية unattended-upgrades أو أداة لإدارة الأنظمة." وجود نواة مصحّحة حيّاً بجانب OpenSSL قديم لا يعني أن الخادم مصحّح، لذلك اترك unattended upgrades يتولى حزم فضاء المستخدم على الجهاز نفسه.

يوجد أيضاً حدّ متعلق بدرجة الخطورة في خدمة Ubuntu. تقول Canonical إن الخدمة "تُصحّح ثغرات النواة المصنّفة بدرجات حرجة وعالية وفق نظام Common Vulnerability Scoring System (CVSS) وتصنيفات الأولوية في Ubuntu." يعرّف معرّف CVE (common vulnerabilities and exposures) ثغرة واحدة، بينما يمثّل CVSS الدرجة المرتبطة بها. تُصلح ثغرة CVE في النواة ذات التصنيف المتوسط داخل الحزمة الموجودة على القرص، ولا تُصحّح حيّاً. لذلك تصل إلى النواة قيد التشغيل عند إعادة التشغيل التالية، وليس قبل ذلك.

ما خيارات تحديث النواة مباشرة؟

توجد ثلاث سلاسل شائعة الاستخدام، وجميعها تعتمد على آلية النواة نفسها.

Canonical Livepatch متاح عبر Ubuntu Pro. خدمة Ubuntu Pro مجانية للاستخدام الشخصي، وتذكر Canonical أنها «مجانية للاستخدام الشخصي، وستظل كذلك دائماً، على ما يصل إلى 5 أجهزة فعلية»، ويرتفع الحد إلى 50 جهازاً لأعضاء Ubuntu Community الرسميين. هذا هو الحد الموثق حتى August 2026. يتطلب الاستخدام التجاري اشتراكاً مدفوعاً. تُمنح التغطية لكل سلسلة نواة ولكل نكهة، وتشمل نوى التوافر العام (GA) لإصدارات الدعم طويل الأمد (LTS) المدعومة، بالإضافة إلى نوى تمكين العتاد (HWE) الخاصة بها، ضمن نكهات مثل generic وaws وazure وgcp وoracle وibm وlowlatency. طابق نواتك مع قائمة النوى المنشورة من Canonical قبل الاعتماد على هذه التغطية.

KernelCare، من TuxCare، هو وكيل تجاري يدعم العديد من التوزيعات، بما فيها التوزيعات التي لا توفر لها الجهة الأصلية خدمة مماثلة. يتكون التثبيت الموثق من سكربت المورّد، curl -s -L https://kernelcare.com/installer | bash، ثم /usr/bin/kcarectl --register KEY للحصول على ترخيص يعتمد على مفتاح. يفحص الوكيل بعد ذلك وجود تصحيحات جديدة وفق جدوله الخاص، ويجبر /usr/bin/kcarectl --update الوكيل على إجراء فحص. اقرأ المثبّت قبل تمريره إلى shell على خادم مهم.

kpatch وkGraft هما الأساس التاريخي لهذه التقنية. جاء kGraft من SUSE، وجاء kpatch من Red Hat، أما جوهر التحديث المباشر في Linux الحالي فيجمع بين الفكرتين. يتراجع استخدام kpatch نفسه تدريجياً؛ إذ يذكر ملف README الخاص به أنه ابتداءً من Linux 6.19 «أصبح مشروع kpatch مهملاً ووضعه هو وضع الصيانة»، مع استبدال kpatch-build بـ klp-build في نواة upstream. في RHEL وإصداراته المعاد بناؤها، استخدم خدمة التوزيعة نفسها بدلاً من إنشاء التصحيحات يدوياً.

اختر بناءً على ما يدعمه توزيعك وما يسمح به ترخيصك. النتيجة على مستوى النواة واحدة في جميع الحالات.

كيفية تفعيل Canonical Livepatch على Ubuntu

احصل أولاً على token من صفحة حساب Ubuntu Pro. يحتاج كلا الأمرين أدناه إلى اتصال صادر يعمل بالشبكة، لأن العميل يتصل بخوادم Canonical لربط النظام وجلب التصحيحات.

sudo pro attach TOKEN
sudo pro status

يؤدي تشغيل sudo pro attach من دون token إلى بدء عملية عبر المتصفح بدلاً من ذلك، ويطبع code لإدخاله في موقع Canonical. يؤدي الربط إلى تفعيل الخدمات الموصى بها تلقائياً، وتشمل Livepatch في إصدار LTS حديث. استخدم sudo pro attach --no-auto-enable إذا كنت تفضل اختيار الخدمات بنفسك.

إذا لم يكن Livepatch مفعّلاً:

sudo pro enable livepatch
sudo canonical-livepatch status

تعمل الخدمة من snap canonical-livepatch، لذلك يجب أن يعمل snapd حتى تكتمل عملية التفعيل. يطبع pro status جدولاً بالخدمات يتضمن entitlement وحالتها. يطبع canonical-livepatch status التفاصيل الخاصة بكل kernel، وتعرض وثائق Canonical مخرجات بهذا الشكل:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

يوجد سطران يقدمان الإجابة. يوضح kernel state ما إذا كانت سلسلة kernel التي تشغّلها مشمولة بالخدمة أصلاً، وهو السطر الذي تتغير حالته إلى الخطأ عند إقلاع kernel لا يدعمه Livepatch. يوضح patch state ما إذا كانت التصحيحات المنطبقة على ذلك kernel قد حُمّلت فعلياً. يكون kernel المشمول من دون تصحيحات مطبقة مشكلة في العميل. أما kernel غير المشمول فمشكلته في kernel، ولا يمكن لأي إعداد في العميل إصلاحها.

كيف أعرف أن إعادة التشغيل معلّقة؟

تلغي live patching الحاجة إلى الإجراء الطارئ، لذلك لا يعود وجود إعادة تشغيل معلّقة واضحاً. يجب أن تبحث عنها.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

ينشئ مدير الحزم /var/run/reboot-required عندما يحتاج أحد الحزم المثبّتة إلى إعادة تشغيل لتطبيق التغيير، كما أن تثبيت حزمة linux-image جديدة ينشئه دائماً. يسرد الملف .pkgs الحزم التي طلبت ذلك. إذا أعاد الأمر الأول القيمة No such file or directory، فهذا يعني أن أياً من الحزم لم يطلب إعادة تشغيل منذ آخر إقلاع للجهاز. في Ubuntu الحالي، يكون /var/run رابطاً رمزياً إلى /run، لذلك يشير كلا المسارين إلى الملف نفسه.

يوجد هذا المؤشر في tmpfs، ويُعاد ضبطه عند كل إقلاع. لذلك تحقّق منه مقابل النواة نفسها:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

يطبع uname -r النواة التي تعمل حالياً. ويطبع الأمر الثاني حزم النواة المثبّتة على القرص. إذا كانت هناك حزمة linux-image في تلك القائمة أحدث من الإصدار الذي يعرضه uname -r، فهذا يعني أن الجهاز يعمل بنواة قديمة، بغض النظر عما تعرضه حالة Livepatch. هذا هو الفحص المهم، لأن live patching مصمم لجعل النواة العاملة آمنة، لا لجعلها الأحدث.

أما الجزء الخاص بفضاء المستخدم من السؤال نفسه، فإن needrestart يكون مثبتاً افتراضياً على Ubuntu Server، ويسرد الخدمات العاملة التي ما زالت تحتفظ بملفات مكتبات محذوفة.

sudo needrestart -r l

تعني مجموعة الرايتين -r l «السرد فقط»، لذلك يعرض الأمر النتائج ولا يغيّر شيئاً.

لماذا لا تختفي الحاجة إلى إعادة التشغيل

لم تتغير نواة النظام الموجودة على القرص. تُحمَّل التصحيحات الحية إلى النواة قيد التشغيل، ولا تُكتب مطلقاً في صورة الإقلاع. لذلك، تعيدك إعادة التشغيل إلى أي linux-image يختاره محمّل الإقلاع، ثم يعيد عميل Livepatch تطبيق التصحيحات التي ما زالت سارية. وبين هاتين اللحظتين، تعمل بشيفرة غير مصححة. وهذا سبب إضافي للإقلاع باستخدام نواة حديثة بدلاً من نواة قديمة.

يُحدَّد نطاق التغطية لكل سلسلة من سلاسل النواة، وتُحال السلاسل إلى التقاعد. عندما تخرج السلسلة قيد التشغيل من قائمة السلاسل المدعومة، يتوقف سطر kernel state عن الإبلاغ عن التغطية. ويكون الحل الوحيد هو استخدام نواة أحدث. وهذا يعني إعادة التشغيل. في إصدار LTS، تصلك السلسلة الأحدث عادةً كنواة لتمكين الأجهزة مضمّنة في إصدار نقطي مثل 26.04.1، لذلك تكون النواة البديلة موجودة بالفعل في المستودع، وكل ما ينقصك هو إقلاع تحدد موعده.

لا تُطبَّق إصلاحات النواة ذات الخطورة المتوسطة والمنخفضة مباشرةً. تبقى هذه الإصلاحات في الحزمة الموجودة على القرص، ولا تصل إليك إلا عند الإقلاع.

تتراكم أيضاً حالة في النوى التي تعمل فترات طويلة، ولا يعالجها التصحيح. ويستحق موقف Canonical نفسه الاقتباس لأنه صريح: Livepatch «ليس بديلاً عن إعادة التشغيل. إنه أداة تمنحك تحكماً أكبر من خلال منع عمليات إعادة التشغيل غير المجدولة». والكلمة التي تحمل المعنى هنا هي غير المجدولة. ستظل بحاجة إلى إعادة التشغيل. لكنك تختار موعدها.

كيفية جدولة إعادة تشغيل يعود بعدها الخادم للعمل

تكون إعادة تشغيل VPS إجراءً أحادي الاتجاه إذا تعذّر عليك الوصول إلى وحدة التحكم. قبل كتابة reboot، تأكد من قدرتك على الدخول مجدداً إذا لم يعد الجهاز للعمل.

• تأكد من أن موفّر الخدمة يتيح لك وحدة تحكم تسلسلية أو عرض VNC (الحوسبة الافتراضية عبر الشبكة) في لوحة التحكم، وافتحها الآن بدلاً من الانتظار حتى حدوث العطل.
• تحقّق من المساحة الخالية باستخدام df -h /boot. يؤدي امتلاء /boot إلى فشل حزمة kernel أثناء كتابة initramfs (نظام الملفات الأولي في الذاكرة)، وقد يترك ذلك إدخالاً في محمّل الإقلاع يشير إلى صورة لم يكتمل إنشاؤها.
• أبقِ على الأقل إصداراً أقدم معروفاً بسلامته من kernel مثبتاً. يعرضه GRUB ضمن "Advanced options for Ubuntu"، ويُعد تشغيله أسرع طريقة للاسترداد عند فشل إصدار kernel جديد.
• اعرف وضع الإنقاذ لدى موفّر الخدمة قبل أن تحتاج إليه. إذا عرضت وحدة التحكم مطالبة initramfs بعد إعادة التشغيل، فهناك تُجرى عملية الإصلاح.

بعد ذلك، أعد التشغيل في وقت تكون فيه مستيقظاً:

sudo shutdown -r +5 "Kernel update, back in a moment"

يجدول ذلك إعادة التشغيل بعد خمس دقائق ويرسل رسالة إلى المستخدمين المسجّلين للدخول. يلغي sudo shutdown -c العملية. عند عودة الجهاز للعمل، تحقّق من الجزأين معاً:

uname -r
sudo canonical-livepatch status

يجب أن يعرض uname -r الآن إصدار kernel الأحدث، ويجب أن يشير خرج الحالة إلى أن السلسلة الجديدة مشمولة. إذا لم يعد الجهاز للعمل إطلاقاً، فغالباً ما يكون الخلل في مسار الإقلاع لا في الشبكة، ويكون مسار الاسترداد هو الوارد في الدليل الخاص بـVPS الذي لا يقلع بعد تحديث kernel.

لماذا يجب تنظيف kernels القديمة

تجعل live patching هذه المشكلة أسوأ بدلاً من حلّها، لأنها تلغي الحاجة إلى إعادة التشغيل بينما تستمر حزم linux-image في التثبيت. يثبّت كل kernel صورة إقلاع، وinitramfs، وشجرة modules، وعادةً حزمة headers. على VPS صغير يحتوي على قسم /boot منفصل بسعة بضع مئات من megabytes، تملأ هذه الملفات مساحة القسم بعد تثبيت ثلاثة أو أربعة kernels.

يؤدي امتلاء /boot إلى فشل تثبيت kernel التالي. وهكذا يصبح الجهاز غير قادر على تثبيت التحديث الذي يحتاج إليه فعلياً. يزيل مسار apt autoremove kernels القديمة بعد أن تصبح مؤهلة للإزالة، لكن kernels القديمة لا تكون مؤهلة دائماً على جهاز لا يُعاد تشغيله مطلقاً، لأن مدير الحزم لن يزيل kernel قد تكون قيد تشغيله.

لذلك تحقّق من kernels المثبتة، واحتفظ بالـkernel قيد التشغيل وبنسخة احتياطية واحدة معروفة بسلامتها، ثم أزل البقية باستخدام الإجراء الآمن لإزالة kernels القديمة على Ubuntu. لا تزل مطلقاً الـkernel الذي يعرضه uname -r حالياً.

FAQ

هل يعني تصحيح النواة مباشرةً أنني لن أضطر أبداً إلى إعادة تشغيل VPS؟

لا. تُحمَّل التصحيحات المباشرة إلى النواة قيد التشغيل ولا تُكتب في صورة الإقلاع، لذلك يبقى linux-image الموجود على القرص عند الإصدار الذي أقلعت به. تذكر Canonical ذلك صراحةً: إن Livepatch «ليس بديلاً عن إعادة التشغيل. بل هو أداة تمنحك مزيداً من التحكم عبر منع عمليات إعادة التشغيل غير المجدولة». تنتهي التغطية أيضاً عند إحالة سلسلة النواة إلى التقاعد، كما أن إصلاحات النواة ذات الخطورة المتوسطة لا تُطبَّق مباشرةً مطلقاً. حدّد إعادة تشغيل للصيانة وفق جدول تختاره، بدلاً من انتظار فرض إعادة تشغيل عليك.

كيف أتحقق من أن تصحيح النواة مباشرةً يطبّق التصحيحات فعلاً؟

شغّل sudo canonical-livepatch status واقرأ السطرين. يوضّح kernel state ما إذا كانت سلسلة النواة قيد التشغيل مشمولة بالخدمة، ويوضّح patch state ما إذا كانت تصحيحات تلك النواة محمّلة. يمكنك أيضاً التحقق مباشرةً من جانب النواة باستخدام ls /sys/kernel/livepatch/، الذي يعرض دليلاً واحداً لكل تصحيح محمّل. تعني القائمة الفارغة أنه لا توجد تصحيحات مطبّقة في الذاكرة حالياً، بصرف النظر عما يقوله العميل.

هل Ubuntu Pro مجاني على VPS شخصي؟

نعم، ضمن حد موثّق. تنص صياغة Canonical على أن Ubuntu Pro «مجاني وسيظل مجانياً للاستخدام الشخصي على ما يصل إلى 5 أجهزة فعلية»، ويرتفع الحد إلى 50 جهازاً لأعضاء Ubuntu Community الرسميين، وذلك اعتباراً من August 2026. يتطلب الاستخدام التجاري اشتراكاً مدفوعاً. تربط جهازاً باستخدام sudo pro attach TOKEN ورمز مميز من صفحة حسابك في Ubuntu Pro، ثم تفعّل الخدمة باستخدام sudo pro enable livepatch.

لماذا تظل ثغرة CVE في النواة مدرجة على أنها غير مُصلحة بعد تشغيل Livepatch؟

عادةً يعود ذلك إلى أحد سببين. قد يكون الإصلاح دون حد الخطورة، لأن Canonical تطبّق مباشرةً «ثغرات النواة ذات التصنيفات الحرجة والعالية وفق Common Vulnerability Scoring System (CVSS) وUbuntu Priority»، وتترك بقية الإصلاحات للحزمة الموجودة على القرص. وقد لا يكون من الممكن التعبير عن الإصلاح كتغيير في جسم دالة، مثلاً عندما يغيّر المشروع المصدر بنية بيانات، وهو ما لا يستطيع التصحيح المباشر تنفيذه بأمان على الكائنات التي خُصّصت لها الذاكرة مسبقاً. تُحل الحالتان بالطريقة نفسها: ثبّت حزمة النواة المحدّثة وأقلع إليها.

ما الذي لا يغطيه تصحيح النواة مباشرةً إطلاقاً؟

مساحة المستخدم. توضح Canonical صراحةً أن Livepatch «لا يصحّح مكتبات مساحة المستخدم مثل OpenSSL أو glibc، لأن ذلك من مسؤولية unattended-upgrades أو أداة لإدارة الأنظمة». ولا يستطيع أيضاً توفير إصدار جديد من النواة أو ميزة جديدة، لأنه يستبدل أجسام الدوال داخل السلسلة التي تشغّلها حالياً فقط. كما لا يستطيع تصحيح دوال __init التي تكون قد نُفّذت وأُزيلت من الذاكرة بحلول وقت تشغيل الخادم.