======== 概要

Question 1

セキュアブートを無効にするか、カーネルモジュールに署名します。

個人的には、BIOS でセキュアブートを無効にします。

見るhttps://wiki.ubuntu.com/セキュリティチーム/セキュアブート

またはカーネルモジュールを手動で署名するには、

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
コンテンツ

概要。

モジュール署名を構成します。

署名キーを生成しています。

カーネル内の公開鍵。

モジュールに手動で署名します。

署名されたモジュールとストリップ。

署名されたモジュールを読み込んでいます。

有効でない署名と署名されていないモジュール。

秘密鍵の管理/保護。

======== 概要

カーネルモジュール署名機能は、インストール中にモジュールを暗号的に署名し、モジュールのロード時に署名をチェックします。これにより、署名されていないモジュールや無効なキーで署名されたモジュールのロードを禁止することで、カーネルのセキュリティを強化できます。モジュール署名により、悪意のあるモジュールをカーネルにロードすることが困難になるため、セキュリティが強化されます。モジュール署名のチェックはカーネルによって行われるため、信頼できるユーザー空間ビットは必要ありません。

この機能は、関連する公開キーをエンコードするために X.509 ITU-T 標準証明書を使用します。署名自体は、業界標準タイプでエンコードされていません。この機能は現在、RSA 公開キー暗号化標準のみをサポートしています (ただし、プラグ可能であり、他の暗号化標準も使用できます)。使用可能なハッシュアルゴリズムは、SHA-1、SHA-224、SHA-256、SHA-384、および SHA-512 です (アルゴリズムは署名内のデータによって選択されます)。

============================ モジュール署名の設定

モジュール署名機能は、カーネル構成の「ロード可能モジュールサポートを有効にする」セクションに移動し、

CONFIG_MODULE_SIG 「モジュール署名の検証」

これにはいくつかのオプションがあります:

(1) 「モジュールは有効な署名を必要とする」(CONFIG_MODULE_SIG_FORCE)
 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.
（２）「すべてのモジュールに自動的に署名する」（CONFIG_MODULE_SIG_ALL）
 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:
スクリプト/署名ファイル

（３）「モジュールはどのハッシュアルゴリズムで署名すべきか？」
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 「モジュールを SHA-1 で署名する」 CONFIG_MODULE_SIG_SHA224 「モジュールを SHA-224 で署名する」 CONFIG_MODULE_SIG_SHA256 「モジュールを SHA-256 で署名する」 CONFIG_MODULE_SIG_SHA384 「モジュールを SHA-384 で署名する」 CONFIG_MODULE_SIG_SHA512 「モジュールを SHA-512 で署名する」
 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.
(4) 「モジュール署名キーのファイル名またはPKCS#11 URI」(CONFIG_MODULE_SIG_KEY)
 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.
(5) 「デフォルトのシステムキーリング用の追加X.509キー」(CONFIG_SYSTEM_TRUSTED_KEYS)
 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.
モジュール署名を有効にすると、署名を行うツールのカーネルビルドプロセスに OpenSSL 開発パッケージへの依存関係が追加されることに注意してください。

========================= 署名キーの生成

署名の生成と確認には、暗号化キーペアが必要です。署名の生成には秘密キーが使用され、署名の確認には対応する公開キーが使用されます。秘密キーはビルド時にのみ必要で、その後は削除するか、安全に保管することができます。公開キーはカーネルに組み込まれ、モジュールのロード時に署名の確認に使用できます。

通常の状況では、CONFIG_MODULE_SIG_KEY がデフォルトから変更されていない場合、カーネルビルドは、ファイルにキーペアが存在しない場合は openssl を使用して新しいキーペアを自動的に生成します。

証明書/署名キー.pem

vmlinux のビルド中 (キーの公開部分を vmlinux に組み込む必要があります) に、次のパラメータを使用します。

証明書/x509.genkey

ファイル（まだ存在しない場合は生成されます）。

独自の x509.genkey ファイルを提供することを強くお勧めします。

特に注目すべきは、x509.genkey ファイル内の req_distinguished_name セクションをデフォルトから変更する必要があることです。

[ req_distinguished_name ] #O = 未指定の会社 CN = ビルド時に自動生成されたカーネルキー #emailAddress = [メールアドレス]

生成される RSA キーのサイズは、次のように設定することもできます。

[ 必須 ] デフォルトビット = 4096

Linux カーネルソースツリーのルートノードにある x509.genkey キー生成構成ファイルと openssl コマンドを使用して、キーのプライベート/パブリックファイルを手動で生成することもできます。次に、パブリック/プライベートキーファイルを生成する例を示します。

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem

生成された kernel_key.pem ファイルの完全なパス名は、CONFIG_MODULE_SIG_KEY オプションで指定でき、自動生成されたキーペアの代わりに、その中の証明書とキーが使用されます。

=========================== カーネル内の公開鍵

カーネルには、ルートが閲覧できる公開鍵のリングが含まれています。これらは「.system_keyring」というキーリングにあり、次の方法で閲覧できます。

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 asymmetri Fedora カーネル署名キー: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

モジュール署名用に特別に生成された公開キー以外に、CONFIG_SYSTEM_TRUSTED_KEYS 構成オプションによって参照される PEM エンコードファイルで追加の信頼できる証明書を提供できます。

さらに、アーキテクチャコードはハードウェアストアから公開キーを取得し、それらを (たとえば、UEFI キーデータベースから) 追加することもあります。

最後に、以下の手順で追加の公開鍵を追加することができます。

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

例えば：

keyctl padd 非対称 "" 0x223c7853
ただし、カーネルは.system_keyringへのキーの追加のみを許可することに注意してください。もし新しいキーの X.509 ラッパーは、キーが追加された時点で .system_keyring にすでに存在するキーによって有効に署名されています。

=========================== モジュールの手動署名

モジュールに手動で署名するには、Linux カーネルソースツリーで利用可能な scripts/sign-file ツールを使用します。スクリプトには 4 つの引数が必要です。

ハッシュアルゴリズム（例：sha256）

秘密鍵のファイル名またはPKCS#11 URI

公開鍵ファイル名

署名するカーネルモジュール

以下はカーネルモジュールに署名する例です。

スクリプト/署名ファイル sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

使用されるハッシュアルゴリズムは、構成されているものと一致する必要はありませんが、一致しない場合は、ハッシュアルゴリズムがカーネルに組み込まれているか、またはそれ自体を必要とせずにロードできることを確認する必要があります。

秘密鍵にパスフレーズまたは PIN が必要な場合は、$KBUILD_SIGN_PIN 環境変数で指定できます。

============================== 署名されたモジュールとストリッピング

署名されたモジュールには、末尾にデジタル署名が単純に追加されています。モジュールファイルの末尾にある文字列「~モジュール署名が追加されました~」は、署名が存在することの確認ですが、署名が有効であることの確認ではありません。

署名されたモジュールは、署名が定義された ELF コンテナの外部にあるため、脆弱です。したがって、署名が計算され添付された後は、署名されたモジュールを削除することはできません。署名されたペイロードはモジュール全体であり、署名時に存在するすべてのデバッグ情報も含まれることに注意してください。

======================= 署名されたモジュールの読み込み

モジュールは、署名されていないモジュールとまったく同じように、insmod、modprobe、init_module()、または finit_module() を使用してロードされます。ユーザー空間では処理は行われません。署名のチェックはすべてカーネル内で行われます。

=========================================== 無効な署名と署名されていないモジュール

CONFIG_MODULE_SIG_FORCE が有効になっているか、カーネルのコマンドラインで module.sig_enforce=1 が指定されている場合、カーネルは公開鍵を持つ有効な署名付きモジュールのみをロードします。それ以外の場合は、署名されていないモジュールもロードします。カーネルが鍵を持っているが、署名が一致しないことが判明したモジュールは、ロードが許可されません。

解析できない署名を持つモジュールはすべて拒否されます。

============================================ 秘密鍵の管理/保護

秘密鍵はモジュールの署名に使用されるため、ウイルスやマルウェアが秘密鍵を使用してモジュールに署名し、オペレーティングシステムを侵害する可能性があります。秘密鍵は破棄するか、安全な場所に移動し、カーネルソースツリーのルートノードに保存しないでください。

Answer

セキュアブートを無効にするか、カーネルモジュールに署名します。

個人的には、BIOS でセキュアブートを無効にします。

見るhttps://wiki.ubuntu.com/セキュリティチーム/セキュアブート

またはカーネルモジュールを手動で署名するには、

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
コンテンツ

概要。

モジュール署名を構成します。

署名キーを生成しています。

カーネル内の公開鍵。

モジュールに手動で署名します。

署名されたモジュールとストリップ。

署名されたモジュールを読み込んでいます。

有効でない署名と署名されていないモジュール。

秘密鍵の管理/保護。

======== 概要

カーネルモジュール署名機能は、インストール中にモジュールを暗号的に署名し、モジュールのロード時に署名をチェックします。これにより、署名されていないモジュールや無効なキーで署名されたモジュールのロードを禁止することで、カーネルのセキュリティを強化できます。モジュール署名により、悪意のあるモジュールをカーネルにロードすることが困難になるため、セキュリティが強化されます。モジュール署名のチェックはカーネルによって行われるため、信頼できるユーザー空間ビットは必要ありません。

この機能は、関連する公開キーをエンコードするために X.509 ITU-T 標準証明書を使用します。署名自体は、業界標準タイプでエンコードされていません。この機能は現在、RSA 公開キー暗号化標準のみをサポートしています (ただし、プラグ可能であり、他の暗号化標準も使用できます)。使用可能なハッシュアルゴリズムは、SHA-1、SHA-224、SHA-256、SHA-384、および SHA-512 です (アルゴリズムは署名内のデータによって選択されます)。

============================ モジュール署名の設定

モジュール署名機能は、カーネル構成の「ロード可能モジュールサポートを有効にする」セクションに移動し、

CONFIG_MODULE_SIG 「モジュール署名の検証」

これにはいくつかのオプションがあります:

(1) 「モジュールは有効な署名を必要とする」(CONFIG_MODULE_SIG_FORCE)
 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.
（２）「すべてのモジュールに自動的に署名する」（CONFIG_MODULE_SIG_ALL）
 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:
スクリプト/署名ファイル

（３）「モジュールはどのハッシュアルゴリズムで署名すべきか？」
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 「モジュールを SHA-1 で署名する」 CONFIG_MODULE_SIG_SHA224 「モジュールを SHA-224 で署名する」 CONFIG_MODULE_SIG_SHA256 「モジュールを SHA-256 で署名する」 CONFIG_MODULE_SIG_SHA384 「モジュールを SHA-384 で署名する」 CONFIG_MODULE_SIG_SHA512 「モジュールを SHA-512 で署名する」
 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.
(4) 「モジュール署名キーのファイル名またはPKCS#11 URI」(CONFIG_MODULE_SIG_KEY)
 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.
(5) 「デフォルトのシステムキーリング用の追加X.509キー」(CONFIG_SYSTEM_TRUSTED_KEYS)
 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.
モジュール署名を有効にすると、署名を行うツールのカーネルビルドプロセスに OpenSSL 開発パッケージへの依存関係が追加されることに注意してください。

========================= 署名キーの生成

署名の生成と確認には、暗号化キーペアが必要です。署名の生成には秘密キーが使用され、署名の確認には対応する公開キーが使用されます。秘密キーはビルド時にのみ必要で、その後は削除するか、安全に保管することができます。公開キーはカーネルに組み込まれ、モジュールのロード時に署名の確認に使用できます。

通常の状況では、CONFIG_MODULE_SIG_KEY がデフォルトから変更されていない場合、カーネルビルドは、ファイルにキーペアが存在しない場合は openssl を使用して新しいキーペアを自動的に生成します。

証明書/署名キー.pem

vmlinux のビルド中 (キーの公開部分を vmlinux に組み込む必要があります) に、次のパラメータを使用します。

証明書/x509.genkey

ファイル（まだ存在しない場合は生成されます）。

独自の x509.genkey ファイルを提供することを強くお勧めします。

特に注目すべきは、x509.genkey ファイル内の req_distinguished_name セクションをデフォルトから変更する必要があることです。

[ req_distinguished_name ] #O = 未指定の会社 CN = ビルド時に自動生成されたカーネルキー #emailAddress = [メールアドレス]

生成される RSA キーのサイズは、次のように設定することもできます。

[ 必須 ] デフォルトビット = 4096

Linux カーネルソースツリーのルートノードにある x509.genkey キー生成構成ファイルと openssl コマンドを使用して、キーのプライベート/パブリックファイルを手動で生成することもできます。次に、パブリック/プライベートキーファイルを生成する例を示します。

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem

生成された kernel_key.pem ファイルの完全なパス名は、CONFIG_MODULE_SIG_KEY オプションで指定でき、自動生成されたキーペアの代わりに、その中の証明書とキーが使用されます。

=========================== カーネル内の公開鍵

カーネルには、ルートが閲覧できる公開鍵のリングが含まれています。これらは「.system_keyring」というキーリングにあり、次の方法で閲覧できます。

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 asymmetri Fedora カーネル署名キー: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

モジュール署名用に特別に生成された公開キー以外に、CONFIG_SYSTEM_TRUSTED_KEYS 構成オプションによって参照される PEM エンコードファイルで追加の信頼できる証明書を提供できます。

さらに、アーキテクチャコードはハードウェアストアから公開キーを取得し、それらを (たとえば、UEFI キーデータベースから) 追加することもあります。

最後に、以下の手順で追加の公開鍵を追加することができます。

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

例えば：

keyctl padd 非対称 "" 0x223c7853
ただし、カーネルは.system_keyringへのキーの追加のみを許可することに注意してください。もし新しいキーの X.509 ラッパーは、キーが追加された時点で .system_keyring にすでに存在するキーによって有効に署名されています。

=========================== モジュールの手動署名

モジュールに手動で署名するには、Linux カーネルソースツリーで利用可能な scripts/sign-file ツールを使用します。スクリプトには 4 つの引数が必要です。

ハッシュアルゴリズム（例：sha256）

秘密鍵のファイル名またはPKCS#11 URI

公開鍵ファイル名

署名するカーネルモジュール

以下はカーネルモジュールに署名する例です。

スクリプト/署名ファイル sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

使用されるハッシュアルゴリズムは、構成されているものと一致する必要はありませんが、一致しない場合は、ハッシュアルゴリズムがカーネルに組み込まれているか、またはそれ自体を必要とせずにロードできることを確認する必要があります。

秘密鍵にパスフレーズまたは PIN が必要な場合は、$KBUILD_SIGN_PIN 環境変数で指定できます。

============================== 署名されたモジュールとストリッピング

署名されたモジュールには、末尾にデジタル署名が単純に追加されています。モジュールファイルの末尾にある文字列「~モジュール署名が追加されました~」は、署名が存在することの確認ですが、署名が有効であることの確認ではありません。

署名されたモジュールは、署名が定義された ELF コンテナの外部にあるため、脆弱です。したがって、署名が計算され添付された後は、署名されたモジュールを削除することはできません。署名されたペイロードはモジュール全体であり、署名時に存在するすべてのデバッグ情報も含まれることに注意してください。

======================= 署名されたモジュールの読み込み

モジュールは、署名されていないモジュールとまったく同じように、insmod、modprobe、init_module()、または finit_module() を使用してロードされます。ユーザー空間では処理は行われません。署名のチェックはすべてカーネル内で行われます。

=========================================== 無効な署名と署名されていないモジュール

CONFIG_MODULE_SIG_FORCE が有効になっているか、カーネルのコマンドラインで module.sig_enforce=1 が指定されている場合、カーネルは公開鍵を持つ有効な署名付きモジュールのみをロードします。それ以外の場合は、署名されていないモジュールもロードします。カーネルが鍵を持っているが、署名が一致しないことが判明したモジュールは、ロードが許可されません。

解析できない署名を持つモジュールはすべて拒否されます。

============================================ 秘密鍵の管理/保護

秘密鍵はモジュールの署名に使用されるため、ウイルスやマルウェアが秘密鍵を使用してモジュールに署名し、オペレーティングシステムを侵害する可能性があります。秘密鍵は破棄するか、安全な場所に移動し、カーネルソースツリーのルートノードに保存しないでください。

Question 2

私も同じドライバーの読み込みの問題が発生しました。grub module.sig_enforce=0Linux カーネルのコマンドラインを単純に渡しました。

手順は次のとおりです。

カーネルブートパラメータを永続的に追加する

システムにログインし、ターミナルウィンドウを起動します（アプリケーション→アクセサリー→ターミナル）。
プロンプトで$次のコマンドを入力します。
```
sudo gedit /etc/default/grub
```
プロンプトが表示されたらパスワードを入力します[sudo]。

ファイルが/etc/default/grub空であるか存在しない場合は、上記の以前のリリースの手順を参照してください。

エディターウィンドウで、矢印キーを使用してカーソルをで始まる行に移動し、GRUB_CMDLINE_LINUX_DEFAULTその行を編集して、という単語の後の二重引用符内のテキストにパラメータを追加しますquiet splash。を追加しました。(新しいパラメータを追加する前に、module.sig_enforce=0必ずの後にスペースを追加してください。)splash
クリック保存ボタン
エディターウィンドウを閉じます。
ターミナルウィンドウのプロンプトで$、次のように入力します。
```
sudo update-grub
```
システムを再起動します。

モジュールをロードしてみると、うまくいきました。

Answer

私も同じドライバーの読み込みの問題が発生しました。grub module.sig_enforce=0Linux カーネルのコマンドラインを単純に渡しました。

手順は次のとおりです。

カーネルブートパラメータを永続的に追加する

システムにログインし、ターミナルウィンドウを起動します（アプリケーション→アクセサリー→ターミナル）。
プロンプトで$次のコマンドを入力します。
```
sudo gedit /etc/default/grub
```
プロンプトが表示されたらパスワードを入力します[sudo]。

ファイルが/etc/default/grub空であるか存在しない場合は、上記の以前のリリースの手順を参照してください。

エディターウィンドウで、矢印キーを使用してカーソルをで始まる行に移動し、GRUB_CMDLINE_LINUX_DEFAULTその行を編集して、という単語の後の二重引用符内のテキストにパラメータを追加しますquiet splash。を追加しました。(新しいパラメータを追加する前に、module.sig_enforce=0必ずの後にスペースを追加してください。)splash
クリック保存ボタン
エディターウィンドウを閉じます。
ターミナルウィンドウのプロンプトで$、次のように入力します。
```
sudo update-grub
```
システムを再起動します。

モジュールをロードしてみると、うまくいきました。

Question 3

Ubuntu 16.04 は、PCI ドライバーの構築に pci_dma_supported ではなく pci_set_dma_mask をサポートしています。間違った API を使用すると、ドライバーのロード時にセキュアブートキーの不一致エラーが表示されます。

Answer

Ubuntu 16.04 は、PCI ドライバーの構築に pci_dma_supported ではなく pci_set_dma_mask をサポートしています。間違った API を使用すると、ドライバーのロード時にセキュアブートキーの不一致エラーが表示されます。

Question 4

カーネル v5.4 では、フラグを無効にしMODULE_SIG_FORCEてからカーネルを再構築できます。

Answer

カーネル v5.4 では、フラグを無効にしMODULE_SIG_FORCEてからカーネルを再構築できます。

======== 概要

答え1

======== 概要

============================ モジュール署名の設定

========================= 署名キーの生成

=========================== カーネル内の公開鍵

=========================== モジュールの手動署名

============================== 署名されたモジュールとストリッピング

======================= 署名されたモジュールの読み込み

=========================================== 無効な署名と署名されていないモジュール

============================================ 秘密鍵の管理/保護

答え2

答え3

答え4

関連情報