وصله کردن زنده هسته لینوکس یا ریبوت VPS؟

وصله کردن زنده هسته (Live kernel patching) روی یک VPS چه کاری انجام می‌دهد

وصله کردن زنده هسته، اصلاحات امنیتی هسته را بدون نیاز به reboot و بدون قطع شدن اتصالات، روی ماشین در حال اجرا اعمال می‌کند. یک نسخه اصلاح‌شده از تابع به عنوان یک ماژول هسته بارگذاری می‌شود و هر فراخوانی به تابع قدیمی به نسخه جدید هدایت می‌گردد، در حالی که سرور همچنان به ترافیک پاسخ می‌دهد. همین مکانیزم، هم نقاط قوت وصله کردن زنده و هم محدودیت‌های آن را توضیح می‌دهد.

این روش زمان می‌خرد، اما جایگزین reboot نمی‌شود. سروری که شش ماه به صورت زنده وصله شده است، همچنان با همان image هسته قدیمی موجود روی دیسک بوت شده است و تمام این وصله‌ها فقط در حافظه (RAM) قرار دارند.

وصله کردن زنده اغلب به عنوان قابلیتی در پلن‌های مدیریت‌شده (managed) فروخته می‌شود. در یک سرور مدیریت‌نشده (unmanaged)، شما خودتان با دو دستور آن را فعال می‌کنید؛ دانستن این موضوع پیش از پرداخت هزینه برای تفاوت بین یک VPS مدیریت‌شده و مدیریت‌نشده ارزشمند است.

وصله کردن زنده (live patching) هسته چگونه کار می‌کند؟

هسته لینوکس دارای یک هسته (core) داخلی برای وصله کردن زنده است که با CONFIG_LIVEPATCH کامپایل می‌شود. وضعیت هسته در حال اجرای خود را برای این قابلیت بررسی کنید:

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

وجود خطی که CONFIG_LIVEPATCH=y را نشان می‌دهد به این معنی است که هسته در حال اجرا با این قابلیت کامپایل شده است. بدون آن، هیچ سرویس وصله کردن زنده‌ای نمی‌تواند روی آن ماشین کاری انجام دهد.

خودِ تغییر مسیر (redirection) از ftrace، یعنی ردیاب توابع هسته، استفاده می‌کند. اکثر توابع هسته با یک دستور call در ابتدای تابع کامپایل می‌شوند، یعنی پیش از آنکه آرگومان‌ها یا پشته (stack) دستکاری شوند. Ftrace از آن نقطه فراخوانی به عنوان یک قلاب (hook) استفاده می‌کند. هنگامی که یک وصله اعمال می‌شود، هسته وصله کردن زنده، یک هندلر ftrace را روی تابع هدف ثبت می‌کند و آن هندلر، اجرای برنامه را به جای تابع اصلی، به تابع جایگزین هدایت می‌کند. مستندات هسته این موضوع را به سادگی بیان می‌کند: «وصله کردن زنده معمولاً نیاز دارد که کد را در همان ابتدای ورود به تابع، پیش از آنکه پارامترهای تابع یا پشته به هر شکلی تغییر کنند، تغییر مسیر دهد.»

دو نتیجه از این جمله حاصل می‌شود که هر دو بعداً اهمیت پیدا می‌کنند. تنها تابعی که ftrace بتواند به آن قلاب بزند قابل وصله کردن است؛ بنابراین تابعی که بدون آن دستور فراخوانی ورودی کامپایل شده باشد، به هیچ وجه قابل وصله کردن نیست. همچنین، واحد وصله کردن، یک تابع کامل است و هرگز نمی‌توان تنها یک خط را در داخل یک تابع وصله کرد.

بخش دشوارتر، تغییر ایمن یک سیستم در حال اجرا است. اگر هنگام تعویض تابع، کد قدیمی هنوز روی پشته برخی از CPUها در حال اجرا باشد، ترکیبی از رفتار قدیمی و جدید ایجاد می‌شود. هسته اصلی لینوکس این موضوع را با یک مدل سازگاریِ «هر-وظیفه» (per-task) مدیریت می‌کند که در مستندات هسته به عنوان یک مدل ترکیبی توصیف شده است: «این مدل از سازگاریِ هر-وظیفه در kGraft و تعویض از طریق سدِ فراخوانی سیستم (syscall barrier) در ترکیب با تعویضِ ردپای پشته (stack trace) در kpatch استفاده می‌کند.» وظایف (tasks) یکی‌یکی به کد جدید منتقل می‌شوند، آن هم تنها زمانی که هسته بتواند اثبات کند که آن وظیفه در حال حاضر داخل یک تابع وصله‌شده نیست. تا زمانی که تمام وظایف منتقل نشوند، وصله در وضعیت انتقال (transition) باقی می‌ماند.

شما می‌توانید نتیجه را شخصاً مشاهده کنید. وصله‌های اعمال‌شده در مسیر /sys/kernel/livepatch ظاهر می‌شوند؛ برای هر وصله یک دایرکتوری وجود دارد و توابع وصله‌شده در داخل آن فهرست شده‌اند.

ls /sys/kernel/livepatch/

یک فهرست خالی به این معنی است که هیچ وصله زنده‌ای در حافظه بارگذاری نشده است، که این وضعیت در یک سرور تازه، حالت شروع عادی محسوب می‌شود.

مواردی که با live kernel patching قابل رفع نیستند

بدنهٔ توابع اصلاح می‌شوند، اما سایر موارد خیر.

• تغییر در ساختار داده‌ها. اگر اصلاحیهٔ ارائه‌شده توسط توسعه‌دهنده، فیلدی به یک struct اضافه کند یا معنای فیلد موجودی را تغییر دهد، راه امنی برای بازنویسی اشیاء (objects) که از قبل تخصیص یافته و در حال استفاده هستند وجود ندارد. پروژهٔ kpatch مستقیماً به این مورد اشاره می‌کند: «وصله‌هایی که داده‌های تخصیص‌یافته به صورت ایستا (statically allocated) را تغییر می‌دهند، مستقیماً پشتیبانی نمی‌شوند.» متغیرهای سایه (shadow variables) و callbackها به عنوان راهکار وجود دارند، اما آن‌ها برای هر وصله به‌صورت دستی نوشته می‌شوند و خودکار نیستند.
• اصلاحاتی که همزمان چندین تابع را درگیر می‌کنند. اصلاحیه‌ای که ترتیب قفل‌گذاری (lock ordering) را در گروهی از توابع تغییر می‌دهد، نیازمند تغییر همزمان همهٔ آن‌هاست؛ در حالی که مدل سازگاری (consistency model) به‌جای متوقف کردن کل سیستم در یک لحظه، وظایف (tasks) را سوئیچ می‌کند.
• کد مقداردهی اولیه (Initialisation code). توابعی که با __init مشخص شده‌اند، تا زمانی که سرور شما بالا می‌آید اجرا شده و حافظهٔ آن‌ها آزاد شده است، بنابراین چیزی برای تغییر مسیر (redirect) باقی نمانده است.
• نسخه‌های جدید هسته و قابلیت‌های جدید. Live patching شما را در یک سری از هسته، بین سطوح مختلف وصله جابه‌جا می‌کند. این قابلیت هرگز شما را از یک سری به سری بعد نمی‌برد و هیچ ویژگی جدیدی اضافه نمی‌کند. اگر به چیزی از سری‌های جدیدتر نیاز دارید، مانند تغییراتی که در Linux 7.1 اعمال شده است، باید آن هسته را نصب کرده و سیستم را با آن بوت کنید.
• فضای کاربری (Userspace). شرکت Canonical مرز این قابلیت را این‌گونه بیان می‌کند: «Canonical Livepatch کتابخانه‌های فضای کاربری مانند OpenSSL یا glibc را وصله نمی‌کند، زیرا این وظیفهٔ unattended-upgrades یا یک ابزار مدیریت سیستم است.» یک هستهٔ وصله‌شده به‌صورت زنده در کنار یک OpenSSL قدیمی، به معنای یک سرور وصله‌شده نیست؛ بنابراین مدیریت بسته‌های فضای کاربری توسط unattended upgrades را در همان سیستم فعال نگه دارید.

همچنین یک مرز برای سطح اهمیت (severity) در سرویس Ubuntu وجود دارد. Canonical اعلام کرده است که «آسیب‌پذیری‌های هسته با رتبهٔ بحرانی (critical) و بالا (high) در سیستم امتیازدهی آسیب‌پذیری‌های رایج (CVSS) و رتبه‌بندی اولویت Ubuntu را وصله می‌کند.» شناسهٔ CVE (آسیب‌پذیری‌ها و مواجهه‌های رایج) یک نقص را نام‌گذاری می‌کند و CVSS امتیازی است که به آن اختصاص می‌یابد. یک CVE با رتبهٔ متوسط در هسته، در بستهٔ موجود روی دیسک اصلاح می‌شود و به‌صورت زنده وصله نمی‌شود؛ بنابراین این اصلاحیه در بوت بعدی و نه پیش از آن، به هستهٔ در حال اجرای شما اعمال خواهد شد.

گزینه‌های وصله زنده (live patching) هسته چیست؟

سه خانواده اصلی در استفاده رایج هستند و همگی از مکانیزم هسته یکسانی بهره می‌برند.

Canonical Livepatch از طریق Ubuntu Pro ارائه می‌شود. Ubuntu Pro برای استفاده شخصی رایگان است و طبق اعلام Canonical، این سرویس «برای استفاده شخصی روی حداکثر 5 دستگاه فیزیکی، همیشه رایگان باقی می‌ماند» و این سقف برای اعضای رسمی جامعه کاربری Ubuntu به 50 دستگاه افزایش می‌یابد. این محدودیت مستندشده تا اوت 2026 است. استفاده تجاری نیازمند اشتراک پولی است. پوشش این سرویس بر اساس سری و نوع هسته (flavour) ارائه می‌شود و هسته‌های general availability (GA) در نسخه‌های long term support (LTS) و همچنین هسته‌های hardware enablement (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 در سروری که برایتان اهمیت دارد pipe کنید، محتوای آن را مطالعه کنید.

kpatch و kGraft پیشینیان این فناوری هستند. kGraft از SUSE و kpatch از Red Hat آمدند و هسته وصله زنده در نسخه upstream لینوکس امروزی، ترکیبی از ایده‌های هر دو است. پروژه kpatch در حال پایان است: فایل README آن بیان می‌کند که از لینوکس 6.19 به بعد، «پروژه kpatch منسوخ شده و در حالت نگهداری قرار دارد» و kpatch-build با klp-build در هسته upstream جایگزین شده است. در RHEL و توزیع‌های مبتنی بر آن، ابزاری که باید استفاده کنید سرویس اختصاصی همان توزیع است، نه ساخت دستی وصله‌ها.

انتخاب خود را بر اساس آنچه توزیع شما پشتیبانی می‌کند و لایسنس شما اجازه می‌دهد، انجام دهید. نتیجه در سطح هسته در هر سه مورد یکسان است.

نحوه فعال‌سازی Canonical Livepatch در اوبونتو

ابتدا یک توکن از صفحه حساب کاربری Ubuntu Pro خود دریافت کنید. هر دو دستور زیر به دسترسی شبکه خروجی نیاز دارند، زیرا کلاینت برای متصل شدن و دریافت وصله‌ها با سرورهای Canonical ارتباط برقرار می‌کند.

sudo pro attach TOKEN
sudo pro status

اجرای sudo pro attach بدون توکن، یک فرآیند مبتنی بر مرورگر را آغاز می‌کند و کدی را برای وارد کردن در سایت Canonical نمایش می‌دهد. اتصال، به‌طور خودکار سرویس‌های توصیه‌شده را فعال می‌کند که در نسخه‌های LTS فعلی شامل Livepatch نیز می‌شود. اگر ترجیح می‌دهید سرویس‌ها را خودتان انتخاب کنید، از sudo pro attach --no-auto-enable استفاده نمایید.

اگر Livepatch هنوز فعال نیست:

sudo pro enable livepatch
sudo canonical-livepatch status

این سرویس از طریق اسنپ canonical-livepatch اجرا می‌شود، بنابراین برای تکمیل مرحله فعال‌سازی، snapd باید به‌درستی کار کند. دستور pro status جدولی از سرویس‌ها را به همراه وضعیت و حق اشتراک آن‌ها نمایش می‌دهد. دستور 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 مشخص می‌کند که آیا سری هسته‌ای که در حال اجرای آن هستید توسط این سرویس پشتیبانی می‌شود یا خیر؛ این همان خطی است که در صورت بوت کردن هسته‌ای که Livepatch از آن پشتیبانی نمی‌کند، وضعیت آن تغییر می‌کند. patch state نشان می‌دهد که آیا وصله‌های مربوط به آن هسته واقعاً بارگذاری شده‌اند یا خیر. هسته‌ای که تحت پوشش است اما وصله‌ای روی آن اعمال نشده، یک مشکل کلاینتی است. هسته‌ای که تحت پوشش نیست، یک مشکل مربوط به هسته است و هیچ تنظیماتی در کلاینت آن را برطرف نمی‌کند.

چگونه متوجه شوم که سیستم نیاز به reboot دارد؟

Live patching وضعیت اضطراری را برطرف می‌کند، بنابراین نیاز به reboot دیگر به سادگی قابل تشخیص نیست. باید آن را بررسی کنید.

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

مدیر بسته (package manager) در صورت نیاز به راه‌اندازی مجدد برای اعمال تغییرات یک بسته نصب‌شده، فایل /var/run/reboot-required را ایجاد می‌کند و نصب هر بسته linux-image جدید نیز همیشه باعث ایجاد آن می‌شود. فایل .pkgs مشخص می‌کند کدام بسته‌ها این درخواست را داشته‌اند. اگر دستور اول خروجی No such file or directory را برگرداند، یعنی از زمان آخرین بوت سیستم، هیچ درخواستی برای reboot ثبت نشده است. در نسخه‌های فعلی Ubuntu، فایل /var/run یک symlink به /run است، بنابراین هر دو مسیر به یک فایل واحد اشاره دارند.

این پرچم در یک tmpfs قرار دارد و با هر بار بوت بازنشانی می‌شود، بنابراین آن را با وضعیت خودِ kernel تطبیق دهید:

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

دستور uname -r نسخه kernel در حال اجرا را نمایش می‌دهد. دستور دوم بسته‌های kernel نصب‌شده روی دیسک را فهرست می‌کند. وجود یک linux-image در آن لیست که جدیدتر از خروجی uname -r باشد، به این معناست که سیستم در حال اجرای یک kernel قدیمی است؛ فارغ از اینکه وضعیت Livepatch چه چیزی را نشان می‌دهد. این بررسی اصلی است، زیرا live patching برای ایمن‌سازی kernel در حال اجرا طراحی شده است، نه برای به‌روز نگه داشتن نسخه آن.

برای بخش userspace همین پرسش، ابزار needrestart به‌صورت پیش‌فرض در Ubuntu Server نصب است و سرویس‌های در حال اجرایی را فهرست می‌کند که هنوز از فایل‌های کتابخانه‌ای حذف‌شده استفاده می‌کنند.

sudo needrestart -r l

جفت پرچم -r l به معنای "فقط فهرست کن" (list only) است، بنابراین هیچ تغییری ایجاد نمی‌کند و فقط گزارش می‌دهد.

چرا نیاز به reboot هرگز از بین نمی‌رود

هسته (kernel) موجود روی دیسک تغییر نمی‌کند. وصله‌های زنده (Live patches) در هستهٔ در حال اجرا بارگذاری می‌شوند و هرگز در image بوت نوشته نمی‌شوند؛ بنابراین با انجام reboot، سیستم با همان linux-image که bootloader انتخاب می‌کند بالا می‌آید و سپس کلاینت Livepatch وصله‌هایی را که همچنان معتبر هستند، مجدداً اعمال می‌کند. در فاصلهٔ بین این دو لحظه، شما در حال اجرای کدی هستید که وصله نشده است؛ این خود دلیلی دیگر برای بوت کردن یک هستهٔ به‌روز به‌جای یک هستهٔ قدیمی است.

پوشش‌دهی وصله‌ها بر اساس سری‌های هسته است و این سری‌ها پس از مدتی بازنشسته می‌شوند. هنگامی که سریِ در حال اجرای شما از لیست پشتیبانی خارج شود، خط kernel state دیگر گزارشی از پوشش‌دهی ارائه نمی‌دهد و تنها راه حل، استفاده از یک هستهٔ جدیدتر است. این یعنی یک reboot.

اصلاحات هسته با درجه اهمیت متوسط و پایین هرگز به صورت Live patch ارائه نمی‌شوند. این اصلاحات در بستهٔ نرم‌افزاری روی دیسک باقی می‌مانند و تنها زمانی که سیستم را بوت کنید، اعمال می‌شوند.

هسته‌هایی که برای مدت طولانی اجرا می‌شوند، وضعیتی (state) را انباشته می‌کنند که وصله‌گذاری آن را پاکسازی نمی‌کند. موضع رسمی Canonical در این باره صادقانه و قابل‌نقل است: Livepatch «جایگزینی برای reboot کردن نیست. ابزاری است که با جلوگیری از rebootهای برنامه‌ریزی‌نشده، کنترل بیشتری به شما می‌دهد.» کلمهٔ کلیدی در اینجا «برنامه‌ریزی‌نشده» (unscheduled) است. شما همچنان reboot می‌کنید، اما زمان آن را خودتان انتخاب می‌کنید.

نحوه زمان‌بندی راه‌اندازی مجدد (reboot) با اطمینان از بالا آمدن سیستم

اگر به کنسول دسترسی نداشته باشید، راه‌اندازی مجدد VPS یک مسیر یک‌طرفه است. پیش از تایپ reboot، مطمئن شوید که در صورت عدم بازگشت ماشین، می‌توانید دوباره به آن دسترسی پیدا کنید.

• تأیید کنید که ارائه‌دهنده شما یک کنسول سریال یا نمای VNC (رایانش شبکه مجازی) در پنل کنترل ارائه می‌دهد و آن را همین حالا باز کنید، نه در زمان قطعی.
• فضای آزاد را با df -h /boot بررسی کنید. پر بودن /boot باعث می‌شود بسته kernel هنگام نوشتن initramfs (سیستم فایل RAM اولیه) با خطا مواجه شود؛ این اتفاق می‌تواند باعث شود ورودی bootloader به تصویری اشاره کند که هرگز کامل نشده است.
• حداقل یک kernel قدیمی که از سلامت آن مطمئن هستید را نصب نگه دارید. GRUB آن را در بخش "Advanced options for Ubuntu" فهرست می‌کند و بوت کردن آن سریع‌ترین راه بازیابی در صورت خرابی kernel جدید است.
• پیش از نیاز به حالت rescue ارائه‌دهنده خود، آن را پیدا کنید. اگر کنسول پس از راه‌اندازی مجدد، اعلان initramfs را نشان داد، تعمیرات در آنجا انجام می‌شود.

سپس در زمانی که بیدار هستید، راه‌اندازی مجدد را زمان‌بندی کنید:

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

این دستور راه‌اندازی مجدد را برای 5 دقیقه بعد زمان‌بندی کرده و پیامی برای کاربران واردشده ارسال می‌کند. sudo shutdown -c آن را لغو می‌کند. وقتی ماشین بازگشت، هر دو بخش را تأیید کنید:

uname -r
sudo canonical-livepatch status

uname -r اکنون باید kernel جدیدتر را گزارش دهد و خروجی وضعیت باید سری جدید را به عنوان تحت پوشش گزارش کند. اگر ماشین اصلاً بالا نیامد، خطا تقریباً همیشه در مسیر بوت است نه در شبکه، و مسیر بازیابی همان است که در راهنمای VPS که پس از به‌روزرسانی kernel بوت نمی‌شود آمده است.

چرا هسته‌های قدیمی همچنان نیاز به پاک‌سازی دارند

وصله‌گذاری زنده (Live patching) این مشکل را تشدید می‌کند، زیرا نیاز به راه‌اندازی مجدد (reboot) را از بین می‌برد، در حالی که بسته‌های linux-image همچنان نصب می‌شوند. هر هسته یک image بوت، یک initramfs، یک درخت ماژول و معمولاً یک بسته headers نصب می‌کند. در یک VPS کوچک با پارتیشن /boot جداگانه که تنها چند صد مگابایت ظرفیت دارد، سه یا چهار مورد از این‌ها باعث پر شدن پارتیشن می‌شود.

پر شدن کامل /boot باعث می‌شود نصب هسته بعدی با شکست مواجه شود؛ این همان دلیلی است که باعث می‌شود یک ماشین نتواند به‌روزرسانی‌های ضروری خود را دریافت کند. دستور apt autoremove هسته‌های قدیمی را پس از واجد شرایط شدن پاک می‌کند، اما در ماشینی که هرگز reboot نمی‌شود، این هسته‌ها همیشه واجد شرایط نیستند، زیرا مدیر بسته (package manager) هسته‌ای را که ممکن است در حال حاضر در حال اجرای آن باشید، حذف نمی‌کند.

بنابراین، بررسی کنید چه چیزی نصب شده است، هسته در حال اجرا و یک هسته جایگزین مطمئن را نگه دارید و بقیه را با استفاده از روش ایمن برای حذف هسته‌های قدیمی در Ubuntu پاک کنید. هرگز هسته‌ای را که uname -r در حال حاضر گزارش می‌دهد، حذف نکنید.

FAQ

آیا وصله زدن زنده هسته (Live kernel patching) به این معنی است که دیگر هرگز نیازی به reboot کردن VPS ندارم؟

خیر. وصله‌های زنده در هسته در حال اجرا بارگذاری می‌شوند و در image بوت نوشته نمی‌شوند، بنابراین linux-image موجود روی دیسک در همان نسخه‌ای که با آن بوت کرده‌اید باقی می‌ماند. Canonical مستقیماً اعلام کرده است: Livepatch «جایگزینی برای reboot کردن نیست. ابزاری است که با جلوگیری از rebootهای برنامه‌ریزی‌نشده، کنترل بیشتری به شما می‌دهد.» همچنین، پوشش این سرویس با بازنشسته شدن سری هسته شما به پایان می‌رسد و اصلاحات هسته با درجه اهمیت متوسط، هرگز به صورت زنده وصله نمی‌شوند. به جای انتظار برای اجبار به reboot، یک برنامه نگهداری دوره‌ای برای آن تنظیم کنید.

چگونه بررسی کنم که آیا وصله زنده هسته واقعاً در حال اعمال وصله‌ها است؟

دستور sudo canonical-livepatch status را اجرا کنید و دو خط خروجی آن را بخوانید. kernel state گزارش می‌دهد که آیا سری هسته در حال اجرای شما توسط این سرویس پوشش داده می‌شود یا خیر، و patch state گزارش می‌دهد که آیا وصله‌های مربوط به آن هسته بارگذاری شده‌اند یا خیر. همچنین می‌توانید وضعیت هسته را مستقیماً با ls /sys/kernel/livepatch/ بررسی کنید که به ازای هر وصله بارگذاری‌شده، یک دایرکتوری فهرست می‌کند. اگر خروجی این دستور خالی باشد، یعنی در حال حاضر هیچ وصله‌ای در حافظه اعمال نشده است، فارغ از اینکه کلاینت چه چیزی را نشان می‌دهد.

آیا Ubuntu Pro روی یک VPS شخصی رایگان است؟

بله، در محدوده مشخص‌شده. طبق اعلام Canonical، از اوت 2026، Ubuntu Pro «برای استفاده شخصی روی حداکثر 5 دستگاه فیزیکی رایگان است و همیشه رایگان خواهد ماند»، که این تعداد برای اعضای رسمی جامعه Ubuntu به 50 دستگاه افزایش می‌یابد. استفاده تجاری نیازمند اشتراک پولی است. شما با استفاده از sudo pro attach TOKEN و توکنی که از صفحه حساب Ubuntu Pro خود دریافت می‌کنید، دستگاه را متصل کرده و سپس سرویس را با sudo pro enable livepatch فعال می‌کنید.

چرا یک CVE هسته پس از اجرای Livepatch همچنان به عنوان اصلاح‌نشده فهرست می‌شود؟

معمولاً به یکی از دو دلیل زیر است. ممکن است اصلاحیه زیر حد آستانه اهمیت باشد، زیرا Canonical فقط «آسیب‌پذیری‌های هسته با درجه اهمیت بحرانی و بالا در سیستم امتیازدهی آسیب‌پذیری‌های رایج (CVSS) و رتبه‌بندی اولویت Ubuntu» را به صورت زنده وصله می‌کند و بقیه موارد را به پکیج موجود روی دیسک واگذار می‌کند. یا ممکن است اصلاحیه به صورت تغییر در بدنه یک تابع قابل پیاده‌سازی نباشد؛ برای مثال زمانی که upstream یک ساختار داده را تغییر داده است، که وصله زنده نمی‌تواند این کار را به صورت ایمن روی اشیاء از پیش تخصیص‌یافته انجام دهد. هر دو مورد به یک شکل حل می‌شوند: پکیج هسته به‌روزرسانی‌شده را نصب کنید و با آن بوت کنید.

وصله زنده هسته اصلاً چه مواردی را پوشش نمی‌دهد؟

فضای کاربری (Userspace). Canonical صراحتاً اعلام کرده است که Livepatch «کتابخانه‌های فضای کاربری مانند OpenSSL یا glibc را وصله نمی‌کند، زیرا این وظیفه unattended-upgrades یا ابزارهای مدیریت سیستم است.» همچنین این سرویس نمی‌تواند نسخه جدید هسته یا قابلیت جدیدی ارائه دهد، زیرا فقط بدنه‌های توابع را در سری هسته‌ای که در حال حاضر اجرا می‌کنید، جایگزین می‌کند. علاوه بر این، نمی‌تواند توابع __init را وصله کند، چرا که این توابع تا زمانی که سرور بالا می‌آید، اجرا شده و از حافظه آزاد شده‌اند.