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.
Até a próxima !!
Nenhum comentário:
Postar um comentário