======== VISÃO GERAL

Question 1

Você desativa a inicialização segura ou assina o módulo do kernel.

Pessoalmente, desativo a inicialização segura na BIOS.

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

Ou para assinar manualmente o módulo do kernel, consulte

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

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
CONTEÚDO

Visão geral.

Configurando a assinatura do módulo.

Gerando chaves de assinatura.

Chaves públicas no kernel.

Assinando módulos manualmente.

Módulos assinados e decapagem.

Carregando módulos assinados.

Assinaturas inválidas e módulos não assinados.

Administrar/proteger a chave privada.

======== VISÃO GERAL

O recurso de assinatura de módulo do kernel assina criptograficamente os módulos durante a instalação e, em seguida, verifica a assinatura ao carregar o módulo. Isso permite maior segurança do kernel ao impedir o carregamento de módulos não assinados ou módulos assinados com uma chave inválida. A assinatura de módulo aumenta a segurança, dificultando o carregamento de um módulo malicioso no kernel. A verificação da assinatura do módulo é feita pelo kernel para que não seja necessário ter bits de espaço de usuário confiáveis.

Este recurso usa certificados padrão X.509 ITU-T para codificar as chaves públicas envolvidas. As assinaturas não são codificadas em nenhum tipo de padrão industrial. Atualmente, o recurso suporta apenas o padrão de criptografia de chave pública RSA (embora seja conectável e permita o uso de outros). Os possíveis algoritmos de hash que podem ser usados são SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (o algoritmo é selecionado pelos dados na assinatura).

========================== CONFIGURANDO ASSINATURA DO MÓDULO

O recurso de assinatura de módulo é ativado indo para a seção "Ativar suporte a módulo carregável" da configuração do kernel e ativando

CONFIG_MODULE_SIG "Verificação de assinatura do módulo"

Isso tem uma série de opções disponíveis:

(1) "Exigir que os módulos sejam assinados de forma válida" (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) "Assinar automaticamente todos os módulos" (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:
scripts/arquivo de assinatura

(3) "Com qual algoritmo de hash os módulos devem ser assinados?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 "Assinar módulos com SHA-1" CONFIG_MODULE_SIG_SHA224 "Assinar módulos com SHA-224" CONFIG_MODULE_SIG_SHA256 "Assinar módulos com SHA-256" CONFIG_MODULE_SIG_SHA384 "Assinar módulos com SHA-384" CONFIG_MODULE_SIG_SHA512 "Assinar módulos com 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) "Nome do arquivo ou URI PKCS#11 da chave de assinatura do módulo" (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) "Chaves X.509 adicionais para chaveiro padrão do sistema" (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.
Observe que habilitar a assinatura do módulo adiciona uma dependência dos pacotes de desenvolvimento do OpenSSL aos processos de construção do kernel para a ferramenta que faz a assinatura.

======================= GERANDO CHAVES DE ASSINATURA

Pares de chaves criptográficas são necessários para gerar e verificar assinaturas. Uma chave privada é usada para gerar uma assinatura e a chave pública correspondente é usada para verificá-la. A chave privada só é necessária durante a construção, após a qual ela pode ser excluída ou armazenada com segurança. A chave pública é incorporada ao kernel para que possa ser usada para verificar as assinaturas à medida que os módulos são carregados.

Sob condições normais, quando CONFIG_MODULE_SIG_KEY permanece inalterado em relação ao seu padrão, a compilação do kernel irá gerar automaticamente um novo par de chaves usando o openssl se não existir nenhum no arquivo:

certificados/signing_key.pem

durante a construção do vmlinux (a parte pública da chave precisa ser incorporada no vmlinux) usando parâmetros em:

certificados/x509.genkey

arquivo (que também é gerado se ainda não existir).

É altamente recomendável que você forneça seu próprio arquivo x509.genkey.

Mais notavelmente, no arquivo x509.genkey, a seção req_distinguished_name deve ser alterada do padrão:

[ req_distinguished_name ] #O = Empresa não especificada CN = Chave do kernel gerada automaticamente no momento da construção #emailAddress = [e-mail protegido]

O tamanho da chave RSA gerada também pode ser definido com:

[requerido] default_bits = 4096

Também é possível gerar manualmente os principais arquivos privados/públicos usando o arquivo de configuração de geração de chave x509.genkey no nó raiz da árvore de fontes do kernel Linux e o comando openssl. A seguir está um exemplo para gerar os arquivos de chave pública/privada:

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

O nome do caminho completo para o arquivo kernel_key.pem resultante pode então ser especificado na opção CONFIG_MODULE_SIG_KEY, e o certificado e a chave nele contidos serão usados em vez de um par de chaves gerado automaticamente.

========================= CHAVES PÚBLICAS NO KERNEL

O kernel contém um anel de chaves públicas que podem ser visualizadas pelo root. Eles estão em um chaveiro chamado ".system_keyring" que pode ser visto por:

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 chaveiro .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 assimetria Assinatura do kernel do Fedora chave: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

Além da chave pública gerada especificamente para assinatura de módulo, certificados confiáveis adicionais podem ser fornecidos em um arquivo codificado em PEM referenciado pela opção de configuração CONFIG_SYSTEM_TRUSTED_KEYS.

Além disso, o código da arquitetura pode pegar chaves públicas de um armazenamento de hardware e adicioná-las também (por exemplo, do banco de dados de chaves UEFI).

Finalmente, é possível adicionar chaves públicas adicionais fazendo:

keyctl padd assimétrico "" [.system_keyring-ID] <[arquivo-chave]

por exemplo:

keyctl padd assimétrico "" 0x223c7853
Observe, entretanto, que o kernel só permitirá que chaves sejam adicionadas a .system_keyringseo wrapper X.509 da nova chave é assinado de forma válida por uma chave que já reside no .system_keyring no momento em que a chave foi adicionada.

========================= MÓDULOS DE ASSINATURA MANUAL

Para assinar manualmente um módulo, use a ferramenta scripts/sign-file disponível na árvore de origem do kernel Linux. O script requer 4 argumentos:

O algoritmo hash (por exemplo, sha256)

O nome do arquivo da chave privada ou URI PKCS#11

O nome do arquivo de chave pública

O módulo do kernel a ser assinado

A seguir está um exemplo para assinar um módulo do kernel:

scripts/arquivo de assinatura sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

O algoritmo de hash usado não precisa corresponder ao configurado, mas se não corresponder, você deve certificar-se de que o algoritmo de hash está incorporado no kernel ou pode ser carregado sem necessidade.

Se a chave privada exigir uma senha ou PIN, ela poderá ser fornecida na variável de ambiente $KBUILD_SIGN_PIN.

============================ MÓDULOS ASSINADOS E REMOÇÃO

Um módulo assinado possui uma assinatura digital simplesmente anexada no final. A string "~Assinatura do módulo anexada~." no final do arquivo do módulo confirma que uma assinatura está presente, mas não confirma que a assinatura é válida!

Os módulos assinados são FRÁGEIS porque a assinatura está fora do contêiner ELF definido. Portanto, eles NÃO PODEM ser retirados depois que a assinatura for computada e anexada. Observe que todo o módulo é a carga assinada, incluindo toda e qualquer informação de depuração presente no momento da assinatura.

====================== CARREGANDO MÓDULOS ASSINADOS

Os módulos são carregados com insmod, modprobe, init_module() ou finit_module(), exatamente como para módulos não assinados, pois nenhum processamento é feito no espaço do usuário. A verificação de assinatura é toda feita dentro do kernel.

======================================= ASSINATURAS NÃO VÁLIDAS E MÓDULOS NÃO ASSINADOS

Se CONFIG_MODULE_SIG_FORCE estiver habilitado ou module.sig_enforce=1 for fornecido na linha de comando do kernel, o kernel carregará apenas módulos assinados validamente para os quais possui uma chave pública. Caso contrário, também carregará módulos não assinados. Qualquer módulo para o qual o kernel tenha uma chave, mas que prove ter uma incompatibilidade de assinatura, não terá permissão para carregar.

Qualquer módulo que tenha uma assinatura não analisável será rejeitado.

======================================= ADMINISTRAÇÃO/PROTEÇÃO DA CHAVE PRIVADA

Como a chave privada é usada para assinar módulos, vírus e malware podem usar a chave privada para assinar módulos e comprometer o sistema operacional. A chave privada deve ser destruída ou movida para um local seguro e não mantida no nó raiz da árvore fonte do kernel.

Answer

Você desativa a inicialização segura ou assina o módulo do kernel.

Pessoalmente, desativo a inicialização segura na BIOS.

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

Ou para assinar manualmente o módulo do kernel, consulte

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

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================
CONTEÚDO

Visão geral.

Configurando a assinatura do módulo.

Gerando chaves de assinatura.

Chaves públicas no kernel.

Assinando módulos manualmente.

Módulos assinados e decapagem.

Carregando módulos assinados.

Assinaturas inválidas e módulos não assinados.

Administrar/proteger a chave privada.

======== VISÃO GERAL

O recurso de assinatura de módulo do kernel assina criptograficamente os módulos durante a instalação e, em seguida, verifica a assinatura ao carregar o módulo. Isso permite maior segurança do kernel ao impedir o carregamento de módulos não assinados ou módulos assinados com uma chave inválida. A assinatura de módulo aumenta a segurança, dificultando o carregamento de um módulo malicioso no kernel. A verificação da assinatura do módulo é feita pelo kernel para que não seja necessário ter bits de espaço de usuário confiáveis.

Este recurso usa certificados padrão X.509 ITU-T para codificar as chaves públicas envolvidas. As assinaturas não são codificadas em nenhum tipo de padrão industrial. Atualmente, o recurso suporta apenas o padrão de criptografia de chave pública RSA (embora seja conectável e permita o uso de outros). Os possíveis algoritmos de hash que podem ser usados são SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (o algoritmo é selecionado pelos dados na assinatura).

========================== CONFIGURANDO ASSINATURA DO MÓDULO

O recurso de assinatura de módulo é ativado indo para a seção "Ativar suporte a módulo carregável" da configuração do kernel e ativando

CONFIG_MODULE_SIG "Verificação de assinatura do módulo"

Isso tem uma série de opções disponíveis:

(1) "Exigir que os módulos sejam assinados de forma válida" (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) "Assinar automaticamente todos os módulos" (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:
scripts/arquivo de assinatura

(3) "Com qual algoritmo de hash os módulos devem ser assinados?"
 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:
CONFIG_MODULE_SIG_SHA1 "Assinar módulos com SHA-1" CONFIG_MODULE_SIG_SHA224 "Assinar módulos com SHA-224" CONFIG_MODULE_SIG_SHA256 "Assinar módulos com SHA-256" CONFIG_MODULE_SIG_SHA384 "Assinar módulos com SHA-384" CONFIG_MODULE_SIG_SHA512 "Assinar módulos com 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) "Nome do arquivo ou URI PKCS#11 da chave de assinatura do módulo" (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) "Chaves X.509 adicionais para chaveiro padrão do sistema" (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.
Observe que habilitar a assinatura do módulo adiciona uma dependência dos pacotes de desenvolvimento do OpenSSL aos processos de construção do kernel para a ferramenta que faz a assinatura.

======================= GERANDO CHAVES DE ASSINATURA

Pares de chaves criptográficas são necessários para gerar e verificar assinaturas. Uma chave privada é usada para gerar uma assinatura e a chave pública correspondente é usada para verificá-la. A chave privada só é necessária durante a construção, após a qual ela pode ser excluída ou armazenada com segurança. A chave pública é incorporada ao kernel para que possa ser usada para verificar as assinaturas à medida que os módulos são carregados.

Sob condições normais, quando CONFIG_MODULE_SIG_KEY permanece inalterado em relação ao seu padrão, a compilação do kernel irá gerar automaticamente um novo par de chaves usando o openssl se não existir nenhum no arquivo:

certificados/signing_key.pem

durante a construção do vmlinux (a parte pública da chave precisa ser incorporada no vmlinux) usando parâmetros em:

certificados/x509.genkey

arquivo (que também é gerado se ainda não existir).

É altamente recomendável que você forneça seu próprio arquivo x509.genkey.

Mais notavelmente, no arquivo x509.genkey, a seção req_distinguished_name deve ser alterada do padrão:

[ req_distinguished_name ] #O = Empresa não especificada CN = Chave do kernel gerada automaticamente no momento da construção #emailAddress = [e-mail protegido]

O tamanho da chave RSA gerada também pode ser definido com:

[requerido] default_bits = 4096

Também é possível gerar manualmente os principais arquivos privados/públicos usando o arquivo de configuração de geração de chave x509.genkey no nó raiz da árvore de fontes do kernel Linux e o comando openssl. A seguir está um exemplo para gerar os arquivos de chave pública/privada:

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

O nome do caminho completo para o arquivo kernel_key.pem resultante pode então ser especificado na opção CONFIG_MODULE_SIG_KEY, e o certificado e a chave nele contidos serão usados em vez de um par de chaves gerado automaticamente.

========================= CHAVES PÚBLICAS NO KERNEL

O kernel contém um anel de chaves públicas que podem ser visualizadas pelo root. Eles estão em um chaveiro chamado ".system_keyring" que pode ser visto por:

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 chaveiro .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 assimetria Assinatura do kernel do Fedora chave: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

Além da chave pública gerada especificamente para assinatura de módulo, certificados confiáveis adicionais podem ser fornecidos em um arquivo codificado em PEM referenciado pela opção de configuração CONFIG_SYSTEM_TRUSTED_KEYS.

Além disso, o código da arquitetura pode pegar chaves públicas de um armazenamento de hardware e adicioná-las também (por exemplo, do banco de dados de chaves UEFI).

Finalmente, é possível adicionar chaves públicas adicionais fazendo:

keyctl padd assimétrico "" [.system_keyring-ID] <[arquivo-chave]

por exemplo:

keyctl padd assimétrico "" 0x223c7853
Observe, entretanto, que o kernel só permitirá que chaves sejam adicionadas a .system_keyringseo wrapper X.509 da nova chave é assinado de forma válida por uma chave que já reside no .system_keyring no momento em que a chave foi adicionada.

========================= MÓDULOS DE ASSINATURA MANUAL

Para assinar manualmente um módulo, use a ferramenta scripts/sign-file disponível na árvore de origem do kernel Linux. O script requer 4 argumentos:

O algoritmo hash (por exemplo, sha256)

O nome do arquivo da chave privada ou URI PKCS#11

O nome do arquivo de chave pública

O módulo do kernel a ser assinado

A seguir está um exemplo para assinar um módulo do kernel:

scripts/arquivo de assinatura sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

O algoritmo de hash usado não precisa corresponder ao configurado, mas se não corresponder, você deve certificar-se de que o algoritmo de hash está incorporado no kernel ou pode ser carregado sem necessidade.

Se a chave privada exigir uma senha ou PIN, ela poderá ser fornecida na variável de ambiente $KBUILD_SIGN_PIN.

============================ MÓDULOS ASSINADOS E REMOÇÃO

Um módulo assinado possui uma assinatura digital simplesmente anexada no final. A string "~Assinatura do módulo anexada~." no final do arquivo do módulo confirma que uma assinatura está presente, mas não confirma que a assinatura é válida!

Os módulos assinados são FRÁGEIS porque a assinatura está fora do contêiner ELF definido. Portanto, eles NÃO PODEM ser retirados depois que a assinatura for computada e anexada. Observe que todo o módulo é a carga assinada, incluindo toda e qualquer informação de depuração presente no momento da assinatura.

====================== CARREGANDO MÓDULOS ASSINADOS

Os módulos são carregados com insmod, modprobe, init_module() ou finit_module(), exatamente como para módulos não assinados, pois nenhum processamento é feito no espaço do usuário. A verificação de assinatura é toda feita dentro do kernel.

======================================= ASSINATURAS NÃO VÁLIDAS E MÓDULOS NÃO ASSINADOS

Se CONFIG_MODULE_SIG_FORCE estiver habilitado ou module.sig_enforce=1 for fornecido na linha de comando do kernel, o kernel carregará apenas módulos assinados validamente para os quais possui uma chave pública. Caso contrário, também carregará módulos não assinados. Qualquer módulo para o qual o kernel tenha uma chave, mas que prove ter uma incompatibilidade de assinatura, não terá permissão para carregar.

Qualquer módulo que tenha uma assinatura não analisável será rejeitado.

======================================= ADMINISTRAÇÃO/PROTEÇÃO DA CHAVE PRIVADA

Como a chave privada é usada para assinar módulos, vírus e malware podem usar a chave privada para assinar módulos e comprometer o sistema operacional. A chave privada deve ser destruída ou movida para um local seguro e não mantida no nó raiz da árvore fonte do kernel.

Question 2

Eu tive esse mesmo problema de carregamento de driver. Eu simplesmente passei module.sig_enforce=0na linha de comando do kernel do grub linux.

Aqui estão as etapas:

Adicionar permanentemente um parâmetro de inicialização do kernel

Faça login no sistema e inicie uma janela de terminal (Formulários→Acessórios→terminal).
No $prompt, digite o comando:
```
sudo gedit /etc/default/grub
```
Digite sua senha quando solicitado por [sudo].

Se o arquivo /etc/default/grubparecer vazio ou não existir, consulte as instruções para versões anteriores acima.

Na janela do editor, use as teclas de seta para mover o cursor para a linha que começa com GRUB_CMDLINE_LINUX_DEFAULTe edite essa linha, adicionando seu(s) parâmetro(s) ao texto entre aspas duplas após as palavras quiet splash. Eu adicionei module.sig_enforce=0. (Certifique-se de adicionar um ESPAÇO splashantes de adicionar seu novo parâmetro.)
Clique noSalvarbotão
Feche a janela do editor.
Na janela do terminal, no $prompt, digite:
```
sudo update-grub
```
Reinicie o sistema.

Tente carregar seu módulo e funcionou para mim.

Answer

Eu tive esse mesmo problema de carregamento de driver. Eu simplesmente passei module.sig_enforce=0na linha de comando do kernel do grub linux.

Aqui estão as etapas:

Adicionar permanentemente um parâmetro de inicialização do kernel

Faça login no sistema e inicie uma janela de terminal (Formulários→Acessórios→terminal).
No $prompt, digite o comando:
```
sudo gedit /etc/default/grub
```
Digite sua senha quando solicitado por [sudo].

Se o arquivo /etc/default/grubparecer vazio ou não existir, consulte as instruções para versões anteriores acima.

Na janela do editor, use as teclas de seta para mover o cursor para a linha que começa com GRUB_CMDLINE_LINUX_DEFAULTe edite essa linha, adicionando seu(s) parâmetro(s) ao texto entre aspas duplas após as palavras quiet splash. Eu adicionei module.sig_enforce=0. (Certifique-se de adicionar um ESPAÇO splashantes de adicionar seu novo parâmetro.)
Clique noSalvarbotão
Feche a janela do editor.
Na janela do terminal, no $prompt, digite:
```
sudo update-grub
```
Reinicie o sistema.

Tente carregar seu módulo e funcionou para mim.

Question 3

Ubuntu 16.04 suporta pci_set_dma_mask em vez de pci_dma_supported para construção de drivers PCI. O uso incorreto da API imprimirá um erro de incompatibilidade de chave de inicialização segura ao carregar o driver.

Answer

Ubuntu 16.04 suporta pci_set_dma_mask em vez de pci_dma_supported para construção de drivers PCI. O uso incorreto da API imprimirá um erro de incompatibilidade de chave de inicialização segura ao carregar o driver.

Question 4

No kernel v5.4, você pode desabilitar o sinalizador MODULE_SIG_FORCEe então reconstruir o kernel.

Answer

No kernel v5.4, você pode desabilitar o sinalizador MODULE_SIG_FORCEe então reconstruir o kernel.

======== VISÃO GERAL

Responder1

======== VISÃO GERAL

========================== CONFIGURANDO ASSINATURA DO MÓDULO

======================= GERANDO CHAVES DE ASSINATURA

========================= CHAVES PÚBLICAS NO KERNEL

========================= MÓDULOS DE ASSINATURA MANUAL

============================ MÓDULOS ASSINADOS E REMOÇÃO

====================== CARREGANDO MÓDULOS ASSINADOS

======================================= ASSINATURAS NÃO VÁLIDAS E MÓDULOS NÃO ASSINADOS

======================================= ADMINISTRAÇÃO/PROTEÇÃO DA CHAVE PRIVADA

Responder2

Responder3

Responder4

informação relacionada