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

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

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

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

وصله کردن زنده اغلب به عنوان یکی از ویژگی‌های طرح‌های مدیریت‌شده (managed) فروخته می‌شود. در یک سرور مدیریت‌نشده (unmanaged)، شما می‌توانید خودتان آن را با دو دستور فعال کنید؛ دانستن این موضوع پیش از پرداخت هزینه برای تفاوت بین یک VPS مدیریت‌شده و یک 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) قادر به اصلاح آن‌ها نیست

بدنهٔ توابع وصله می‌شوند. سایر موارد تغییر نمی‌کنند.

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

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

گزینه‌های وصله زنده (live kernel 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

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

sudo pro attach TOKEN
sudo pro status

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

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

sudo pro enable livepatch
sudo canonical-livepatch status

این سرویس از طریق snap با نام 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 فهرست بسته‌هایی را که درخواست reboot کرده‌اند، نگه می‌دارد. اگر دستور اول خروجی No such file or directory را برگرداند، یعنی از آخرین باری که دستگاه روشن شده، هیچ درخواستی برای reboot ثبت نشده است. در نسخه‌های فعلی Ubuntu، فایل /var/run یک symlink به /run است، بنابراین هر دو مسیر به یک فایل واحد اشاره دارند.

این پرچم در یک tmpfs قرار دارد و با هر بار reboot بازنشانی می‌شود، بنابراین آن را با وضعیت خودِ 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. در نسخه‌های LTS، سری‌های جدیدتر معمولاً در قالب یک hardware enablement kernel و در یک point release مانند 26.04.1 به دست شما می‌رسند؛ بنابراین جایگزین آن از قبل در آرشیو موجود است و تنها چیزی که کم دارید، یک 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 همچنان نصب می‌شوند. هر هسته یک boot image، یک initramfs، یک درخت ماژول و معمولاً یک بسته headers نصب می‌کند. در یک VPS کوچک با پارتیشن /boot مجزا که تنها چند صد مگابایت ظرفیت دارد، سه یا چهار مورد از آن‌ها فضا را پر می‌کنند.

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

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

FAQ

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

خیر. وصله‌های زنده در هستهٔ در حال اجرا بارگذاری می‌شوند و در image بوت نوشته نمی‌شوند، بنابراین linux-image موجود روی دیسک در همان نسخه‌ای که با آن بوت کرده‌اید باقی می‌ماند. Canonical مستقیماً اعلام کرده است: Livepatch «جایگزینی برای reboot کردن نیست. ابزاری است که با جلوگیری از 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 دستگاه افزایش می‌یابد. استفادهٔ تجاری نیازمند اشتراک پولی است. شما با استفاده از یک توکن از صفحهٔ حساب کاربری Ubuntu Pro خود، دستگاه را با sudo pro attach TOKEN متصل می‌کنید و سپس سرویس را با sudo pro enable livepatch فعال می‌نمایید.

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

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

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

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