Live kernel patching คืออะไร จำเป็นต้องรีบูต VPS หรือไม่

การทำ live kernel patching บน VPS

การทำ live kernel patching คือการนำแพตช์ความปลอดภัยของ kernel ไปปรับใช้กับเครื่องที่กำลังทำงานอยู่ โดยไม่ต้องรีบูตเครื่องและไม่มีการตัดการเชื่อมต่อ ระบบจะโหลดสำเนาของฟังก์ชันที่แก้ไขแล้วเข้ามาในรูปแบบ kernel module จากนั้นจะเปลี่ยนเส้นทางการเรียกใช้ฟังก์ชันเดิมไปที่สำเนาใหม่ในขณะที่เซิร์ฟเวอร์ยังคงให้บริการ traffic ตามปกติ กลไกนี้อธิบายทั้งข้อดีและข้อจำกัดของ live patching ได้เป็นอย่างดี

มันช่วยซื้อเวลาให้คุณ แต่ไม่ได้ทำให้การรีบูตหมดความจำเป็น เซิร์ฟเวอร์ที่ผ่านการทำ live patching มาเป็นเวลา 6 เดือนก็ยังคงรันอยู่บน kernel image เดิมที่อยู่ในดิสก์ และแพตช์ทั้งหมดนั้นจะคงอยู่เพียงแค่ในหน่วยความจำเท่านั้น

บ่อยครั้งที่ live patching ถูกนำเสนอเป็นฟีเจอร์ของแผนบริการแบบ managed สำหรับเครื่องแบบ unmanaged คุณสามารถเปิดใช้งานได้ด้วยตัวเองผ่าน 2 คำสั่ง ซึ่งเป็นสิ่งที่ควรทราบก่อนที่คุณจะตัดสินใจจ่ายเงินส่วนต่างระหว่าง VPS แบบ managed และ unmanaged

การทำ live kernel patching ทำงานอย่างไร

Kernel มีแกนหลักสำหรับการทำ live patching ในตัว ซึ่งถูกคอมไพล์รวมไว้ด้วย CONFIG_LIVEPATCH ให้ตรวจสอบ kernel ที่กำลังทำงานอยู่ของคุณว่ารองรับหรือไม่:

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

บรรทัดที่แสดง CONFIG_LIVEPATCH=y หมายความว่า kernel ที่คุณใช้งานอยู่ถูกสร้างขึ้นโดยมีแกนหลักดังกล่าว หากไม่มีสิ่งนี้ บริการ live patching จะไม่สามารถดำเนินการใดๆ บนเครื่องนั้นได้

การเปลี่ยนทิศทางการทำงาน (redirection) ใช้ ftrace ซึ่งเป็นเครื่องมือติดตามฟังก์ชันของ kernel ฟังก์ชันส่วนใหญ่ของ kernel ถูกคอมไพล์โดยมีคำสั่งเรียกใช้ (call instruction) อยู่ที่ส่วนบนสุดของฟังก์ชัน ก่อนที่จะมีการจัดการกับอาร์กิวเมนต์หรือ stack Ftrace จะใช้จุดเรียกใช้นั้นเป็น hook เมื่อมีการใช้ patch แกนหลักของ live patching จะลงทะเบียน ftrace handler ไว้ที่ฟังก์ชันเป้าหมาย และ handler นั้นจะส่งการทำงานไปยังฟังก์ชันทดแทนแทน เอกสารของ kernel อธิบายไว้อย่างชัดเจนว่า: "โดยทั่วไปแล้ว Livepatching จำเป็นต้องเปลี่ยนทิศทางโค้ดที่จุดเริ่มต้นของฟังก์ชัน ก่อนที่พารามิเตอร์ของฟังก์ชันหรือ stack จะถูกแก้ไขในลักษณะใดก็ตาม"

ผลลัพธ์สองประการที่ตามมาจากประโยคนั้นมีความสำคัญในภายหลัง ประการแรก เฉพาะฟังก์ชันที่ ftrace สามารถ hook ได้เท่านั้นที่จะทำ patch ได้ ดังนั้นฟังก์ชันที่คอมไพล์โดยไม่มีคำสั่งเรียกใช้ที่จุดเริ่มต้นจึงไม่สามารถทำ patch ได้เลย ประการที่สอง หน่วยของการทำ patch คือฟังก์ชันทั้งฟังก์ชัน ไม่ใช่แค่บรรทัดเดียวภายในฟังก์ชันนั้น

ส่วนที่ยากกว่าคือการสลับการทำงานของระบบที่กำลังรันอยู่ให้ปลอดภัย หากโค้ดเดิมยังคงทำงานอยู่บน stack ของ CPU บางตัวในขณะที่คุณสลับฟังก์ชัน คุณจะได้ผลลัพธ์ที่ผสมผสานระหว่างพฤติกรรมเก่าและใหม่ Linux upstream จัดการเรื่องนี้ด้วยโมเดลความสอดคล้องแบบ per-task ซึ่งในเอกสารของ kernel อธิบายว่าเป็นแบบไฮบริด: "ใช้ความสอดคล้องแบบ per-task ของ kGraft และการสลับด้วย syscall barrier รวมเข้ากับการสลับด้วย stack trace ของ kpatch" งาน (tasks) จะย้ายไปใช้โค้ดใหม่ทีละรายการ เฉพาะเมื่อ kernel สามารถยืนยันได้ว่างานนั้นไม่ได้อยู่ในฟังก์ชันที่ถูก patch อยู่ จนกว่าทุกงานจะย้ายเสร็จสิ้น patch นั้นจะอยู่ในสถานะกำลังเปลี่ยนผ่าน (transition)

คุณสามารถดูผลลัพธ์ได้ด้วยตนเอง Patch ที่ถูกใช้งานจะปรากฏภายใต้ /sys/kernel/livepatch โดยแบ่งเป็นหนึ่งไดเรกทอรีต่อหนึ่ง patch และมีรายการฟังก์ชันที่ถูก patch อยู่ภายใน

ls /sys/kernel/livepatch/

หากรายการว่างเปล่า หมายความว่าไม่มี live patch ถูกโหลดอยู่ในหน่วยความจำ ซึ่งเป็นสถานะเริ่มต้นปกติบนเซิร์ฟเวอร์ที่เพิ่งติดตั้งใหม่

สิ่งที่การทำ live kernel patching ไม่สามารถแก้ไขได้

การทำ patch จะส่งผลเฉพาะส่วนเนื้อหาของฟังก์ชันเท่านั้น ส่วนอื่นทั้งหมดจะไม่ได้รับผลกระทบ

• การเปลี่ยนแปลงโครงสร้างข้อมูล (Data structures): หากการแก้ไขจากต้นทางมีการเพิ่มฟิลด์เข้าไปใน struct หรือเปลี่ยนความหมายของฟิลด์เดิม จะไม่มีวิธีที่ปลอดภัยในการเขียนทับออบเจกต์ที่ถูกจัดสรรและใช้งานอยู่แล้ว โครงการ kpatch ระบุกรณีนี้ไว้อย่างชัดเจนว่า "Patch ที่แก้ไขข้อมูลซึ่งถูกจัดสรรแบบ static จะไม่ได้รับการสนับสนุนโดยตรง" แม้จะมี shadow variables และ callbacks เป็นวิธีแก้ปัญหาเฉพาะหน้า แต่สิ่งเหล่านี้ต้องเขียนขึ้นด้วยมือสำหรับแต่ละ patch ไม่ใช่กระบวนการอัตโนมัติ
• การแก้ไขที่กระจายตัวอยู่ในหลายฟังก์ชันพร้อมกัน: การแก้ไขที่เปลี่ยนลำดับการล็อก (lock ordering) ในกลุ่มฟังก์ชันจำเป็นต้องมีการเปลี่ยนแปลงทั้งหมดพร้อมกัน แต่รูปแบบความสอดคล้อง (consistency model) ของระบบจะใช้วิธีสลับงาน (task) แทนที่จะหยุดการทำงานของเครื่องทั้งหมดในเสี้ยววินาทีเดียว
• โค้ดส่วนการเริ่มต้นระบบ (Initialisation code): ฟังก์ชันที่ถูกระบุด้วย __init ได้ทำงานและถูกลบออกจากหน่วยความจำไปแล้วในขณะที่เซิร์ฟเวอร์ของคุณเริ่มทำงาน จึงไม่มีส่วนใดเหลือให้เปลี่ยนเส้นทาง (redirect) ได้อีก
• เคอร์เนลเวอร์ชันใหม่และฟีเจอร์ใหม่: การทำ live patching ช่วยให้คุณอัปเดตระดับ patch ภายในซีรีส์เคอร์เนลเดียวกันเท่านั้น ไม่สามารถใช้ข้ามจากซีรีส์หนึ่งไปยังอีกซีรีส์หนึ่งได้ และไม่สามารถเพิ่มฟีเจอร์ใหม่ได้ หากคุณต้องการสิ่งที่อยู่ในซีรีส์ที่ใหม่กว่า เช่น การเปลี่ยนแปลงที่รวมอยู่ใน Linux 7.1 คุณต้องติดตั้งเคอร์เนลนั้นและทำการบูตเครื่องใหม่
• Userspace: Canonical ระบุขอบเขตไว้อย่างชัดเจนว่า "Canonical Livepatch ไม่ได้ทำ patch ให้กับไลบรารีใน userspace เช่น OpenSSL หรือ glibc เนื่องจากเป็นหน้าที่ของ unattended-upgrades หรือเครื่องมือจัดการระบบ" การมีเคอร์เนลที่ผ่านการทำ live patch แต่ใช้ OpenSSL เวอร์ชันเก่าไม่ได้หมายความว่าเซิร์ฟเวอร์ของคุณปลอดภัย ดังนั้นควรเปิดใช้งาน unattended upgrades เพื่อจัดการแพ็กเกจใน userspace บนเครื่องเดียวกันไว้เสมอ

นอกจากนี้ยังมีขอบเขตด้านระดับความรุนแรงของบริการจาก Ubuntu โดย Canonical ระบุว่าจะ "ทำ patch ให้กับช่องโหว่ของเคอร์เนลที่มีระดับความรุนแรงสูงและวิกฤตตามมาตรฐาน Common Vulnerability Scoring System (CVSS) และระดับความสำคัญของ Ubuntu เท่านั้น" ตัวระบุ CVE (common vulnerabilities and exposures) จะระบุถึงข้อบกพร่องหนึ่งรายการ และ CVSS คือคะแนนที่กำกับไว้ ช่องโหว่เคอร์เนลที่มีระดับความรุนแรงปานกลางจะได้รับการแก้ไขในแพ็กเกจที่อยู่บนดิสก์และจะไม่ถูกทำ live patch ดังนั้นการแก้ไขจะส่งผลต่อเคอร์เนลที่กำลังทำงานอยู่ก็ต่อเมื่อมีการรีบูตเครื่องในครั้งถัดไปเท่านั้น

ตัวเลือกสำหรับการทำ live kernel patching มีอะไรบ้าง

มีสายการพัฒนาที่นิยมใช้กันอยู่ 3 สาย ซึ่งทั้งหมดทำงานบนกลไก kernel เดียวกัน

Canonical Livepatch ให้บริการผ่าน Ubuntu Pro โดย Ubuntu Pro เปิดให้ใช้งานส่วนบุคคลได้ฟรี ซึ่ง Canonical ระบุว่า "เป็นบริการฟรีสำหรับการใช้งานส่วนบุคคลบนเครื่องจริงสูงสุด 5 เครื่องเสมอ" และเพิ่มเป็น 50 เครื่องสำหรับสมาชิก Ubuntu Community อย่างเป็นทางการ นี่คือข้อจำกัดที่ระบุไว้ ณ เดือนสิงหาคม 2026 สำหรับการใช้งานเชิงพาณิชย์จำเป็นต้องมีการสมัครสมาชิกแบบชำระเงิน การครอบคลุมจะพิจารณาตามซีรีส์และรุ่นของ kernel โดยครอบคลุม kernel รุ่น general availability (GA) ของรุ่น long term support (LTS) ที่รองรับ รวมถึง kernel รุ่น hardware enablement (HWE) ในรุ่นต่างๆ เช่น generic, aws, azure, gcp, oracle, ibm และ lowlatency โปรดตรวจสอบ kernel ของคุณกับรายการ kernel ที่ Canonical เผยแพร่ก่อนตัดสินใจใช้งาน

KernelCare จาก TuxCare เป็นเอเจนต์เชิงพาณิชย์ที่ครอบคลุมหลาย distribution รวมถึงรุ่นที่ไม่มีบริการจากผู้ผลิตโดยตรง การติดตั้งตามเอกสารคือการใช้สคริปต์ของผู้ผลิต curl -s -L https://kernelcare.com/installer | bash ตามด้วย /usr/bin/kcarectl --register KEY สำหรับการใช้สิทธิ์แบบใช้คีย์ เอเจนต์จะตรวจสอบแพตช์ใหม่ตามกำหนดเวลาของตนเอง และ /usr/bin/kcarectl --update ใช้สำหรับบังคับตรวจสอบทันที โปรดอ่านสคริปต์ติดตั้งก่อนที่จะส่งผ่านข้อมูล (pipe) ไปยัง shell บนเซิร์ฟเวอร์ที่คุณให้ความสำคัญ

kpatch และ kGraft เป็นต้นแบบดั้งเดิม kGraft มาจาก SUSE ส่วน kpatch มาจาก Red Hat และกลไก live patching ใน Linux upstream ปัจจุบันคือการรวมแนวคิดของทั้งสองเข้าด้วยกัน ตัวโครงการ kpatch เองกำลังลดบทบาทลง โดย README ระบุว่าตั้งแต่ Linux 6.19 เป็นต้นไป "โครงการ kpatch ถูกเลิกใช้งานและอยู่ในโหมดบำรุงรักษา" โดย kpatch-build จะถูกแทนที่ด้วย klp-build ใน kernel upstream สำหรับ RHEL และรุ่นที่สร้างใหม่จาก RHEL เครื่องมือที่คุณควรใช้คือบริการของ distribution นั้นๆ แทนการสร้างแพตช์ด้วยตนเอง

ให้เลือกตามสิ่งที่ distribution ของคุณรองรับและสิ่งที่ใบอนุญาตของคุณอนุญาต ผลลัพธ์ในระดับ kernel นั้นเหมือนกันในทุกกรณี

วิธีการเปิดใช้งาน Canonical Livepatch บน Ubuntu

ให้ขอรับ token จากหน้าบัญชี Ubuntu Pro ของคุณก่อน คำสั่งทั้งสองด้านล่างจำเป็นต้องมีการเชื่อมต่อเครือข่ายขาออกที่ใช้งานได้ เนื่องจากไคลเอนต์ต้องติดต่อกับเซิร์ฟเวอร์ของ Canonical เพื่อทำการเชื่อมต่อและดึงข้อมูลแพตช์

sudo pro attach TOKEN
sudo pro status

การรัน sudo pro attach โดยไม่ระบุ token จะเป็นการเริ่มขั้นตอนผ่านเบราว์เซอร์แทน โดยระบบจะแสดงรหัสเพื่อให้คุณนำไปกรอกบนเว็บไซต์ของ Canonical การเชื่อมต่อจะเปิดใช้งานบริการที่แนะนำโดยอัตโนมัติ ซึ่งในรุ่น 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 ระบุว่า series ที่คุณใช้งานอยู่ได้รับความคุ้มครองจากบริการนี้หรือไม่ และเป็นบรรทัดที่จะแสดงสถานะผิดพลาดเมื่อคุณบูต 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 จะเป็น symlink ไปยัง /run ดังนั้นไม่ว่าจะใช้ path ใดก็จะได้ไฟล์เดียวกัน

แฟล็กดังกล่าวอยู่ใน tmpfs และจะถูกรีเซ็ตทุกครั้งที่บูตเครื่อง ดังนั้นควรยืนยันสถานะกับตัว kernel โดยตรง:

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

uname -r จะแสดงเวอร์ชัน kernel ที่คุณกำลังใช้งานอยู่ ส่วนคำสั่งที่สองจะแสดงรายการแพ็กเกจ kernel ที่ติดตั้งอยู่ในดิสก์ หากพบ linux-image ในรายการนั้นที่มีเวอร์ชันใหม่กว่าที่ uname -r รายงาน แสดงว่าเครื่องกำลังรัน kernel เวอร์ชันเก่าอยู่ ไม่ว่าสถานะของ Livepatch จะเป็นอย่างไรก็ตาม นี่คือการตรวจสอบที่สำคัญที่สุด เพราะ Livepatch ถูกออกแบบมาเพื่อให้ kernel ที่รันอยู่มีความปลอดภัย ไม่ใช่เพื่อให้เป็นเวอร์ชันล่าสุดเสมอไป

สำหรับส่วนของ userspace ในคำถามเดียวกัน needrestart จะถูกติดตั้งมาเป็นค่าเริ่มต้นใน Ubuntu Server และจะแสดงรายการบริการที่กำลังทำงานอยู่ซึ่งยังคงเรียกใช้ไฟล์ไลบรารีที่ถูกลบไปแล้ว

sudo needrestart -r l

คู่แฟล็ก -r l หมายถึง "แสดงรายการเท่านั้น" (list only) ดังนั้นมันจะรายงานผลโดยไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้น

เหตุใดการรีบูตจึงยังคงจำเป็น

Kernel ในดิสก์ไม่มีการเปลี่ยนแปลง Live patches จะถูกโหลดเข้าสู่ Kernel ที่กำลังทำงานอยู่เท่านั้น และไม่ได้ถูกเขียนลงใน boot image ดังนั้นการรีบูตจะทำให้คุณกลับมาใช้งาน linux-image ตามที่ bootloader เลือกไว้ จากนั้น Livepatch client จะทำการติดตั้ง patch ที่ยังคงใช้งานได้ใหม่อีกครั้ง ในช่วงเวลาระหว่างสองเหตุการณ์นี้ คุณกำลังรันโค้ดที่ยังไม่ได้ติดตั้ง patch ซึ่งเป็นอีกเหตุผลหนึ่งที่ควรบูตด้วย Kernel เวอร์ชันปัจจุบันแทนที่จะเป็นเวอร์ชันเก่า

การครอบคลุมของ patch จะจำกัดอยู่ตามซีรีส์ของ Kernel และซีรีส์เหล่านั้นจะถูกยกเลิกการสนับสนุน เมื่อซีรีส์ที่คุณใช้งานอยู่หลุดออกจากรายการที่รองรับ บรรทัด kernel state จะหยุดรายงานสถานะการครอบคลุม และวิธีแก้ไขเดียวคือการใช้ Kernel เวอร์ชันใหม่กว่า ซึ่งต้องอาศัยการรีบูต ในรุ่น LTS เวอร์ชันใหม่กว่ามักจะมาถึงคุณในรูปแบบของ hardware enablement kernel ที่รวมอยู่ใน a point release เช่น 26.04.1 ดังนั้นตัวไฟล์ทดแทนจึงอยู่ในคลังซอฟต์แวร์เรียบร้อยแล้ว สิ่งที่ขาดไปมีเพียงการรีบูตที่คุณต้องเป็นผู้กำหนดเวลา

การแก้ไข Kernel ที่มีความรุนแรงระดับปานกลางและระดับต่ำจะไม่ถูกทำ live patch โดยเด็ดขาด สิ่งเหล่านี้จะค้างอยู่ในแพ็กเกจบนดิสก์และจะมีผลต่อเมื่อคุณทำการบูตเครื่องเท่านั้น

Kernel ที่รันเป็นเวลานานจะสะสมสถานะที่การทำ patch ไม่สามารถล้างออกได้ จุดยืนของ Canonical เองนั้นควรค่าแก่การอ้างถึง เพราะเป็นจุดยืนที่ตรงไปตรงมา: Livepatch "ไม่ใช่สิ่งทดแทนการรีบูต แต่เป็นเครื่องมือที่ช่วยให้คุณควบคุมได้มากขึ้นโดยการป้องกันการรีบูตที่ไม่ได้วางแผนไว้" คำที่มีความหมายสำคัญในที่นี้คือ ไม่ได้วางแผนไว้ คุณยังคงต้องรีบูต แต่คุณเป็นผู้เลือกเวลาเอง

วิธีการตั้งเวลา reboot ให้ระบบกลับมาทำงานได้ตามปกติ

การ reboot VPS จะกลายเป็นทางตันหากคุณไม่สามารถเข้าถึงคอนโซลได้ ก่อนที่คุณจะพิมพ์ reboot ให้ตรวจสอบให้แน่ใจว่าคุณสามารถเข้าถึงเครื่องได้อีกครั้งในกรณีที่เครื่องไม่กลับมาทำงานตามปกติ

• ตรวจสอบว่าผู้ให้บริการของคุณมี serial console หรือหน้าจอ VNC (virtual network computing) ให้ใช้งานในแผงควบคุม และให้เปิดใช้งานไว้ตั้งแต่ตอนนี้ แทนที่จะไปเปิดตอนที่ระบบล่ม
• ตรวจสอบพื้นที่ว่างด้วย df -h /boot หาก /boot เต็ม จะทำให้แพ็กเกจ kernel ล้มเหลวขณะเขียน initramfs (initial RAM filesystem) ซึ่งอาจส่งผลให้ bootloader ชี้ไปยังอิมเมจที่เขียนไม่เสร็จสมบูรณ์
• เก็บ kernel เวอร์ชันเก่าที่ใช้งานได้ปกติไว้อย่างน้อยหนึ่งเวอร์ชัน GRUB จะแสดงรายการนี้ไว้ภายใต้ "Advanced options for Ubuntu" และการบูตด้วย kernel ดังกล่าวเป็นวิธีแก้ไขที่เร็วที่สุดเมื่อ kernel ใหม่มีปัญหา
• ค้นหาวิธีเข้าสู่โหมด rescue ของผู้ให้บริการก่อนที่คุณจะจำเป็นต้องใช้ หากคอนโซลแสดงพรอมต์ initramfs หลังจาก reboot นั่นคือจุดที่คุณต้องดำเนินการซ่อมแซม

จากนั้นให้ตั้งเวลา reboot ในช่วงเวลาที่คุณยังตื่นอยู่:

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

คำสั่งนี้จะตั้งเวลา reboot ล่วงหน้า 5 นาทีและส่งข้อความแจ้งเตือนไปยังผู้ใช้ที่ล็อกอินอยู่ ส่วน sudo shutdown -c ใช้สำหรับยกเลิกคำสั่งดังกล่าว เมื่อเครื่องกลับมาทำงานแล้ว ให้ตรวจสอบทั้งสองส่วน:

uname -r
sudo canonical-livepatch status

uname -r ควรแสดง kernel เวอร์ชันใหม่ และสถานะที่แสดงผลควรระบุว่าซีรีส์ใหม่ได้รับการครอบคลุมแล้ว หากเครื่องไม่กลับมาทำงานเลย ข้อผิดพลาดมักเกิดจากเส้นทางการบูต (boot path) ไม่ใช่ที่ระบบเครือข่าย และแนวทางการกู้คืนคือขั้นตอนที่ระบุไว้ใน คู่มือสำหรับ VPS ที่ไม่สามารถบูตได้หลังการอัปเดต kernel

เหตุผลที่ยังจำเป็นต้องล้าง kernel เก่าออก

การทำ live patching ทำให้ปัญหานี้แย่ลงแทนที่จะดีขึ้น เพราะมันลดความจำเป็นในการ reboot ในขณะที่แพ็กเกจ linux-image ยังคงติดตั้งอยู่เรื่อยๆ kernel แต่ละเวอร์ชันจะติดตั้ง boot image, initramfs, โครงสร้างโมดูล และมักจะมีแพ็กเกจ headers ติดตั้งมาด้วย บน VPS ขนาดเล็กที่มีพาร์ทิชัน /boot แยกต่างหากเพียงไม่กี่ร้อยเมกะไบต์ kernel เพียง 3 หรือ 4 เวอร์ชันก็สามารถทำให้พื้นที่เต็มได้

เมื่อ /boot เต็ม จะทำให้การติดตั้ง kernel ถัดไปล้มเหลว ซึ่งเป็นสาเหตุที่ทำให้เครื่องไม่สามารถรับอัปเดตที่จำเป็นได้ คำสั่ง apt autoremove จะล้าง kernel เก่าออกเมื่อถึงเงื่อนไขที่เหมาะสม แต่บนเครื่องที่ไม่เคย reboot เลย kernel เหล่านั้นอาจยังไม่เข้าเงื่อนไข เพราะตัวจัดการแพ็กเกจจะไม่ลบ kernel ที่คุณอาจกำลังใช้งานอยู่

ดังนั้น ให้ตรวจสอบว่ามีอะไรติดตั้งอยู่บ้าง โดยให้เก็บ kernel ที่กำลังใช้งานอยู่และ kernel สำรองที่ใช้งานได้ปกติไว้อีก 1 เวอร์ชัน จากนั้นลบส่วนที่เหลือออกโดยใช้ ขั้นตอนที่ปลอดภัยสำหรับการลบ kernel เก่าบน Ubuntu ห้ามลบ kernel ที่ uname -r รายงานว่ากำลังใช้งานอยู่ในขณะนั้นเด็ดขาด

FAQ

การทำ live kernel patching หมายความว่าฉันไม่ต้อง reboot VPS เลยใช่ไหม?

ไม่จำเป็น การทำ live patch จะโหลดเข้าสู่ kernel ที่กำลังทำงานอยู่เท่านั้น แต่ไม่ได้เขียนลงใน boot image ดังนั้น linux-image บนดิสก์จะยังคงเป็นเวอร์ชันเดิมที่คุณใช้บูตเครื่อง Canonical ระบุไว้อย่างชัดเจนว่า Livepatch "ไม่ใช่การทดแทนการ reboot แต่เป็นเครื่องมือที่ช่วยให้คุณควบคุมสถานการณ์ได้มากขึ้นโดยการป้องกันการ reboot แบบไม่ได้วางแผนไว้" นอกจากนี้ การครอบคลุมจะสิ้นสุดลงเมื่อ kernel ซีรีส์ของคุณถูกยกเลิกการสนับสนุน และการแก้ไข kernel ที่มีความรุนแรงระดับปานกลางจะไม่ถูกทำ live patch เลย คุณควรวางแผนการ reboot เพื่อบำรุงรักษาตามรอบเวลาที่คุณกำหนดเอง แทนที่จะรอให้ระบบบังคับให้คุณต้องทำ

ฉันจะตรวจสอบได้อย่างไรว่า live kernel patching กำลังทำงานอยู่จริง?

ให้รันคำสั่ง sudo canonical-livepatch status แล้วอ่านบรรทัดผลลัพธ์สองบรรทัด โดย kernel state จะรายงานว่า kernel ซีรีส์ที่คุณใช้งานอยู่ได้รับการครอบคลุมโดยบริการหรือไม่ และ patch state จะรายงานว่ามีการโหลด patch สำหรับ kernel นั้นแล้วหรือยัง คุณยังสามารถตรวจสอบฝั่ง kernel ได้โดยตรงด้วย ls /sys/kernel/livepatch/ ซึ่งจะแสดงรายการไดเรกทอรีของ patch ที่ถูกโหลดไว้ หากรายการว่างเปล่าหมายความว่าไม่มีการ patch ใดๆ ในหน่วยความจำ ณ ขณะนี้ ไม่ว่า client จะรายงานอย่างไรก็ตาม

Ubuntu Pro ฟรีสำหรับ VPS ส่วนตัวหรือไม่?

ฟรี ภายใต้ขอบเขตที่กำหนดไว้ Canonical ระบุว่า Ubuntu Pro "เป็นบริการฟรีสำหรับการใช้งานส่วนตัวบนเครื่อง physical สูงสุด 5 เครื่องเสมอ" และเพิ่มเป็น 50 เครื่องสำหรับสมาชิก Ubuntu Community อย่างเป็นทางการ ณ เดือนสิงหาคม 2026 สำหรับการใช้งานเชิงพาณิชย์จำเป็นต้องสมัครสมาชิกแบบเสียค่าใช้จ่าย คุณสามารถเชื่อมต่อเครื่องด้วย sudo pro attach TOKEN โดยใช้ token จากหน้าบัญชี Ubuntu Pro ของคุณ จากนั้นเปิดใช้งานบริการด้วย sudo pro enable livepatch

ทำไม CVE ของ kernel ถึงยังแสดงสถานะว่าไม่ได้รับการแก้ไขหลังจากรัน Livepatch แล้ว?

โดยปกติเกิดจากสองสาเหตุหลัก สาเหตุแรกคือการแก้ไขนั้นอาจมีความรุนแรงต่ำกว่าเกณฑ์ที่กำหนด เนื่องจาก Canonical จะทำ live patch เฉพาะ "ช่องโหว่ของ kernel ที่มีความรุนแรงระดับวิกฤตและสูงตามมาตรฐาน Common Vulnerability Scoring System (CVSS) และระดับความสำคัญของ Ubuntu" เท่านั้น ส่วนที่เหลือจะปล่อยให้เป็นหน้าที่ของแพ็กเกจบนดิสก์ สาเหตุที่สองคือการแก้ไขนั้นอาจไม่สามารถทำได้โดยการเปลี่ยนเนื้อหาในฟังก์ชัน เช่น กรณีที่ upstream มีการปรับเปลี่ยนโครงสร้างข้อมูล ซึ่งการทำ live patching ไม่สามารถทำได้อย่างปลอดภัยกับออบเจกต์ที่ถูกจัดสรรหน่วยความจำไปแล้ว ทั้งสองกรณีแก้ไขได้ด้วยวิธีเดียวกัน คือการติดตั้งแพ็กเกจ kernel เวอร์ชันอัปเดตแล้วทำการ reboot เข้าสู่ kernel ใหม่

การทำ live kernel patching ไม่ครอบคลุมส่วนใดบ้าง?

ไม่ครอบคลุม userspace Canonical ระบุไว้อย่างชัดเจนว่า Livepatch "ไม่ทำการ patch ไลบรารีใน userspace เช่น OpenSSL หรือ glibc เนื่องจากเป็นหน้าที่ของ unattended-upgrades หรือเครื่องมือจัดการระบบ" นอกจากนี้ยังไม่สามารถส่งมอบ kernel เวอร์ชันใหม่หรือฟีเจอร์ใหม่ได้ เนื่องจากทำได้เพียงแทนที่เนื้อหาฟังก์ชันภายในซีรีส์ที่คุณใช้งานอยู่เท่านั้น และไม่สามารถ patch ฟังก์ชัน __init ซึ่งทำงานเสร็จสิ้นและถูกลบออกจากหน่วยความจำไปแล้วตั้งแต่ตอนที่เซิร์ฟเวอร์เริ่มทำงานได้สำเร็จ