O Linux pretende mudar o padrão para algumas de suas atenuações de Spectre

Confira !!

Os desenvolvedores do kernel Linux upstream estão procurando mudar alguns de seus padrões de mitigação de Spectre em torno do que é aplicado aos encadeamentos SECCOMP por padrão, em parte devido ao impacto no desempenho, bem como por outros motivos.

Para atenuar a Variante Dois do Espectro e a Variante Quatro do Espectro (Desativação do Bypass do Armazenamento Especulativo - SSBD), os encadeamentos SECCOMP veem a atenuação por padrão, enquanto outros encadeamentos dependem de controles por encadeamento via prctl. Os desenvolvedores do kernel Linux de empresas como Red Hat e Google estão agora procurando não aplicar as mitigações por padrão aos threads SECCOMP para as mitigações Spectre V2 / V4.

O SECCOMP é o modo de computação seguro do Linux e usado por softwares como QEMU, OpenSSH, systemd, Snap e muito mais. Até agora, pelo menos as atenuações, a menos que o uso de substituições de parâmetro do kernel aplique suas atenuações por padrão a todos os threads SECCOMP.

Andrea Arcangeli, da Red Hat, apresentou uma proposta para evitar o padrão SECCOMP e, em vez disso, transformar o comportamento padrão em optar pela interface prctl. Essa mudança levaria ao mesmo efeito que inicializar qualquer versão do kernel Linux atual com as opções de "spec_store_bypass_disable = prctl spectre_v2_user = prctl."

Consulte o RFC vinculado para o esboço completo das razões argumentadas, mas a breve sinopse é: "Em última análise, definir SSBD e STIBP por padrão para todas as prisões seccomp é um ponto ideal e ruim com mais contras do que prós que acabam reduzindo a segurança na nuvem pública (dando um grande incentivo para não expor SPEC_CTRL que seria necessário para ficar cheio segurança com IBPB após definir nosmt no convidado) e prejudicando excessivamente o desempenho para aplicativos mais seguros usando seccomp que acabam tendo que ser desativados com SECCOMP_FILTER_FLAG_SPEC_ALLOW. "

Kees Cook do Google acrescentou :"Acordado. Acho que este é o momento certo para virar esse interruptor. Concordo com os (muito bem descritos) fundamentos. :) Fundamentalmente, provavelmente todos que estão interessados ​​em manipular as atenuações estão fazendo isso agora, e não faz mais sentido (em muitas frentes) amarrar alguns ao modo seccomp (que pretendia ser uma defesa temporária para obter cobertura enquanto sysadmins absorveram quais deveriam ser as melhores práticas). "

Vamos continuar monitorando para ver se / quando essa mudança será aceita.

Fonte

Até a próxima !!