Linux 5.18 está trazendo muitos melhorias aleatórias/RNG graças ao trabalho do desenvolvedor do kernel Jason Donenfeld. Uma das mudanças que teve que ser desfeita durante a janela de mesclagem foi tentar fazer com que/dev/random e/dev/urandom se comportassem exatamente da mesma forma. Embora revertido por enquanto com o código 5.18, Donenfeld preparou uma mudança que deve deixá-lo em boa forma para as principais arquiteturas com o próximo ciclo do kernel.
Essa unificação do trabalho/dev/random e/dev/urandom teve que ser cancelada devido a algumas arquiteturas de CPU não terem fonte suficiente de aleatoriedade na inicialização e sem entropia de jitter. Isso estava causando problemas para Arm (32 bits), Motorola 68000 (M68k), Microblaze, SPARX32, Xtensa e outras arquiteturas de nicho.
Com este patch agora na árvore de desenvolvimento random.git, está tentando inicializar de forma oportunista em leituras/dev/urandom. Para arquiteturas principais e proeminentes, isso deve permitir o mesmo comportamento desejado com as alterações do Linux 5.18 RNG em torno do urandom.
Em 6f98a4bfee72 (“random: block in/dev/urandom”), tentamos fazer uma chamada try_to_generate_entropy() bem-sucedida *required* se o RNG ainda não foi inicializado. Infelizmente, arquiteturas estranhas e antigos espaços de usuário combinados em equipamentos de teste TCG, tornando essa mudança ainda não realista, por isso foi revertida em 0313bc278dac (“Revert”random: block in/dev/urandom””).
Entretanto, em vez de fazer uma chamada try_to_generate_entropy() bem-sucedida *required*, podemos fazê-la *best-effort*.
Se try_to_generate_entropy() falhar, ele falhará e nada mudará em relação ao comportamento atual. Se for bem-sucedido, o/dev/urandom se torna seguro para uso gratuito. Dessa forma, não arriscamos o potencial de regressão que nos levou a reverter a chamada required-try_to_generate_entropy() anterior.
Na prática, isso significa que pelo menos em x86,/dev/urandom se torna seguro. Provavelmente outras arquiteturas com contadores de ciclo em funcionamento também se tornarão seguras. E arquiteturas com contadores de ciclo lentos ou quebrados, pelo menos, não serão afetadas por essa mudança.
Então pode não ser o glorioso”todas as coisas estão unificadas!”mudança que esperávamos inicialmente, mas na prática, ela causa um impacto positivo.
Supondo que não haja mais problemas de RNG descobertos com este trabalho, você pode esperar que essa mudança apareça no Linux 5.19 kernel neste verão.
Atualização: agora parece que a alteração está sendo enviada como um pull request para o Linux 5.18 como uma”correção”… Veremos se essa mudança ainda é respeitada desta vez para o 5.18 ou é desviada para o 5.19.
