A informação não está diretamente relacionado à recente atualização do BIOS AMD Zen 2 necessária para corrigir um problema de RdRand. Embora esteja relacionado ao fato de que o erro original do AMD RdRand provém dessas CPUs anteriores. Porém, a AMD decidiu não mais anunciar o suporte da RdRand para os processadores Family 15h (Bulldozer) e Family 16h (Jaguar) no Linux. Processadores AMD Bulldozer/Jaguar perdem suporte da RdRand no Linux.
A instrução RdRand ainda funcionará em CPUs com esta capacidade. No entanto, o bit de ID da CPU está sendo limpo para que não seja anunciado que o software verifique explicitamente o suporte. Tom Lendacky da AMD recorreu à limpeza do bit de ID de CPU RDRAND para processadores de 15h/16h (sem impacto para o Zen etc.) devido a problemas de RdRand surgindo após a suspensão/retomada. Esses problemas afetaram alguns usuários por algum tempo e originaram-se com o relatório de bug systemd da AMD RdRand original sobre problemas após esse ciclo.
Processadores AMD Bulldozer/Jaguar perdem suporte da RdRand no Linux
O buggy RdRand está sendo responsabilizado pelas implementações da BIOS que não executam as etapas apropriadas para garantir que a RdRand continue funcionando. Contudo, aparentemente com BIOS com defeito suficiente, o bit RdRand será limpo para que os processadores tentem impedir que o software o use. Embora qualquer software que o faça ainda possa experimentar os eventos problemáticos. O bug é conhecido há pelo menos cinco anos.
Se você não planeja suspender/retomar ou se seu sistema/BIOS está em bom estado, há um novo parâmetro de kernel rdrand_force sendo incluído para ativar este suporte (também conhecido como manter o status quo).
Em resposta, pelo menos um desenvolvedor está causando uma vulnerabilidade de segurança que até agora o RdRand poderia estar lançando dados não aleatórios. E um problema com a implementação de RdRand da AMD que poderia ser insegura se não fosse programada adequadamente pelo BIOS.
Esta alteração está atualmente pendente através deste patch que provavelmente terminará no ciclo Linux 5.4, embora ainda não haja nenhuma palavra sobre correções.
Oracle está trabalhando para criar mais do DTrace para o kernel Linux e implementação de eBPF
https://www.youtube.com/watch?v=_o92BAmQigo
Enquanto os prospectos do DTrace para o kernel Linux não são mais vistos como mágicos ou inovadores como eram há mais de uma década, a Oracle continua trabalhando em sua porta DTrace para o Linux e estendendo seu alcance além do “Unbreakable Enterprise Kernel” para o RHEL. -clonado Oracle Linux. A Oracle agora diz que está trabalhando para aumentar o volume de trabalho, além de obter uma implementação baseada em eBPF para o kernel.
Notícias Relacionadas
Na quarta-feira, a Oracle publicou uma postagem no blog descrevendo o DTrace no Fedora. Fazer o DTrace funcionar no Fedora não é fácil: atualmente, é necessário criar uma versão com patch do kernel do Linux e também criar os utilitários de espaço do usuário do DTrace. É assim que atualmente é para a maioria ou todas as distribuições Linux além do Oracle Linux com UEK.
Embora esteja escrito no post do blog:
Note que, no momento, a Oracle está fazendo o upstreaming do trabalho relacionado ao DTrace e reimplementando o próprio DTrace em cima da infra-estrutura de kernel existente, como o eBPF. Mais sobre isso em blogs futuros.
Isso é certamente interessante e estamos curiosos para ver o que vem desse esforço relatado. Nos últimos meses, vimos a Oracle trabalhando em um back-end de eBPF para o GCC, além de complementar o suporte ao LLVM existente. Postado na quarta-feira também foram os últimos patches de suporte do eBPF para o GCC para direcionar esta máquina virtual no kernel.
LLVM 9.0-RC2 lançado e LLVM 10 muda para C ++ 14
O LLVM 9.0 Release Candidate 2 está agora disponível para testes, enquanto o LLVM 10.0 mudou sua base de código para o C ++ 14.
Hans Wennborg anunciou o segundo e esperado lançamento final para o LLVM 9.0 e sub-projetos associados como o Clang 9.0. O LLVM 9.0 está cerca de uma semana atrasado. Porém, ainda há tempo para que ele seja enviado dentro do prazo em duas semanas, caso contrário, parece que ele deve pousar um pouco no início de setembro.
No espaço de desenvolvimento LLVM 10 Git/SVN, entretanto, mudaram para o C ++ 14. O próprio LLVM há muito tempo suporta o C ++ 14 (trata-se de envolver o C ++ 20), mas essa mudança é sobre permitir que o desenvolvimento do LLVM seja feito com os recursos modernos do C ++ 14, em vez de limitados ao C ++ 11.
Isso está batendo os requisitos mínimos da versão C ++ para construir o LLVM e seus subprojetos. Embora qualquer compilador dos últimos anos esteja em boa forma para lidar com a construção do LLVM 10.
Via Phoronix
