As alterações do subsistema de criptografia para o kernel Linux 5.5 são notáveis. A principal adição à área de criptografia para o próximo ciclo do kernel é carregar os patches que adotam alguns elementos do esforço de criptografia Zinc liderado por Jason Donenfeld, da WireGuard. A falta de suporte ao Zinc no kernel Linux principal tem sido o principal bloqueador da fusão desse túnel VPN seguro no kernel. Assim, o Linux 5.5 Crypto Code tem as alterações para inaugurar o WireGuard.
Porém, agora o pessoal de criptografia decidiu integrar algumas das melhores peças de seu design e, com o tempo, outros bits de Zinc poderiam ainda ser mesclados também. No entanto, o que está chegando ao Linux 5.5 é suficiente para desbloquear a dependência de criptografia no WireGuard. Com isso dito, o WireGuard deve chegar ao Linux 5.6 se as revisões finais forem boas, mas infelizmente não estão prontas a tempo para este novo ciclo 5.5.
Também notável no Linux 5.5 está finalizando a transição para o SKCIPHER, para que o código de bloco assíncrono “BLKCIPHER”/”ABLKCIPHER” possa finalmente ser removido.
Linux 5.5 Crypto Code tem as alterações para inaugurar o WireGuard
Agora também foi adicionado suporte aos algoritmos blake2b e blake2s, algoritmo curve25519 KPP, código ChaCha acelerado escalar para ARM, código 32r2 acelerado do Zinc para a arquitetura MIPS, um driver HiSilicon TRNG e código do acelerador HPRE e vários outros bits de driver de criptografia.
Mais detalhes sobre as mudanças de criptografia para o que será o primeiro grande lançamento do kernel de 2020 podem ser encontrados através desta solicitação de recebimento.
Linux 5.5 para finalmente conectar o código EFI RNG para x86 como outra fonte de entropia
Desde 2016, o kernel Linux no ARM invocou o protocolo EFI Random Number Generator (RNG) para servir como uma fonte adicional de entropia durante a inicialização antecipada. Com o Linux 5.5 no início de 2020, esse código finalmente está acontecendo para x86/x86_64.
A especificação EFI possui um protocolo RNG que é opcional para poder retornar valores RNG ao suportar um conjunto arbitrário de algoritmos RNG. Isso existe desde UEFI 2.4 (2013) e, embora o código ARM do kernel Linux o invoque há anos em seu código EFI, o código x86 (x86_64 incluído) possui uma conexão semelhante ao Linux 5.5.
Onde suportado, isso propiciará o pool de entropia do kernel como outra fonte de entropia durante os estágios iniciais do processo de inicialização, onde normalmente a entropia pode ser bastante limitada. Já existe o CONFIG_RANDOM_TRUST_BOOTLOADER existente Kconfig alterna para saber se essa fonte aleatória pode ser confiável.
Esse código EFI x86 RNG está entre os poucos aprimoramentos nas atualizações de EFI para a v5.5.
Sanitizer de simultaneidade de kernel definido para Linux 5.5 para descobrir condições de corrida de dados
Adicionando à lista de alterações no deck do kernel do Linux 5.5 está um novo “desinfetante” para detectar as condições de corrida de dados.
O kernel do Linux já possui um limpador de endereços, de comportamento indefinido e outros auxiliares, enquanto o mais novo é o sanitizer de simultaneidade do kernel. Como muitos dos limpadores para o kernel e dentro dos compiladores, o trabalho é cortesia dos engenheiros do Google.
O Sanitizer de simultaneidade do kernel deve detectar as corridas de dados dentro do kernel em tempo real quando compilado com o suporte “KCSAN” ativado. Devido à sobrecarga de tempo de execução, essa funcionalidade não deve ser empacotada para kernels de produção, mas mais apenas para testar compilações.
Veja como funciona:
O KCSAN usa os recursos de instrumentação -fsanitize = thread build time do GCC e do Clang, que transforma todas as leituras / gravações de memória em retornos de chamada __tsan_ * com endereços e sinalizadores de tipo de acesso passados ??no KCSAN que o KCSAN pode processar e se transformar em uma matriz global de ‘watchpoints’ que denotam acessos contínuos. Se duas CPUs acontecerem uma com a outra através de um acesso não seguro (não atômico), um aviso será gerado.
O Kernel Concurrency Sanitizer ainda está sendo aprimorado para solucionar falsos positivos, mas a implementação inicial está pronta para o Linux 5.5.
Linux 5.5 inicia sanidade checando a saída RdRand devido ao comportamento do processador de buggy
O kernel Linux 5.5 em desenvolvimento começará a verificar com integridade a saída da instrução RdRand quanto à aleatoriedade na inicialização e retomada da CPU devido ao recente impacto das CPUs AMD que produziram uma saída RdRand não aleatória.
Notícias Relacionadas
Devido a algumas CPUs AMD Jaguar e Bulldozer terem o RdRand de buggy quando emparelhadas com várias placas-mãe devido a diferenças de firmware e BIOS, particularmente no currículo, o kernel Linux não voltou mais a anunciar os processadores RdRand for Family 15h/16h há alguns meses.
Porém, como uma solução de longo prazo mais genérica para afastar os problemas do RdRand, o kernel do Linux está começando a verificar a saída do RdRand.
Com o caminho do código de inicialização da CPU do Linux 5.5, o kernel começará a testar a saída do RdRand executando vários loops e assegurando a saída entre os loops que chamam de mudança do RdRand. Se a saída do RdRand não for alterada (como sempre retornando zeros, como era o caso de alguns sistemas AMD), o kernel será despejado no dmesg: ” RDRAND fornece uma saída com cheiro desagradável, considere não usá-lo inicializando com” nordrand “.
Isso combinado com as questões aleatoriedade CPU x86_64 fora todos conhecidos atualmente existentes desativação de anúncios RdRand para processadores 15h / 16h e já tendo trabalhado com as questões Zen 2 deve quadrados. A verificação de integridade do RdRand foi enviada hoje pela janela de mesclagem 5.5 como parte das alterações do x86 / cpu .
Linux 5.5 para finalmente conectar o código EFI RNG para x86 como outra fonte de entropia
Desde 2016, o kernel do Linux no ARM invocou o protocolo EFI Random Number Generator (RNG) para servir como uma fonte adicional de entropia durante a inicialização antecipada. Com o Linux 5.5 no início de 2020, esse código finalmente está acontecendo para x86 / x86_64.
A especificação EFI possui um protocolo RNG que é opcional para poder retornar valores RNG ao suportar um conjunto arbitrário de algoritmos RNG. Isso existe desde UEFI 2.4 (2013) e, embora o código ARM do kernel Linux o invoque há anos em seu código EFI, o código x86 (x86_64 incluído) possui uma conexão semelhante ao Linux 5.5.
Onde suportado, isso propiciará o pool de entropia do kernel como outra fonte de entropia durante os estágios iniciais do processo de inicialização, onde normalmente a entropia pode ser bastante limitada. Já existe o CONFIG_RANDOM_TRUST_BOOTLOADER existente o Kconfig alterna para saber se essa fonte aleatória pode ser confiável.
Esse código EFI x86 RNG está entre os poucos aprimoramentos nas atualizações de EFI para a v5.5.
O agendador do Linux 5.5 vê um retrabalho de balanceamento de carga para obter melhor desempenho, mas apresenta regressões de risco
Ingo Molnar enviou as alterações no agendador do kernel, juntamente com o outro material que ele está supervisionando para o Linux 5.5. Com esta próxima versão do kernel Linux, ocorre uma reformulação da lógica de balanceamento de carga do Completely Fair Scheduler. Isso está ajudando algumas atividades, pelo menos, mas com a mudança intrusiva corre o risco de possíveis regressões.
O retrabalho da lógica de balanceamento de carga do CFS foi realizado por engenheiros da Linaro e Arm, entre outras organizações, devido à localização inadequada de tarefas com o algoritmo atual. Uma grande limpeza ocorreu e, após várias rodadas de revisões, eles esperam ter abordado todas as regressões. O Ingo reconhece o risco de algumas consequências dessa mudança invasiva
O retrabalho do balanceamento de carga é a mudança mais intrusiva: substitui as heurísticas antigas que se tornaram menos significativas após a introdução das métricas do PELT, por um algoritmo de balanceamento de carga inicial. Como tal, não é realmente uma série iterativa, mas substitui a antiga lógica de balanceamento de carga pela nova. Esperamos que não restem regressões de desempenho – mas, estatisticamente, é altamente provável que haja alguma carga de trabalho prejudicando essas mudanças. Nesse caso, preferimos dar uma olhada nessa carga de trabalho e corrigir seu agendamento, em vez de reverter as alterações.
Ao testar em um sistema ARM64 de quatro núcleos, eles descobriram que o desempenho variava de menos de 1% a mais de 10% no teste do planejador Hackbench. Com um servidor ARM64 de 224 núcleos, o desempenho variou de menos de 1% de melhorias a 12% de desempenho melhor com o Hackbench e até 33% de desempenho melhor com o Dbench. Mais números e detalhes através da revisão do patch v4.
Portanto, esse código do planejador faz dele uma das mudanças interessantes até agora para esta nova janela de mesclagem do Linux 5.5.
Como se vê, além do Linux 5.5 Crypto Code tem as alterações para inaugurar o WireGuard, teremos muitas outras novidades.
Fonte: Phoronix
