Início / server / Perguntas / 746733
Accepted
Aaron Copley
Asked: 2016-01-05 15:35:23 +0800 CST

Erro LUKS durante a inicialização

  • 772
alg: drbg: could not allocate DRNG handle for ...

Só vejo esse erro no console durante o processo de inicialização das máquinas virtuais que criamos. EDIT: 05/02/16 - Também vejo isso em algumas instalações bare-metal. (Ele continua inicializando completamente.) Presumo que tenha algo a ver com o hardware virtualizado e a falta de um gerador de números aleatórios (compatível). O problema é que não consigo avaliar a gravidade. A força da criptografia está comprometida? (Devo me importar com esse erro?) Como posso corrigi-lo?

Estamos usando QEMU/KVM no CentOS 6.7. Posso fazer um virsh dumpxml exemplo de sistema se você realmente achar que isso ajudará. Estamos usando o tamanho de chave/cifra padrão do Anaconda . (aes-xts-plain64/512)

Esta é a referência mais antiga que encontrei na lista de discussão linux-crypto . Infelizmente, é um pouco sobre a minha cabeça.

http://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg10398.html

alg: drbg: não foi possível alocar o identificador DRNG para ...

linux

2 respostas

  1. Conscientemente, não acredito que isso afete a força de sua criptografia.

    Eu verifiquei o código-fonte e, desde que eu esteja interpretando o que li corretamente, você não precisa necessariamente se preocupar com isso.

    Este código pertence ao módulo 'stdrng'. Pelo menos no Fedora 23, isso é incorporado ao kernel, em vez de exportado como um módulo do kernel.

    Quando stdrng é inicializado pela primeira vez, ocorrem as seguintes chamadas.

    Em crypto/drbg.c, a inicialização começa aqui.

    1997 module_init(drbg_init);

    Isso registra todos os drbgs conhecidos pelo sistema.

    1985         for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1986                 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 1);
1987         for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1988                 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 0);

    Em seguida, ele passa para uma função auxiliar que executa a inicialização:

    1989         return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));

    Neste crypto/rng.capenas itera através de cada rng para registrá-lo.

    210         for (i = 0; i < count; i++) {
211                 ret = crypto_register_rng(algs + i);
212                 if (ret)
213                         goto err;
214         }

    Essa função faz várias etapas de inicialização e chama outra função para alocação.

    196         return crypto_register_alg(base);

    O que não é tão óbvio é o que acontece durante o registro.

    Outro módulo chamado tcrypttambém embutido no kernel recebe notificações de novos algoritmos sendo inseridos. Uma vez que ele vê um novo algoritmo registrado, ele agenda um teste dele. Isso é o que produz a saída que você vê na tela.

    Quando o teste termina, o algoritmo entra no estado TESTADO. Se o teste falhar, imagino (não consegui encontrar o bit que produz esse comportamento) que não é selecionável para pesquisa se você passar os sinalizadores corretos.

    Se o teste passa ou não, é definitivamente armazenado internamente.

    Além disso, chamar o psudeo gerador de números aleatórios faz com que uma lista de algoritmos seja iterada de prngs em ordem de força, conforme ditado por esta nota emcrypto/drbg.c

    107 /*
108  * The order of the DRBG definitions here matter: every DRBG is registered
109  * as stdrng. Each DRBG receives an increasing cra_priority values the later
110  * they are defined in this array (see drbg_fill_array).
111  *

    Como o mais forte não falha (hmac sha256), é improvável que você esteja usando os com falha, mesmo que possam ser selecionados.

    Para resumir -

    • Isso acontece quando o stdrngmódulo é necessário para algo.
    • Ele carrega todos os seus algoritmos conhecidos.
    • Todos os algoritmos carregados são testados. Alguns podem falhar (por que não é considerado nesta resposta).
    • Os algoritmos com falha no teste não devem estar disponíveis para seleção posteriormente.
    • Os PRNGS são ordenados por força e os PRNGS fortes que passam são tentados primeiro.
    • Coisas que dependem de stdrngesperançosamente não devem usar esses algoritmos como base para sua fonte PRNG.

    Você pode ver quais algoritmos tiveram sucesso e passaram nos testes usando o seguinte comando:

     grep -EC5 'selftest.*passed' /proc/crypto

    Você também pode ver a prioridade de seleção com o campo 'prioridade'. Quanto maior o valor, mais forte é o PRNG de acordo com o autor do módulo.

    Então, feliz por estar errado aqui, pois não me considero um programador de kernel, mas, em conclusão -

    Quando stdrngcarregado, parece selecionar outros algoritmos da lista de algoritmos aceitáveis ​​que são considerados mais fortes do que os com falha, e os com falha provavelmente não são selecionados de qualquer maneira.

    Como tal, acredito que não há risco adicional para você ao usar luks.

    • 8
  2. Best Answer

    Como posso consertar isso?

    De acordo com a Base de Conhecimento da Red Hat , você deve adicionar o módulo 'ctr' do Kernel ao seu initrd. Suas instruções também dizem para incluir 'ecb', embora pareça que o problema é que o módulo 'ctr' não está sendo carregado.

    dracut -f -v --add-drivers "ctr ecb"

    Os assinantes podem ver as informações completas. Não tenho certeza se tenho permissão para republicar o resto aqui, então parafraseei a solução completa.

    https://access.redhat.com/solutions/2249181

    Editar 29/09/2016:

    Você também pode adicionar esses drivers para /etc/dracut.confque sejam adicionados ao novo initramfs nas atualizações do Kernel. Caso contrário, seus sintomas reaparecem misteriosamente muitos meses depois. ;)

    add_drivers+="ctr ecb"
    • 1

relate perguntas