======== ÜBERBLICK

Question 1

Sie deaktivieren entweder den sicheren Start oder signieren das Kernelmodul.

Ich persönlich deaktiviere den sicheren Start im BIOS.

Sehenhttps://wiki.ubuntu.com/SecurityTeam/SecureBoot

Oder um das Kernelmodul manuell zu signieren, siehe

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

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
INHALT

Überblick.

Modulsignierung konfigurieren.

Signaturschlüssel generieren.

Öffentliche Schlüssel im Kernel.

Module manuell signieren.

Signierte Module und Stripping.

Signierte Module werden geladen.

Ungültige Signaturen und nicht signierte Module.

Verwalten/Schützen des privaten Schlüssels.

======== ÜBERBLICK

Die Kernelmodul-Signaturfunktion signiert Module während der Installation kryptografisch und überprüft dann die Signatur beim Laden des Moduls. Dies ermöglicht eine erhöhte Kernelsicherheit, indem das Laden von nicht signierten oder mit einem ungültigen Schlüssel signierten Modulen unterbunden wird. Die Modulsignatur erhöht die Sicherheit, indem es schwieriger wird, ein bösartiges Modul in den Kernel zu laden. Die Überprüfung der Modulsignatur wird vom Kernel durchgeführt, sodass keine vertrauenswürdigen Userspace-Bits erforderlich sind.

Diese Einrichtung verwendet X.509 ITU-T-Standardzertifikate, um die beteiligten öffentlichen Schlüssel zu verschlüsseln. Die Signaturen selbst sind nicht in einem Industriestandardtyp kodiert. Die Einrichtung unterstützt derzeit nur den RSA-Public-Key-Verschlüsselungsstandard (obwohl er steckbar ist und die Verwendung anderer zulässt). Die möglichen Hash-Algorithmen, die verwendet werden können, sind SHA-1, SHA-224, SHA-256, SHA-384 und SHA-512 (der Algorithmus wird durch Daten in der Signatur ausgewählt).

============================ MODULSIGNIERUNG KONFIGURIEREN

Die Modulsignaturfunktion wird aktiviert, indem Sie in der Kernelkonfiguration zum Abschnitt "Enable Loadable Module Support" gehen und

CONFIG_MODULE_SIG "Modulsignaturüberprüfung"

Dafür stehen mehrere Optionen zur Verfügung:

(1) „Module müssen gültig signiert sein“ (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.
(2) „Alle Module automatisch signieren“ (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:
Skripte/Signaturdatei

(3) "Mit welchem Hash-Algorithmus sollen Module signiert werden?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 „Module mit SHA-1 signieren“ CONFIG_MODULE_SIG_SHA224 „Module mit SHA-224 signieren“ CONFIG_MODULE_SIG_SHA256 „Module mit SHA-256 signieren“ CONFIG_MODULE_SIG_SHA384 „Module mit SHA-384 signieren“ CONFIG_MODULE_SIG_SHA512 „Module mit SHA-512 signieren“
 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) „Dateiname oder PKCS#11-URI des Modulsignaturschlüssels“ (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) „Zusätzliche X.509-Schlüssel für den Standard-Systemschlüsselbund“ (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.
Beachten Sie, dass durch die Aktivierung der Modulsignierung eine Abhängigkeit von den OpenSSL-Entwicklungspaketen zu den Kernel-Build-Prozessen für das Tool hinzugefügt wird, das die Signierung durchführt.

======================== SIGNIERSCHLÜSSEL GENERIEREN

Zum Generieren und Überprüfen von Signaturen werden kryptografische Schlüsselpaare benötigt. Ein privater Schlüssel wird zum Generieren einer Signatur verwendet und der entsprechende öffentliche Schlüssel wird zum Überprüfen der Signatur verwendet. Der private Schlüssel wird nur während des Builds benötigt. Danach kann er gelöscht oder sicher gespeichert werden. Der öffentliche Schlüssel wird in den Kernel integriert, sodass er zum Überprüfen der Signaturen beim Laden der Module verwendet werden kann.

Unter normalen Umständen wird bei unverändertem CONFIG_MODULE_SIG_KEY gegenüber dem Standardwert der Kernel-Build automatisch ein neues Schlüsselpaar mit OpenSSL generiert, wenn in der Datei keins vorhanden ist:

zertifikate/signing_key.pem

während des Erstellens von vmlinux (der öffentliche Teil des Schlüssels muss in vmlinux integriert werden) mithilfe von Parametern im:

zertifikate/x509.genkey

Datei (die ebenfalls generiert wird, falls sie noch nicht vorhanden ist).

Es wird dringend empfohlen, dass Sie Ihre eigene x509.genkey-Datei bereitstellen.

Insbesondere sollte in der Datei x509.genkey der Abschnitt „req_distinguished_name“ gegenüber der Standardeinstellung geändert werden:

[ req_distinguished_name ] #O = Nicht angegebenes Unternehmen CN = Automatisch generierter Kernel-Schlüssel zur Build-Zeit #emailAddress = [email geschützt]

Die generierte RSA-Schlüsselgröße kann auch wie folgt eingestellt werden:

[ erforderlich ] Standardbits = 4096

Es ist auch möglich, die privaten/öffentlichen Schlüsseldateien manuell zu generieren, indem Sie die Schlüsselgenerierungskonfigurationsdatei x509.genkey im Stammknoten des Linux-Kernel-Quellbaums und den Befehl openssl verwenden. Nachfolgend sehen Sie ein Beispiel zum Generieren der öffentlichen/privaten Schlüsseldateien:

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

Der vollständige Pfadname für die resultierende Datei kernel_key.pem kann dann in der Option CONFIG_MODULE_SIG_KEY angegeben werden. Das darin enthaltene Zertifikat und der Schlüssel werden anstelle eines automatisch generierten Schlüsselpaars verwendet.

========================== ÖFFENTLICHE SCHLÜSSEL IM KERNEL

Der Kernel enthält einen Ring öffentlicher Schlüssel, die von Root eingesehen werden können. Sie befinden sich in einem Schlüsselring namens „.system_keyring“, der wie folgt eingesehen werden kann:

[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-Kernel-Signaturschlüssel: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

Über den speziell für die Modulsignierung generierten öffentlichen Schlüssel hinaus können zusätzliche vertrauenswürdige Zertifikate in einer PEM-codierten Datei bereitgestellt werden, auf die die Konfigurationsoption CONFIG_SYSTEM_TRUSTED_KEYS verweist.

Darüber hinaus kann der Architekturcode öffentliche Schlüssel aus einem Hardwarespeicher übernehmen und diese ebenfalls hinzufügen (z. B. aus der UEFI-Schlüsseldatenbank).

Schließlich ist es möglich, zusätzliche öffentliche Schlüssel hinzuzufügen, indem Sie Folgendes tun:

keyctl padd asymmetrisch "" [.system_keyring-ID] <[Schlüsseldatei]

z.B:

keyctl padd asymmetrisch "" 0x223c7853
Beachten Sie jedoch, dass der Kernel nur das Hinzufügen von Schlüsseln zu .system_keyring zulässtWennDer X.509-Wrapper des neuen Schlüssels ist gültig mit einem Schlüssel signiert, der sich zum Zeitpunkt der Hinzufügung des Schlüssels bereits im Systemschlüsselring befindet.

=========================== MODULE MANUELL SIGNIEREN

Um ein Modul manuell zu signieren, verwenden Sie das Tool scripts/sign-file, das im Quellcode des Linux-Kernels verfügbar ist. Das Skript erfordert 4 Argumente:

Der Hash-Algorithmus (z. B. sha256)

Der Dateiname des privaten Schlüssels oder die PKCS#11-URI

Der Dateiname des öffentlichen Schlüssels

Das zu signierende Kernelmodul

Das Folgende ist ein Beispiel zum Signieren eines Kernelmoduls:

Skripte/Signaturdatei sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

Der verwendete Hash-Algorithmus muss nicht mit dem konfigurierten übereinstimmen. Ist dies jedoch nicht der Fall, sollten Sie sicherstellen, dass der Hash-Algorithmus entweder im Kernel integriert ist oder ohne eigenen Bedarf geladen werden kann.

Wenn der private Schlüssel eine Passphrase oder PIN erfordert, kann diese in der Umgebungsvariable $KBUILD_SIGN_PIN bereitgestellt werden.

============================ SIGNIERTE MODULE UND STRIPPEN

Einem signierten Modul wird einfach am Ende eine digitale Signatur angehängt. Die Zeichenfolge „~Modulsignatur angehängt~.“ am Ende der Moduldatei bestätigt, dass eine Signatur vorhanden ist, aber nicht, dass die Signatur gültig ist!

Signierte Module sind BRÜCHTIG, da die Signatur außerhalb des definierten ELF-Containers liegt. Daher dürfen sie NICHT entfernt werden, sobald die Signatur berechnet und angehängt wurde. Beachten Sie, dass das gesamte Modul die signierte Nutzlast ist, einschließlich aller Debuginformationen, die zum Zeitpunkt der Signierung vorhanden sind.

======================= SIGNIERTE MODULE WERDEN GELADEN

Module werden mit insmod, modprobe, init_module() oder finit_module() geladen, genau wie nicht signierte Module, da keine Verarbeitung im Benutzerbereich erfolgt. Die Signaturprüfung erfolgt vollständig im Kernel.

== ...

Wenn CONFIG_MODULE_SIG_FORCE aktiviert ist oder module.sig_enforce=1 in der Kernel-Befehlszeile angegeben wird, lädt der Kernel nur gültig signierte Module, für die er einen öffentlichen Schlüssel hat. Andernfalls lädt er auch unsignierte Module. Module, für die der Kernel einen Schlüssel hat, deren Signatur jedoch nicht übereinstimmt, dürfen nicht geladen werden.

Jedes Modul mit einer nicht analysierbaren Signatur wird abgelehnt.

=========================================== VERWALTUNG/SCHUTZ DES PRIVATEN SCHLÜSSELS

Da der private Schlüssel zum Signieren von Modulen verwendet wird, könnten Viren und Malware den privaten Schlüssel zum Signieren von Modulen verwenden und das Betriebssystem kompromittieren. Der private Schlüssel muss entweder vernichtet oder an einen sicheren Ort verschoben werden und darf nicht im Stammknoten des Kernel-Quellcodebaums aufbewahrt werden.

Answer

Sie deaktivieren entweder den sicheren Start oder signieren das Kernelmodul.

Ich persönlich deaktiviere den sicheren Start im BIOS.

Sehenhttps://wiki.ubuntu.com/SecurityTeam/SecureBoot

Oder um das Kernelmodul manuell zu signieren, siehe

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

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
INHALT

Überblick.

Modulsignierung konfigurieren.

Signaturschlüssel generieren.

Öffentliche Schlüssel im Kernel.

Module manuell signieren.

Signierte Module und Stripping.

Signierte Module werden geladen.

Ungültige Signaturen und nicht signierte Module.

Verwalten/Schützen des privaten Schlüssels.

======== ÜBERBLICK

Die Kernelmodul-Signaturfunktion signiert Module während der Installation kryptografisch und überprüft dann die Signatur beim Laden des Moduls. Dies ermöglicht eine erhöhte Kernelsicherheit, indem das Laden von nicht signierten oder mit einem ungültigen Schlüssel signierten Modulen unterbunden wird. Die Modulsignatur erhöht die Sicherheit, indem es schwieriger wird, ein bösartiges Modul in den Kernel zu laden. Die Überprüfung der Modulsignatur wird vom Kernel durchgeführt, sodass keine vertrauenswürdigen Userspace-Bits erforderlich sind.

Diese Einrichtung verwendet X.509 ITU-T-Standardzertifikate, um die beteiligten öffentlichen Schlüssel zu verschlüsseln. Die Signaturen selbst sind nicht in einem Industriestandardtyp kodiert. Die Einrichtung unterstützt derzeit nur den RSA-Public-Key-Verschlüsselungsstandard (obwohl er steckbar ist und die Verwendung anderer zulässt). Die möglichen Hash-Algorithmen, die verwendet werden können, sind SHA-1, SHA-224, SHA-256, SHA-384 und SHA-512 (der Algorithmus wird durch Daten in der Signatur ausgewählt).

============================ MODULSIGNIERUNG KONFIGURIEREN

Die Modulsignaturfunktion wird aktiviert, indem Sie in der Kernelkonfiguration zum Abschnitt "Enable Loadable Module Support" gehen und

CONFIG_MODULE_SIG "Modulsignaturüberprüfung"

Dafür stehen mehrere Optionen zur Verfügung:

(1) „Module müssen gültig signiert sein“ (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.
(2) „Alle Module automatisch signieren“ (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:
Skripte/Signaturdatei

(3) "Mit welchem Hash-Algorithmus sollen Module signiert werden?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 „Module mit SHA-1 signieren“ CONFIG_MODULE_SIG_SHA224 „Module mit SHA-224 signieren“ CONFIG_MODULE_SIG_SHA256 „Module mit SHA-256 signieren“ CONFIG_MODULE_SIG_SHA384 „Module mit SHA-384 signieren“ CONFIG_MODULE_SIG_SHA512 „Module mit SHA-512 signieren“
 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) „Dateiname oder PKCS#11-URI des Modulsignaturschlüssels“ (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) „Zusätzliche X.509-Schlüssel für den Standard-Systemschlüsselbund“ (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.
Beachten Sie, dass durch die Aktivierung der Modulsignierung eine Abhängigkeit von den OpenSSL-Entwicklungspaketen zu den Kernel-Build-Prozessen für das Tool hinzugefügt wird, das die Signierung durchführt.

======================== SIGNIERSCHLÜSSEL GENERIEREN

Zum Generieren und Überprüfen von Signaturen werden kryptografische Schlüsselpaare benötigt. Ein privater Schlüssel wird zum Generieren einer Signatur verwendet und der entsprechende öffentliche Schlüssel wird zum Überprüfen der Signatur verwendet. Der private Schlüssel wird nur während des Builds benötigt. Danach kann er gelöscht oder sicher gespeichert werden. Der öffentliche Schlüssel wird in den Kernel integriert, sodass er zum Überprüfen der Signaturen beim Laden der Module verwendet werden kann.

Unter normalen Umständen wird bei unverändertem CONFIG_MODULE_SIG_KEY gegenüber dem Standardwert der Kernel-Build automatisch ein neues Schlüsselpaar mit OpenSSL generiert, wenn in der Datei keins vorhanden ist:

zertifikate/signing_key.pem

während des Erstellens von vmlinux (der öffentliche Teil des Schlüssels muss in vmlinux integriert werden) mithilfe von Parametern im:

zertifikate/x509.genkey

Datei (die ebenfalls generiert wird, falls sie noch nicht vorhanden ist).

Es wird dringend empfohlen, dass Sie Ihre eigene x509.genkey-Datei bereitstellen.

Insbesondere sollte in der Datei x509.genkey der Abschnitt „req_distinguished_name“ gegenüber der Standardeinstellung geändert werden:

[ req_distinguished_name ] #O = Nicht angegebenes Unternehmen CN = Automatisch generierter Kernel-Schlüssel zur Build-Zeit #emailAddress = [email geschützt]

Die generierte RSA-Schlüsselgröße kann auch wie folgt eingestellt werden:

[ erforderlich ] Standardbits = 4096

Es ist auch möglich, die privaten/öffentlichen Schlüsseldateien manuell zu generieren, indem Sie die Schlüsselgenerierungskonfigurationsdatei x509.genkey im Stammknoten des Linux-Kernel-Quellbaums und den Befehl openssl verwenden. Nachfolgend sehen Sie ein Beispiel zum Generieren der öffentlichen/privaten Schlüsseldateien:

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

Der vollständige Pfadname für die resultierende Datei kernel_key.pem kann dann in der Option CONFIG_MODULE_SIG_KEY angegeben werden. Das darin enthaltene Zertifikat und der Schlüssel werden anstelle eines automatisch generierten Schlüsselpaars verwendet.

========================== ÖFFENTLICHE SCHLÜSSEL IM KERNEL

Der Kernel enthält einen Ring öffentlicher Schlüssel, die von Root eingesehen werden können. Sie befinden sich in einem Schlüsselring namens „.system_keyring“, der wie folgt eingesehen werden kann:

[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-Kernel-Signaturschlüssel: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

Über den speziell für die Modulsignierung generierten öffentlichen Schlüssel hinaus können zusätzliche vertrauenswürdige Zertifikate in einer PEM-codierten Datei bereitgestellt werden, auf die die Konfigurationsoption CONFIG_SYSTEM_TRUSTED_KEYS verweist.

Darüber hinaus kann der Architekturcode öffentliche Schlüssel aus einem Hardwarespeicher übernehmen und diese ebenfalls hinzufügen (z. B. aus der UEFI-Schlüsseldatenbank).

Schließlich ist es möglich, zusätzliche öffentliche Schlüssel hinzuzufügen, indem Sie Folgendes tun:

keyctl padd asymmetrisch "" [.system_keyring-ID] <[Schlüsseldatei]

z.B:

keyctl padd asymmetrisch "" 0x223c7853
Beachten Sie jedoch, dass der Kernel nur das Hinzufügen von Schlüsseln zu .system_keyring zulässtWennDer X.509-Wrapper des neuen Schlüssels ist gültig mit einem Schlüssel signiert, der sich zum Zeitpunkt der Hinzufügung des Schlüssels bereits im Systemschlüsselring befindet.

=========================== MODULE MANUELL SIGNIEREN

Um ein Modul manuell zu signieren, verwenden Sie das Tool scripts/sign-file, das im Quellcode des Linux-Kernels verfügbar ist. Das Skript erfordert 4 Argumente:

Der Hash-Algorithmus (z. B. sha256)

Der Dateiname des privaten Schlüssels oder die PKCS#11-URI

Der Dateiname des öffentlichen Schlüssels

Das zu signierende Kernelmodul

Das Folgende ist ein Beispiel zum Signieren eines Kernelmoduls:

Skripte/Signaturdatei sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

Der verwendete Hash-Algorithmus muss nicht mit dem konfigurierten übereinstimmen. Ist dies jedoch nicht der Fall, sollten Sie sicherstellen, dass der Hash-Algorithmus entweder im Kernel integriert ist oder ohne eigenen Bedarf geladen werden kann.

Wenn der private Schlüssel eine Passphrase oder PIN erfordert, kann diese in der Umgebungsvariable $KBUILD_SIGN_PIN bereitgestellt werden.

============================ SIGNIERTE MODULE UND STRIPPEN

Einem signierten Modul wird einfach am Ende eine digitale Signatur angehängt. Die Zeichenfolge „~Modulsignatur angehängt~.“ am Ende der Moduldatei bestätigt, dass eine Signatur vorhanden ist, aber nicht, dass die Signatur gültig ist!

Signierte Module sind BRÜCHTIG, da die Signatur außerhalb des definierten ELF-Containers liegt. Daher dürfen sie NICHT entfernt werden, sobald die Signatur berechnet und angehängt wurde. Beachten Sie, dass das gesamte Modul die signierte Nutzlast ist, einschließlich aller Debuginformationen, die zum Zeitpunkt der Signierung vorhanden sind.

======================= SIGNIERTE MODULE WERDEN GELADEN

Module werden mit insmod, modprobe, init_module() oder finit_module() geladen, genau wie nicht signierte Module, da keine Verarbeitung im Benutzerbereich erfolgt. Die Signaturprüfung erfolgt vollständig im Kernel.

== ...

Wenn CONFIG_MODULE_SIG_FORCE aktiviert ist oder module.sig_enforce=1 in der Kernel-Befehlszeile angegeben wird, lädt der Kernel nur gültig signierte Module, für die er einen öffentlichen Schlüssel hat. Andernfalls lädt er auch unsignierte Module. Module, für die der Kernel einen Schlüssel hat, deren Signatur jedoch nicht übereinstimmt, dürfen nicht geladen werden.

Jedes Modul mit einer nicht analysierbaren Signatur wird abgelehnt.

=========================================== VERWALTUNG/SCHUTZ DES PRIVATEN SCHLÜSSELS

Da der private Schlüssel zum Signieren von Modulen verwendet wird, könnten Viren und Malware den privaten Schlüssel zum Signieren von Modulen verwenden und das Betriebssystem kompromittieren. Der private Schlüssel muss entweder vernichtet oder an einen sicheren Ort verschoben werden und darf nicht im Stammknoten des Kernel-Quellcodebaums aufbewahrt werden.

Question 2

Ich hatte dasselbe Problem beim Laden des Treibers. Ich habe es einfach module.sig_enforce=0über die Befehlszeile meines Grub-Linux-Kernels eingegeben.

Hier sind die Schritte:

Einen Kernel-Boot-Parameter dauerhaft hinzufügen

Melden Sie sich beim System an und starten Sie ein Terminalfenster (Anwendungen→Zubehör→Terminal).
Geben Sie an der $Eingabeaufforderung den folgenden Befehl ein:
```
sudo gedit /etc/default/grub
```
Geben Sie Ihr Kennwort ein, wenn Sie dazu aufgefordert werden [sudo].

Wenn die Datei /etc/default/grubleer zu sein scheint oder nicht existiert, lesen Sie die oben stehenden Anweisungen für frühere Versionen.

Bewegen Sie den Cursor im Editorfenster mit den Pfeiltasten auf die Zeile, die mit beginnt. GRUB_CMDLINE_LINUX_DEFAULTBearbeiten Sie dann diese Zeile, indem Sie Ihre Parameter dem Text in den Anführungszeichen nach den Wörtern hinzufügen quiet splash. Ich habe hinzugefügt . (Denken Sie daran , vor dem Hinzufügen Ihres neuen Parameters module.sig_enforce=0ein LEERTASTE einzufügen .)splash
Drücke denSpeichernTaste
Schließen Sie das Editorfenster.
Geben Sie im Terminalfenster an der $Eingabeaufforderung Folgendes ein:
```
sudo update-grub
```
Starten Sie das System neu.

Versuchen Sie, Ihr Modul zu laden, bei mir hat es funktioniert.

Answer

Ich hatte dasselbe Problem beim Laden des Treibers. Ich habe es einfach module.sig_enforce=0über die Befehlszeile meines Grub-Linux-Kernels eingegeben.

Hier sind die Schritte:

Einen Kernel-Boot-Parameter dauerhaft hinzufügen

Melden Sie sich beim System an und starten Sie ein Terminalfenster (Anwendungen→Zubehör→Terminal).
Geben Sie an der $Eingabeaufforderung den folgenden Befehl ein:
```
sudo gedit /etc/default/grub
```
Geben Sie Ihr Kennwort ein, wenn Sie dazu aufgefordert werden [sudo].

Wenn die Datei /etc/default/grubleer zu sein scheint oder nicht existiert, lesen Sie die oben stehenden Anweisungen für frühere Versionen.

Bewegen Sie den Cursor im Editorfenster mit den Pfeiltasten auf die Zeile, die mit beginnt. GRUB_CMDLINE_LINUX_DEFAULTBearbeiten Sie dann diese Zeile, indem Sie Ihre Parameter dem Text in den Anführungszeichen nach den Wörtern hinzufügen quiet splash. Ich habe hinzugefügt . (Denken Sie daran , vor dem Hinzufügen Ihres neuen Parameters module.sig_enforce=0ein LEERTASTE einzufügen .)splash
Drücke denSpeichernTaste
Schließen Sie das Editorfenster.
Geben Sie im Terminalfenster an der $Eingabeaufforderung Folgendes ein:
```
sudo update-grub
```
Starten Sie das System neu.

Versuchen Sie, Ihr Modul zu laden, bei mir hat es funktioniert.

Question 3

Ubuntu 16.04 unterstützt zum Erstellen von PCI-Treibern pci_set_dma_mask statt pci_dma_supported. Bei falscher API-Nutzung wird beim Laden des Treibers ein Fehler wegen Nichtübereinstimmung des Secure Boot-Schlüssels ausgegeben.

Answer

Ubuntu 16.04 unterstützt zum Erstellen von PCI-Treibern pci_set_dma_mask statt pci_dma_supported. Bei falscher API-Nutzung wird beim Laden des Treibers ein Fehler wegen Nichtübereinstimmung des Secure Boot-Schlüssels ausgegeben.

Question 4

Bei Kernel v5.4 können Sie das Flag deaktivieren MODULE_SIG_FORCEund dann den Kernel neu erstellen.

Answer

Bei Kernel v5.4 können Sie das Flag deaktivieren MODULE_SIG_FORCEund dann den Kernel neu erstellen.

======== ÜBERBLICK

Antwort1

======== ÜBERBLICK

============================ MODULSIGNIERUNG KONFIGURIEREN

======================== SIGNIERSCHLÜSSEL GENERIEREN

========================== ÖFFENTLICHE SCHLÜSSEL IM KERNEL

=========================== MODULE MANUELL SIGNIEREN

============================ SIGNIERTE MODULE UND STRIPPEN

======================= SIGNIERTE MODULE WERDEN GELADEN

== ...

=========================================== VERWALTUNG/SCHUTZ DES PRIVATEN SCHLÜSSELS

Antwort2

Antwort3

Antwort4

verwandte Informationen