วิธีการติดตั้งโมดูลเคอร์เนลแบบกำหนดเองบน SLES 15 ด้วยการบูตแบบปลอดภัย

ในการโหลดโมดูลเคอร์เนลแบบกำหนดเองบน SLES 15 ที่เปิดใช้งาน Secure Boot ให้สร้างโมดูลนั้นสำหรับเคอร์เนลที่คุณจะใช้งานโดยเฉพาะ ลงนาม.koไฟล์ที่เสร็จสมบูรณ์ด้วยใบรับรองการลงนามที่เชื่อถือได้ ลงทะเบียนใบรับรองนั้นเป็น Machine Owner Key (MOK) แล้วจึงโหลดโมดูลด้วยคำสั่ง `secure boot` modprobeMOKคือใบรับรองที่ควบคุมได้ในเครื่อง ซึ่ง shim ของ SUSE และเคอร์เนล Linux สามารถเชื่อถือได้สำหรับการตรวจสอบโมดูล Secure Boot อย่าปิด Secure Boot เพื่อแก้ไขปัญหาการลงนามที่ไม่ได้รับการอนุมัติ กระบวนการด้านล่างนี้สำหรับผู้ดูแลระบบที่ควบคุมเครื่องและสามารถอนุมัติการลงทะเบียนคีย์ได้เมื่อรีบูตเครื่อง

คู่มือนี้อ้างอิงจากเอกสารการดูแลระบบ SLES 15 SP7 ของ SUSE และคำแนะนำเกี่ยวกับการจัดแพ็กเกจโมดูลเคอร์เนลของ SUSE ซึ่งตรวจสอบแล้วเมื่อวันที่ 6 ตุลาคม 2026 คำสั่งต่างๆ ใช้acme_driverชื่อโมดูลเป็นตัวอย่าง โปรดแทนที่ด้วยชื่อโมดูลจริงโดยไม่มี.koคำต่อท้ายในส่วนที่เหมาะสม นี่เป็นเพียงตัวอย่างคำสั่ง ไม่ใช่ผลลัพธ์จากโฮสต์ที่ทดสอบแล้ว

เมื่อวิธีการนี้เหมาะสม

ใช้วิธีนี้สำหรับโมดูลที่กำหนดเองซึ่งอยู่นอกโครงสร้างหลักของเคอร์เนล—โมดูลที่จัดหาแยกต่างหากจากเคอร์เนลที่กำลังทำงานอยู่—เมื่อคุณสามารถสร้างใหม่หรือขอรับเวอร์ชันสำหรับเคอร์เนล SLES เป้าหมายได้ และสามารถลงทะเบียนใบรับรองบนเซิร์ฟเวอร์ได้ วิธีนี้ใช้ได้กับระบบที่บูตผ่าน SUSE Secure Boot และเส้นทาง shim หากผู้จำหน่ายจัดหาแพ็คเกจไดรเวอร์ SLES 15 อย่างเป็นทางการ ให้ใช้คำแนะนำในการติดตั้งและการลงนามที่ได้รับการสนับสนุนจากผู้จำหน่ายก่อน แพ็คเกจของผู้จำหน่ายอาจจัดการความเข้ากันได้ของเคอร์เนลและการอัปเดตได้ดีกว่าการคัดลอกด้วยตนเอง

Secure Boot ตรวจสอบความถูกต้องของลำดับการบูต และเคอร์เนลยังตรวจสอบลายเซ็นบนโมดูลที่โหลดได้ภายใต้นโยบายที่เกี่ยวข้อง โมดูลอาจได้รับการลงนามแล้วแต่ยังคงโหลดไม่สำเร็จหากกำหนดเป้าหมายไปที่ ABI ของเคอร์เนลที่แตกต่างกัน ขึ้นอยู่กับสัญลักษณ์ที่ขาดหายไป หรือสร้างขึ้นสำหรับสถาปัตยกรรมที่ไม่ถูกต้อง ในทางกลับกัน การที่ตรงกับเคอร์เนลไม่ได้ทำให้โมดูลที่ไม่ได้ลงนามนั้นน่าเชื่อถือ การลงนามมีไว้เพื่อสร้างความน่าเชื่อถือ ไม่ได้เป็นการสร้างความเข้ากันได้หรือรับรองว่าโค้ดนั้นปลอดภัย

ก่อนที่คุณจะเริ่มต้น

• ใช้บัญชีผู้ดูแลระบบและตรวจสอบว่าคุณมีช่วงเวลาสำหรับการบำรุงรักษา การลงทะเบียน MOK จำเป็นต้องรีบูตเครื่องและต้องได้รับการอนุมัติใน MokManager ซึ่งโดยปกติจะทำผ่านคอนโซลภายในเครื่องหรือคอนโซลระยะไกล
• ตรวจสอบสถานะเคอร์เนลที่กำลังทำงานอยู่และสถานะ Secure Boot ด้วยคำสั่ง `src` และ `src` uname -rสร้างmokutil --sb-stateโมดูลโดยใช้ไฟล์พัฒนาเคอร์เนลและชุดเครื่องมือที่ตรงกันสำหรับเคอร์เนลเวอร์ชันนั้น ชื่อแพ็กเกจและไฟล์ที่จำเป็นจะแตกต่างกันไปตาม Service Pack ของ SLES เคอร์เนลเวอร์ชัน และวิธีการสร้าง ดังนั้นโปรดตรวจสอบกับที่เก็บข้อมูลที่เปิดใช้งานบนระบบเป้าหมาย
• ตัดสินใจว่าจะเก็บคีย์ลงนามส่วนตัวไว้ที่ใด สำหรับระบบที่ใช้งานจริง ควรใช้บริการลงนามที่องค์กรควบคุมหรือกระบวนการจัดการคีย์ที่ได้รับการอนุมัติ สำหรับห้องปฏิบัติการหรือโฮสต์ที่ควบคุมเพียงเครื่องเดียว การสร้างคีย์ในเครื่องก็อาจเหมาะสมกว่า ปกป้องคีย์ส่วนตัว เซิร์ฟเวอร์ต้องการใบรับรองสาธารณะสำหรับการลงทะเบียน ไม่ใช่คีย์ส่วนตัว
• ควรเตรียมเส้นทางการกู้คืน ระบบจัดเก็บซอร์สโค้ดหรือแพ็กเกจจากผู้จำหน่ายของโมดูล และเคอร์เนลที่ใช้งานได้ดีไว้ให้พร้อม อย่าโหลดไดรเวอร์ลงบนฮาร์ดแวร์ที่ใช้งานจริงจนกว่าคุณจะเข้าใจข้อกำหนดของอุปกรณ์และเคอร์เนลเสียก่อน

1. สร้างคีย์ลงนามและใบรับรองสาธารณะ

ในระบบลงนามที่มีการป้องกัน ให้สร้างคีย์ส่วนตัวและใบรับรอง X.509 ที่เข้ารหัสแบบ DER คำแนะนำเกี่ยวกับการจัดแพ็กเกจโมดูลเคอร์เนลของ SUSE ระบุให้codeSigningใช้คีย์แบบขยายใน Service Pack ของ SLES 15 รุ่นปัจจุบัน ตัวอย่างนี้ใช้ OpenSSL และชื่อใบรับรองที่สื่อความหมาย:

openssl req -new -x509 -newkey rsa:2048 -sha256 \
  -keyout module-signing.key \
  -out module-signing.der -outform DER -nodes \
  -days 4745 -addext "extendedKeyUsage=codeSigning" \
  -subj "/CN=Custom Module Signing/"
chmod 600 module-signing.key

ตัวเลือก นี้-nodesไม่ได้เข้ารหัสคีย์ส่วนตัว ดังนั้นสิทธิ์การเข้าถึงไฟล์และการควบคุมการจัดเก็บจึงมีความสำคัญ อย่าคัดลอกคีย์ส่วนตัวนั้นไปยังเซิร์ฟเวอร์ทั่วไปหรือฝังไว้ในแพ็กเกจ หากนโยบายขององค์กรกำหนดให้ใช้คีย์ที่เข้ารหัส การลงนามโดยใช้ฮาร์ดแวร์ การหมุนเวียนคีย์ หรือวงจรชีวิตของใบรับรองที่แตกต่างกัน ให้ปฏิบัติตามนโยบายนั้นและข้อกำหนดของเครื่องมือลงนาม ถ่ายโอนเฉพาะmodule-signing.derไปยังระบบที่จะลงทะเบียนคีย์สาธารณะ เท่านั้น

2. สร้างโมดูลสำหรับเคอร์เนลเป้าหมายและลงนามรับรอง

สร้างโมดูลโดยใช้เวอร์ชันเคอร์เนลที่แสดงไว้อย่างแม่นยำuname -rคำแนะนำในการสร้างของโปรเจกต์ต้นฉบับจะเป็นตัวกำหนดคอมไพเลอร์ เฮดเดอร์ และการกำหนดค่าที่จำเป็น ไม่มีคำสั่งสร้างเดียวที่ใช้ได้กับทุกโมดูลที่กำหนดเอง ตรวจสอบผลลัพธ์vermagicด้วยmodinfoหากคุณต้องการวินิจฉัยความไม่ตรงกันของเคอร์เนล

ลงนามในไฟล์โมดูลสุดท้ายหลังจากคอมไพล์และขั้นตอนการบรรจุหรือการแยกส่วนใดๆ เสร็จสิ้นแล้ว เอกสารของ SUSE เกี่ยวกับเครื่องมือช่วยในการลงนามอยู่ที่นี่/usr/lib/rpm/pesign/kernel-sign-file; ตัวอย่างต่อไปนี้ใช้รูปแบบ PKCS#7 และค่าแฮช SHA-256:

/usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 \
  module-signing.key module-signing.der acme_driver.ko

ตัวช่วยจะต้องมีอยู่ในระบบการลงนามของ SUSE หากไม่มี ให้ตรวจสอบเอกสาร SLES/KMP อย่างเป็นทางการและที่เก็บข้อมูลที่เปิดใช้งานสำหรับการตั้งค่าการลงนามที่รองรับ แทนที่จะใช้คำสั่งลงนามแบบสุ่ม ลายเซ็นของโมดูลจะถูกเพิ่มเข้าไปในไฟล์ ห้ามลบ แก้ไข บีบอัดใหม่ หรือเปลี่ยนแปลงโมดูลหลังจากลงนามแล้ว การเปลี่ยนแปลงดังกล่าวอาจทำให้ลายเซ็นไม่ถูกต้อง เก็บไฟล์ต้นฉบับที่สมบูรณ์ไว้เพื่อให้คุณสามารถทำขั้นตอนการลงนามขั้นสุดท้ายซ้ำได้

3. ลงทะเบียนใบรับรองสาธารณะเป็น MOK

บนเซิร์ฟเวอร์ SLES ให้วางmodule-signing.derใบรับรองสาธารณะไว้ในตำแหน่งที่ผู้ใช้ root สามารถอ่านได้ จากนั้นจัดคิวเพื่อลงทะเบียน:

mokutil --root-pw --import module-signing.der
mokutil --list-new

เอกสารของ SUSE --root-pwระบุวิธีการอนุญาตการลงทะเบียนที่รอดำเนินการโดยใช้รหัสผ่าน root คำสั่งนำเข้าจะจัดคิวใบรับรอง ไม่ได้ลงทะเบียนทันที รีบูตเซิร์ฟเวอร์ ใน MokManager เลือกEnroll key from diskเลือกใบรับรอง ยืนยันการลงทะเบียน และดำเนินการอนุญาตที่ร้องขอให้เสร็จสมบูรณ์ ข้อความในเมนูอาจแตกต่างกันเล็กน้อยขึ้นอยู่กับเวอร์ชันของ shim/MokManager หากคุณไม่สามารถเข้าถึงหน้าจอการลงทะเบียนได้ ให้ตรวจสอบเส้นทางการบูตและจัดเตรียมการเข้าถึงคอนโซล อย่าคิดว่าใบรับรองได้รับการลงทะเบียนแล้วเพียงเพราะคำสั่งนำเข้าสำเร็จ

หลังจากเซิร์ฟเวอร์เริ่มทำงานแล้ว โปรดตรวจสอบว่าคีย์ปรากฏอยู่ในรายการที่ลงทะเบียนไว้หรือไม่:

mokutil --list-enrolled

4. ติดตั้ง อัปเดตส่วนประกอบที่จำเป็น และโหลดโมดูล

คัดลอกไฟล์ที่ลงนามแล้วไปยังไดเร็กทอรี extra-modules สำหรับเคอร์เนลที่กำลังทำงานอยู่ รีเฟรชแผนผังการพึ่งพา และร้องขอโมดูลตามชื่อ หากคุณกำลังติดตั้งสำหรับเคอร์เนลที่บูตแตกต่างกัน ให้แทนที่ด้วยเวอร์ชันเคอร์เนลจริง:

release=$(uname -r)
install -D -m 0644 acme_driver.ko \
  "/lib/modules/$release/extra/acme_driver.ko"
depmod -a "$release"
modprobe acme_driver

modprobeโดยทั่วไปแล้ว วิธีนี้เป็นที่นิยมมากกว่าinsmodเพราะช่วยแก้ปัญหาการพึ่งพาของโมดูล ทดสอบอุปกรณ์หรือฟังก์ชันการทำงานจริงที่ไดรเวอร์มีให้ คำสั่งที่สำเร็จเพียงอย่างเดียวไม่ได้พิสูจน์ว่าฮาร์ดแวร์ทำงานได้อย่างถูกต้อง หากต้องการโหลดโมดูลเมื่อบูตเครื่อง ให้เพิ่มชื่อโมดูลในบรรทัดแยกต่างหากในไฟล์ เช่น/etc/modules-load.d/acme_driver.conf.sys/module.js SLES ใช้กลไกการโหลดโมดูลของ systemd สำหรับไฟล์การกำหนดค่าเหล่านี้

5. ตรวจสอบเส้นทางความเชื่อถือและแก้ไขปัญหาที่เกิดขึ้น

การตรวจสอบที่เป็นประโยชน์ ได้แก่:

mokutil --list-enrolled
modinfo -F signer /lib/modules/$(uname -r)/extra/acme_driver.ko
lsmod | grep acme_driver
journalctl -k -b | tail -n 80

modinfo -F signerแสดงข้อมูลเมตาของผู้ลงนามที่ฝังอยู่ในโมดูล แต่ข้อมูลนี้เพียงอย่างเดียวไม่สามารถพิสูจน์ได้ว่าใบรับรองได้รับการลงทะเบียนแล้ว หรือเคอร์เนลที่กำลังทำงานอยู่ยอมรับลายเซ็น การทดสอบที่สำเร็จmodprobeโดยที่ Secure Boot ยังคงเปิดใช้งานอยู่ ตามด้วยการตรวจสอบบันทึกของเคอร์เนลและการตรวจสอบการทำงานของอุปกรณ์ จะเป็นหลักฐานที่มีประโยชน์มากกว่า เอาต์พุตเทอร์มินัลที่แสดงในรูปเป็นเพียงตัวอย่างของคำสั่งและผลลัพธ์ที่แสดงให้เห็น ไม่ใช่รายงานการทดสอบที่ดำเนินการสำหรับบทความนี้

SUSE ยังติดตามด้วยว่าโมดูลใดได้รับการสนับสนุน และการโหลดโมดูลที่ไม่ได้รับการสนับสนุนอาจส่งผลต่อสถานะการสนับสนุนหรือสถานะปนเปื้อนของเคอร์เนล นโยบายดังกล่าวแยกต่างหากจากการตรวจสอบลายเซ็น: การเปลี่ยนแปลงการตั้งค่าโมดูลที่ไม่ได้รับการสนับสนุนจะไม่ลงทะเบียนคีย์ลงนามและจะไม่ซ่อมแซมลายเซ็นที่ถูกปฏิเสธ โปรดตรวจสอบคำแนะนำการสนับสนุนของ SUSE ก่อนที่จะเปลี่ยนแปลงนโยบายดังกล่าวในระบบการผลิตที่ได้รับการสนับสนุน

วางแผนสำหรับการอัปเดตเคอร์เนลและการติดตั้งซ้ำ

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

สำหรับกลุ่มอุปกรณ์หรือไดรเวอร์ที่ต้องรองรับการอัปเดตเป็นประจำ ให้ใช้เวิร์กโฟลว์การจัดแพ็กเกจที่ทำซ้ำได้ เช่น แนวทาง Kernel Module Package (KMP) ของ SUSE ในกรณีที่เหมาะสมกับไดรเวอร์และโมเดลการสนับสนุนของคุณ การจัดแพ็กเกจสามารถจัดการขั้นตอนการสร้างและการลงนามต่อเคอร์เนลได้ แต่ไม่ได้ขจัดความจำเป็นในการป้องกันคีย์ที่ถูกต้อง ความเข้ากันได้ของโมดูล ความน่าเชื่อถือของ MOK และการทดสอบการอัปเดต โปรดศึกษาเอกสารประกอบสำหรับ Service Pack ของ SLES 15 ที่แน่นอนและวงจรชีวิตของเคอร์เนลที่องค์กรของคุณรองรับ

เอกสารอ้างอิงอย่างเป็นทางการ

• คู่มือการดูแลระบบ SUSE Linux Enterprise Server 15 SP7 — การบูตแบบปลอดภัยและการลงทะเบียน MOK การโหลดโมดูล และนโยบายโมดูลที่ไม่รองรับ
• คู่มือแพ็กเกจโมดูลเคอร์เนลของ SUSE — กระบวนการลงนาม KMP และข้อกำหนดการลงนามที่ใช้กับ SLES 15
• เอกสารเกี่ยวกับการลงนามโมดูลเคอร์เนล Linux — พฤติกรรมการลงนามเคอร์เนลและข้อจำกัดของไฟล์โมดูลที่ลงนามแล้ว