在 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"
終端機顯示 uname -r、mokutil 安全啟動狀態以及正在執行的核心建置目錄的檢查結果
在安裝或簽署驅動程式之前,請檢查目前核心版本和安全啟動狀態。

如果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
終端顯示外部核心驅動程式和核心簽章工具路徑的範例 modinfo 列表
檢查模組元數據,特別是 vermagic,而不是假設任何 .ko 檔案都與 SLES 15 相符。

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"
SLES 風格的終端顯示了 zypper 安裝核心開發和簽名先決條件的過程
在使用自訂模組之前,請先安裝相符的核心開發包和加密工具。

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

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

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules
終端顯示 kbuild make 指令正在針對正在執行的 SLES 核心編譯外部核心模組。
使用核心建構樹和驅動程式原始碼目錄產生匹配的 .ko 檔案。

如果您已經從可信任供應商獲得了相容版本,則無需編譯.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
終端機顯示 OpenSSL 指令正在建立本機 RSA 私鑰和 X.509 模組簽章憑證
產生單獨的模組簽署金鑰對,並將私鑰限制為管理員所有。

-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"
終端顯示了核心模組的範例簽名檔案呼叫和 modinfo 簽名器檢查
將簽名套用至已安裝的 .ko 文件,並在載入之前檢查其簽署者欄位。

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

4. 使用 MOK 註冊公共證書

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

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot
藍色 MokManager 風格的啟動選單,其中「註冊 MOK」選項高亮顯示,高於其他機器所有者金鑰選項。
在 UEFI 啟動時功能表中,選擇「註冊 MOK」並確認要求的憑證註冊。

下次啟動時,選擇「註冊 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
終端顯示用於檢查已簽名模組的 modprobe、lsmod 和 kernel-log 命令
確認已簽署的模組出現在已載入模組清單中,並檢查核心日誌是否有錯誤。

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

  • 金鑰被拒絕或所需金鑰不可用:重新運行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 日更新;第三方驅動程式安裝程式和非預設核心版本的命令行為必須與它們的維護者確認。

留下評論

診斷卡在 systemd 關閉螢幕的 SUSE 伺服器

診斷卡在 systemd 關閉螢幕的 SUSE 伺服器

使用 systemd 作業和先前的啟動日誌來尋找運行緩慢的服務、掛載點或儲存依賴項,然後修正它,而不掩蓋原因。

僅開放 SLES 15 伺服器所需的網路流量

僅開放 SLES 15 伺服器所需的網路流量

使用 firewall-cmd 檢查活動區域,安全地允許 HTTP,保留 SSH 訪問,並驗證該規則在 SLES 15 上重新加載後是否仍然存在。

診斷 SLES PAM 登入失敗問題,避免被鎖定

診斷 SLES PAM 登入失敗問題,避免被鎖定

追溯 PAM 故障到其服務、帳戶原則或身分提供者,然後在保持管理員會話正常運作的情況下修復正確的 SLES 配置。

在 ONLYOFFICE 文件伺服器中新增字型:Docker 與 Linux

在 ONLYOFFICE 文件伺服器中新增字型:Docker 與 Linux

在 ONLYOFFICE 文件伺服器中安裝自訂字體,比較持久 Docker 掛載與直接複製,重建字體列表,並驗證結果。

使用 Restic 和 Cron 實現 Nextcloud 的自動化和一致性備份

使用 Restic 和 Cron 實現 Nextcloud 的自動化和一致性備份

將 Nextcloud 的檔案和 MariaDB 一起備份,使用 cron 安排加密的 Restic 快照,並在不危及執行伺服器的情況下驗證復原。

使用 TGZ Exports 備份和還原 Zimbra CE 郵箱

使用 TGZ Exports 備份和還原 Zimbra CE 郵箱

匯出單一 Zimbra Community Edition 信箱,驗證其 TGZ 備份,並在不覆寫現有郵件的情況下還原遺失的項目。

允許已批准的使用者使用 Keycloak 登入建立 Jitsi 會議室

允許已批准的使用者使用 Keycloak 登入建立 Jitsi 會議室

僅允許已批准的帳戶使用 Keycloak 和令牌身份驗證啟動 Jitsi Meet 會議室,同時在需要時允許訪客加入。

透過 LDAP 將 Active Directory 使用者與 ONLYOFFICE DocSpace 同步。

透過 LDAP 將 Active Directory 使用者與 ONLYOFFICE DocSpace 同步。

將 ONLYOFFICE DocSpace 連接到 Active Directory 或 OpenLDAP,安全地匯入使用者和群組,映射帳戶字段,並安排可靠的同步。

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

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

在不停用安全啟動的情況下載入自訂 SLES 15 核心模組。匹配正在運行的內核,對 .ko 檔案進行簽名,註冊 MOK 金鑰,並驗證載入情況。

將 ONLYOFFICE Docs 置於 HAProxy 之後而不影響編輯功能

將 ONLYOFFICE Docs 置於 HAProxy 之後而不影響編輯功能

為 ONLYOFFICE Docs 設定 HAProxy HTTPS、轉送標頭、WebSocket 逾時和執行狀況檢查,然後驗證編輯和儲存功能。