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 ได้ ดังนั้นฟังก์ชันที่คอมไพล์โดยไม่มี call instruction ที่จุดเริ่มต้นจึงไม่สามารถ patch ได้เลย และหน่วยของการ patch คือฟังก์ชันทั้งฟังก์ชัน ไม่ใช่แค่บรรทัดเดียวภายในฟังก์ชันนั้น

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

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

ls /sys/kernel/livepatch/

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

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

การแก้ไขจะทำได้เฉพาะในส่วนของเนื้อหาฟังก์ชันเท่านั้น ส่วนอื่นไม่สามารถทำได้

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

นอกจากนี้ยังมีเกณฑ์ความรุนแรงสำหรับบริการของ Ubuntu โดย Canonical ระบุว่าจะ "แพตช์ช่องโหว่ของเคอร์เนลที่มีระดับความรุนแรงสูงและวิกฤตตามมาตรฐาน 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 อย่างเป็นทางการ นี่คือข้อจำกัดที่ระบุไว้ ณ เดือนสิงหาคม 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 เพื่อบังคับให้ตรวจสอบทันที โปรดอ่านสคริปต์ติดตั้งก่อนที่จะส่งผ่านไปยัง shell บนเซิร์ฟเวอร์ที่คุณต้องการดูแล

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

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

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

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

sudo pro attach TOKEN
sudo pro status

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

เนื่องจาก flag ดังกล่าวอยู่ใน 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

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

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

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

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

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

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

วิธีตั้งเวลา 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 mode ของผู้ให้บริการไว้ก่อนที่คุณจะจำเป็นต้องใช้ หากคอนโซลแสดงพรอมต์ 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 เพียงสามหรือสี่ตัวก็สามารถทำให้พื้นที่เต็มได้

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

ดังนั้น ให้ตรวจสอบว่ามีการติดตั้งอะไรไว้บ้าง โดยให้เก็บ kernel ที่กำลังใช้งานอยู่และ kernel สำรองที่ใช้งานได้ปกติไว้อีกหนึ่งตัว จากนั้นลบส่วนที่เหลือออกโดยใช้ ขั้นตอนที่ปลอดภัยสำหรับการลบ 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 กำลังใช้งาน patch อยู่จริง?

ให้รันคำสั่ง 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 "เป็นบริการฟรีสำหรับการใช้งานส่วนตัวสูงสุด 5 เครื่อง" และเพิ่มเป็น 50 เครื่องสำหรับสมาชิกชุมชน Ubuntu อย่างเป็นทางการ ณ เดือนสิงหาคม 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 เข้าสู่เวอร์ชันนั้น

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

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