在 SLES 15 安全啟動上安裝和簽署自訂核心模組

在 SUSE Linux Enterprise Server 15 上，第三方驅動程式可能編譯正確，但載入失敗，並顯示「所需金鑰無法使用」或「服務拒絕金鑰」的錯誤訊息。當 UEFI 安全啟動強制執行模組簽名時，解決方法是使用受信任的證書對自訂核心模組進行簽名，透過機器所有者金鑰 (MOK) 管理註冊該證書，然後正常載入模組——無需停用安全啟動。

本教學假設您使用的是標準的 SLES 15 UEFI 系統，並已安裝 SUSE shim、kernel-default內核，且擁有管理員權限，驅動程式來源可靠。本教學僅針對自訂.ko模組，不涉及內核簽章或韌體平台金鑰變更。範例遵循 SLES 15 SP6/SP7 管理模型；請檢查您已安裝的服務包的軟體包和核心版本差異。

1. 首先檢查安全啟動和正在運行的核心。

使用管理員權限登錄，並確定您實際啟動的核心。僅憑軟體包名稱匹配並不能證明某個模組可以載入到該核心中。

uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"

如果mokutil報告顯示已啟用安全啟動，則金鑰相關的載入失敗很可能是由於簽章不受信任造成的。如果安全啟動已停用，請在產生金鑰之前調查其他原因；顯式核心簽章強制執行也可能起作用。載入失敗後，請檢查核心日誌以取得實際的拒絕訊息。

sudo journalctl -k -b --no-pager | tail -n 50

安裝候選模組前請先檢查它。請將範例中的檔案名稱替換為實際檔案名稱；實際檔案名稱vermagic應與正在執行的核心版本和相容的建置屬性相符。

modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko

2. 使用受支援的驅動程式套件或建構匹配的模組

首先向硬體或軟體供應商索取與 SLES 相容且已簽署的核心模組包 (KMP)。這比手動安裝二進位檔案更可取：供應商可能提供核心更新處理和文件化的憑證註冊流程。並非所有安全啟動機器都會自動信任供應商簽署。

如果必須自行編譯驅動程序，請安裝與目前運行核心相符的開發檔案。通常kernel-default，SLES 軟體包包含預設核心開發套件、核心開發檔案和編譯工具。軟體倉庫的可用性和版本取決於註冊情況和已啟用的 SLES 模組。

sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"

如果建置目錄缺失或開發包針對的是不同的核心版本，請先修復軟體包/核心不符的問題。新安裝的核心可能需要在建置之前進行受控重啟。

從可信任驅動程式來源目錄中，使用供應商提供的建置說明。對於傳統的基於 kbuild 的模組，以下命令會針對正在運行的核心進行建置；它本身不會下載或建立驅動程式。

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules

如果您已經從可信任供應商獲得了相容版本，則無需編譯.ko。切勿強制載入錯誤的模組vermagic；簽章無法修復不相容的二進位檔案。

3. 建立簽名金鑰並對已安裝的模組進行簽名

在僅限根使用者存取的目錄中產生專用的 RSA 金鑰和 X.509 憑證。公鑰憑證將被註冊；私鑰必須受到保護，因為控制私鑰的人可以簽署此機器可能信任的其他模組。

sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
  -subj "/CN=SLES Custom Module Signing/" \
  -keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv

-nodes這裡僅提供一個簡單的範例，建立一個未加密的私密金鑰；對於生產環境的簽章流程，請根據安全策略使用適當保護的加密金鑰或外部簽章服務。此處顯示的十年有效期僅為示例，並非組織機構的證書有效期建議。

將完成的模組複製到正在運行的核心的模組目錄中。在進行任何打包、剝離或其他文件修改後，對已安裝的文件進行簽署。將 `<module_name>`mydriver及其路徑替換為模組的實際基本名稱和位置。

install -D -m 0644 /path/to/mydriver.ko \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
  /root/module-signing/MOK.der \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"

如果sign-file該路徑下沒有該工具，請尋找與您的核心建置檔案相符的工具，而不是複製不相關的版本。顯示的簽署者表示該文件包含簽章元資料；但這並未證明簽章者已註冊。簽名後切勿剝離或修改模組。

4. 使用 MOK 註冊公共證書

匯入 DER 格式的公鑰憑證（而非其他憑證），MOK.priv並設定一次性註冊密碼mokutil。重新啟動前安排好控制台存取權限；授權是在啟動時的 MokManager 介面中進行的，而不是在 SSH shell 中進行的。

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot

下次啟動時，選擇「註冊 MOK」，依照確認提示操作，輸入一次性密碼，然後繼續啟動。選單顯示取決於韌體和 shim 版本。如果未確認註冊就回傳 Linux，則新憑證將處於不受信任狀態。

啟動後，驗證特定證書是否已註冊：

sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled

5. 載入已簽署的模組並隔離剩餘錯誤

更新模組依賴元數據，並按模組名稱而非完整檔案路徑載入模組。modprobe解析依賴關係並遵循標準模組配置。

sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver

如果載入仍然失敗，請選擇與證據相符的糾正措施：

• 金鑰被拒絕或所需金鑰不可用：重新運行mokutil --test-key；確認您安裝的文件是已簽署的文件，並檢查驅動程式更新是否已將其替換。
• 模組格式無效：modinfo -F vermagic請與目前核心進行比較uname -r，重新建置目前內核，並檢查 CPU 架構。
• 未知符號或缺少依賴項：檢查journalctl -k -b供應商所需的模組和內核 ABI；其他簽名無法修復缺少的符號。

對於啟動關鍵型儲存或網路驅動程序，請先在非生產系統上進行測試，並確保恢復控制台可用。僅在驅動程式運作穩定可靠後才配置自動載入；SUSE 文件/etc/modules-load.d/中列出了在裝置偵測到時不會自動載入的模組。

重啟後驗證結果

如果持續載入至關重要，請在維護視窗期間再次重新啟動。確認安全啟動仍然啟用、公鑰已註冊、模組存在，且核心沒有報告新的驗證或相容性錯誤。.ko核心或供應商驅動程式升級後，重新建置或重新安裝並簽署更新後的程式。

mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30

主要文件： SUSE SLES 15 SP6：UEFI 和機器所有者金鑰；SUSE：管理核心模組；Linux 核心：模組簽署工具；Linux 核心：建立外部模組。 《SLES 15 SP6 管理指南》已於 2026 年 9 月 17 日更新；第三方驅動程式安裝程式和非預設核心版本的命令行為必須與它們的維護者確認。