Confira !!
Existem algumas correções urgentes pendentes para o processamento especulativo da execução x86 / x86_64 para o kernel Linux, após um engenheiro de segurança do Google descobrir esses problemas, incluindo uma das correções que tratam de uma situação que impactou injustamente as CPUs AMD.
Na fila desta manhã, em x86 / urgente, estão várias correções nas atenuações especulativas de execução do kernel Linux.
O primeiro é uma questão sobre a força que desativa o IBPB com base no STIBP e no IBRS aprimorado. Esse manuseio incorreto da Barreira de Previsão de Filial Indireta (IBPB) em algumas condições pode afetar as CPUs AMD contra as recomendações da AMD e também levar os aplicativos a serem silenciosamente vulneráveis aos ataques da Variante Dois do Espectro. Anthony Steinhauser, do Google, que descobriu esses problemas, explicou: "Quando o STIBP não está disponível ou o IBRS aprimorado está disponível, o Linux desativa a força do IBPB do Spectre-BTB, mesmo quando o multithreading simultâneo está desativado. Embora as tentativas de ativar o IBPB usando prctl (PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, ...) falhem com EPERM, o syscall seccomp (ou seu equivalente em prctl (PR_SET_SECCOMP, ...)) é usado, por exemplo, por Chromium ou OpenSSH, sem erros, mas com êxito o aplicativo permanece silenciosamente vulnerável a ataques Spectre v2 entre processos (envenenamento clássico por BTB). Ao mesmo tempo, o relatório SYSFS exibe que o IBPB está habilitado condicionalmente quando, na verdade, está desabilitado incondicionalmente. O STIBP é útil apenas quando o SMT está ativado. Quando o SMT está desativado e o STIBP está indisponível, não faz sentido forçar a desativação também do IBPB, porque o IBPB protege contra ataques Spectre-BTB entre processos, independentemente do estado SMT. Ao mesmo tempo em que o STIBP ausente foi observado apenas nos processadores AMD, a AMD não recomenda o uso do STIBP, mas recomenda o uso do IBPB, desativando assim
O IBPB por falta de STIBP vai diretamente contra o conselho da AMD. "
Steinhauser também acrescentou", o IBRS aprimorado foi projetado para proteger os ataques de envenenamento e envenenamento de BTB entre núcleos do espaço do usuário contra o kernel (e ataques de envenenamento de BTB do convidado contra o hipervisor), não foi projetado para impedir o processo cruzado (ou envenenamento de BTB entre VMs) entre processos (ou VMs) em execução no mesmo núcleo. Portanto, mesmo com o IBRS aprimorado, é necessário liberar o BTB durante as alternâncias de contexto, para que não haja motivo para forçar a desativação do IBPB quando o IBRS aprimorado estiver disponível. "
Para que a primeira correção esteja habilitando o controle da Barreira de Previsão de Filial Indireta, mesmo quando os Preditores de Filial Indireta com Rosca Única não estiverem disponíveis ou a Especulação Restrita de Filial Indireta com Aprimoramento estiver disponível.
Um segundo problema descoberto e agora com um patch pendente é o desligamento não autorizado do processo especulativo de desvio de armazenamento (SSBD). Esse problema é sobre uma otimização na mitigação de SSBD que deu errado. A otimização está tentando evitar uma gravação MSR dispendiosa, mas foi considerada incorreta e pode permitir que um invasor interrompa a proteção SSBD de um processo vítima e, assim, exponha a Variante Quatro do Espectro. "É explorável se o invasor criar um processo que impõe o SSBD e possuir o valor contrário do STIBP que o processo da vítima (ou seja, se o processo da vítima aplicar o STIBP, o processo do invasor não deverá aplicá-lo; se o processo da vítima não aplicar o STIBP, o o processo do invasor deve aplicá-lo) e agendá-lo no mesmo núcleo que o processo da vítima. Se a vítima corre atrás do atacante, ela se torna vulnerável ao Spectre V4. "
Arredondar esse lote de bugs do Linux com especulação x86 / x86_64 hoje é um problema em que é possível ativar a especulação indireta de ramificação mesmo depois de ter sido desativada à força. Para piorar a situação, o comando prctl speculation control pode então relatar que foi desativado à força mesmo quando a especulação indireta do ramo está ativada "Atualmente, é possível ativar a especulação indireta de ramificação, mesmo depois de ter sido desativada à força usando a opção PR_SPEC_FORCE_DISABLE. Além disso, o comando PR_GET_SPECULATION_CTRL fornece posteriormente um resultado incorreto (desativado à força quando na verdade é ativado). Isso também é inconsistente em relação ao STIBP e a documentação que afirma claramente que PR_SPEC_FORCE_DISABLE não pode ser desfeita. Corrija isso, aplicando a especulação de ramificação indireta desativada por força. "
Essas três correções de especulação do Linux estão na fila esta manhã em x86 / urgente. Eles devem ser atualizados em breve e portados para todas as séries estáveis suportadas, para esses buracos bastante significativos no atual processamento especulativo de execução pelo kernel Linux. Também é a segunda terça-feira do mês, para ver se outras divulgações de vulnerabilidades são feitas hoje.
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário