如何在啟用安全啟動的 SLES 15 上安裝自訂核心模組

若要在啟用安全啟動的 SLES 15 上載入自訂核心模組，請針對您將要執行的核心版本進行編譯，.ko使用受信任的簽名憑證對編譯後的檔案進行簽名，並將該憑證註冊為機器所有者金鑰 (MOK)，然後載入該模組modprobe。 MOK是本機控制的證書，SUSE 的 shim 和 Linux 核心可以信任它來驗證安全啟動模組。請勿為了繞過簽名被拒絕的問題而關閉安全啟動。以下步驟適用於控制該機器並可以在重新啟動時批准金鑰註冊的管理員。

本指南遵循 SUSE SLES 15 SP7 管理文件和 SUSE 核心模組打包指南，並於 2026 年 10 月 6 日進行了審核。命令範例使用 ` acme_driver<module_name>` 作為模組名稱；請.ko根據需要將其替換為實際模組名稱（不含後綴）。這些僅為命令範例，並非來自已測試主機的輸出。

範例終端命令：使用 mokutil 檢查安全啟動，並使用 uname 識別正在執行的 SLES 內核 — 範例預檢命令：在建置模組之前確認安全啟動狀態並記錄確切的核心版本。

當這種方法合適時

對於自訂的外部模組（即與運行中的核心分開提供的模組），如果可以重新建置或取得目標 SLES 核心的建置版本，並且可以在伺服器上註冊證書，則可以使用此方法。此方法適用於透過 SUSE 安全啟動和 shim 路徑啟動的系統。如果供應商提供了官方的 SLES 15 驅動程式包，請先使用其支援的安裝和簽名說明；供應商提供的軟體包在內核相容性和更新方面可能優於手動複製的軟體包。

安全啟動會驗證啟動鏈，核心也會根據適用的策略檢查可載入模組的簽章。即使模組已簽名，如果其目標核心應用二進位介面 (ABI) 不同、依賴缺少的符號或為錯誤的架構構建，則仍然可能無法載入。反之，即使與核心匹配，未簽署的模組也並非可信。簽章解決的是信任問題，而不是建立相容性或證明程式碼安全性。

開始之前

請使用管理員帳戶並確認您有維護窗口。 MOK 註冊需要重新啟動系統，並在 MokManager 中進行審核操作，通常可透過本機或遠端控制台完成。
使用 `src/ config uname -r...mokutil --sb-state
確定私鑰的儲存位置。對於生產環境，請使用組織內部受控的簽章服務或已核准的金鑰管理流程。對於實驗室環境或單一受控主機，本地產生的金鑰可能更為實用。務必保護好私鑰；伺服器註冊時需要的是公鑰證書，而不是私鑰。
保留恢復路徑、模組原始碼或供應商軟體包以及已知可用的核心。在了解驅動程式的裝置和核心需求之前，請勿將其載入到生產硬體上。

1. 建立簽署金鑰和公鑰憑證

在受保護的簽章系統中，建立私鑰和 DER 編碼的 X.509 憑證。 SUSE 核心模組打包指南要求codeSigning在目前的 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到將要註冊公鑰的系統。

範例終端顯示了 OpenSSL 程式碼簽署憑證命令以及對私鑰的限制性權限 — 憑證建立和金鑰權限命令範例；對私鑰進行受控存取。

2. 為目標核心建立模組並對其進行簽名

使用 `--kernel-version` 指令指定的核心版本建構模組uname -r。來源專案的建置說明決定了所需的編譯器、頭檔和配置；沒有一個建置命令適用於所有自訂模組。如果需要診斷內核不符合問題，vermagic請使用`--kernel-version` 指令檢查結果。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 文件和已啟用的軟體倉庫，以了解支援的簽名設置，而不是隨意使用簽名命令。模組簽名會附加到檔案中。簽名後，請勿剝離、編輯、重新壓縮或以其他方式更改模組；此類更改可能會使簽名失效。請保留原始的建置產物，以便您可以重複最終的簽章步驟。

範例：使用 SUSE kernel-sign-file 指令對 acme_driver.ko 檔案進行 PKCS7 SHA-256 簽名 — SUSE 簽署助理使用受保護的私鑰及其相符的公鑰憑證對已完成的模組檔案進行簽署。

3. 將公共憑證註冊為 MOK

在 SLES 伺服器上，將公鑰module-signing.der憑證放在 root 使用者可以讀取的位置，然後將其加入註冊佇列：

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

SUSE 文件中--root-pw介紹了一種使用 root 密碼授權待註冊憑證的方法。導入指令會將憑證加入佇列，但不會立即註冊。重啟伺服器。在 MokManager 中，選擇「從磁碟註冊金鑰」，選擇證書，確認註冊，並完成所需的授權。選單措辭可能會因 shim/MokManager 版本而略有不同。如果無法存取註冊螢幕，請檢查啟動路徑並安排控制台存取權限；不要因為匯入命令成功就認為證書已註冊。

伺服器啟動後，確認金鑰出現在已註冊清單中：

mokutil --list-enrolled

使用 mokutil 匯入 DER 憑證並列出待處理的 MOK 條目的範例終端序列 — 導入操作會將憑證加入佇列，以便在重新啟動時進行審核；`mokutil --list-new`並顯示待處理的註冊請求。

MokManager 註冊畫面，已選擇“從磁碟註冊金鑰”，並顯示確認提示 — 重新啟動時，MokManager 會顯示金鑰註冊選擇和確認步驟，授權操作員必須批准該步驟。

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通常情況下，`sudo` 比 `sudo` 更可取，insmod因為它能解決模組依賴關係。測試驅動程式提供的實際設備或功能；僅憑命令成功並不能證明硬體運作正常。如果模組需要在啟動時加載，請將其模組名稱單獨添加到類似 `.slesforce.conf` 的檔案中/etc/modules-load.d/acme_driver.conf。 SLES 使用 systemd 的模組載入機制來處理這些設定檔。

以下範例終端命令用於在目前核心額外目錄中安裝已簽名模組、運行 depmod 並呼叫 modprobe。 — 在匹配的核心版本下安裝已簽署的模組，重新建構依賴關係訊息，然後使用`modprobe`.

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在安全啟動仍啟用的情況下成功註冊，並進行核心日誌檢查和裝置功能檢查，才是更有力的證據。圖中顯示的終端輸出僅為命令範例和說明性輸出，並非本文測試報告。

症狀	需要檢查什麼
`Key was rejected by service`或與簽名相關的載入錯誤	確認簽署此模組的憑證已註冊`mokutil --list-enrolled`；確認模組是在上次修改後簽署的；審核`journalctl -k -b`。
`Invalid module format`	將模組`vermagic`與`uname -r`. 進行比較，並針對正在運行的核心及其版本重新建置。
`Unknown symbol`或未解決的依賴關係	檢查匹配的建置環境和所需的配套模組；`depmod -a`安裝後重新運行。
`Module not found`	檢查檔案名稱、模組名、核心特定的目標目錄和依賴關係圖。傳遞給 `.` 的名稱`modprobe`通常會省略 `.` `.ko`。

SUSE 也會追蹤模組是否受支持，而載入不支援的模組可能會影響核心的支援狀態或污點狀態。此策略與簽章驗證無關：變更不支援的模組設定不會註冊簽章金鑰，也不會修復被拒絕的簽章。在受支援的生產系統上變更此策略之前，請查閱 SUSE 的支援指南。

範例終端檢查顯示了已註冊的 MOK、模組簽署者元資料以及 lsmod 中的模組名稱。 — 結合使用已註冊金鑰清單、簽署者元資料、已載入模組清單和核心日誌；沒有哪一項檢查能夠證明整個信任和相容性鏈。

制定核心更新和重複部署計劃

為某個核心版本建構的模組不會自動與下一個核心版本相容。核心更新後，請安裝匹配的建置環境，針對新的核心ABI重新建置模組，對最終檔案進行簽名，將其安裝到該核心的模組樹中，並更新其依賴項資訊。如果簽名憑證仍然受信任，通常無需重新註冊。但替換或輪換的證書則需要重新註冊和批准。在依賴無人值守的啟動時載入之前，請務必先測試新核心和模組的兼容性。

對於需要定期更新的車隊或驅動程序，如果 SUSE 的核心模組包 (KMP) 方法符合您的驅動程式和支援模型，請使用可重複的打包工作流程。打包可以組織每個核心的建置和簽署步驟，但並不能取代正確的金鑰保護、模組相容性、MOK 信任和更新測試。請參閱文檔，以了解特定的 SLES 15 服務包以及您組織支援的核心生命週期。