Confira !!
Acontece que o próprio Linus Torvalds foi até surpreendido com o acerto de desempenho que descrevemos no Linux 4.20 como resultado da introdução de "Preditor de Ramo Indireto de Sintaxe Simples" da STIBP, bem como o back-port de já para a série estável para hyperthread cruzado Proteção Spectre V2. Ele não quer isso ativado por padrão.
Todo o benchmarking que tenho feito nos últimos dias para esclarecer a adição do STIBP do kernel do Linux parece estar valendo a pena. Meus testes descobriram que o Linux 4.20 incorre em penalidades de desempenho significativas em muitas cargas de trabalho - na verdade, mais do que algumas mitigações anteriores de Specter e Meltdown - e o STIBP já está sendo transferido para séries estáveis como o Linux 4.19.2.PHP, Python, Java e muitas outras cargas de trabalho são afetados de forma mensurável e até mesmo o desempenho dos jogos em certa medida.
Linus Torvalds postou na lista de discussão do kernel no domingo com um título de STIBP por padrão. Reverter? . Lá ele escreveu:
Isto foi marcado por estável, e honestamente, em nenhum lugar da discussão eu vi qualquer menção de quão ruim o impacto no desempenho disso foi.
Quando o desempenho cai em 50% em algumas cargas, as pessoas precisam começar a se perguntar se valeu a pena. É aparentemente melhor apenas desabilitar a SMT por completo, que é o que as pessoas conscientes da segurança fazem de qualquer maneira.
Então, por que essa STIBP abrandou por padrão quando as pessoas que * realmente * se importam já desativaram o SMT?
Eu acho que devemos usar a mesma lógica que para L1TF: nós definimos como padrão algo que não mata performance. Avise uma vez sobre isso e deixe as pessoas loucas dizerem "Eu prefiro ter um desempenho de 50% do que me preocupar com uma questão teórica".
Linus
Ele também seguiu com: " Eu não acho que o código precise ser revertido, mas o * comportamento * de apenas habilitar incondicionalmente o STIBP precisa ser revertido. Porque era claramente muito mais caro do que as pessoas eram informadas. "
Por muito tempo o kernel developer Andi Kleen até argumenta agora que o código deve ser revertido. "Na verdade, acho que deveria ser revertido. Sim, é claro, opt-in é necessário. Mas também quando você opt-in não faz sentido definir STIBP quando o irmão está executando o mesmo contexto de segurança, que na verdade é um caso comum Então, para até mesmo usá-lo corretamente, você precisaria de algum suporte ao agendador para detectar esses casos e apenas habilitá-lo, com o opt-in. Esses patches nem tentaram resolver esse problema. "
O veterano da Intel Linux, Arjan van de Ven, disse: "Na documentação, a AMD recomenda oficialmente contra isso por padrão, e eu posso falar pela Intel que a nossa posição também é: isso não deve ser ativado por padrão. STIBP e seus amigos estão lá como ferramentas, e foram criados desde cedo como grandes martelos porque isso é tudo o que se pode adicionar em uma atualização de microcódigo .. martelos grandes e caros ... Usar essas ferramentas muito mais cirurgicamente é bom, se uma tarefa paranoica quiser por exemplo, ou quando você sabe que está fazendo uma transição de segurança hard core. Mas sempre ligado?
Com alguns patches ainda em revisão, o comportamento padrão do STIBP será apenas habilitá-lo para tarefas que o solicitem via processos prctl ou não dumpable como o daemon OpenSSH. Mas mesmo o manuseio geral de processos não-dumpable a serem protegidos pelo STIBP está levantando algumas preocupações também, provavelmente acabando afetando alguns daemons sensíveis ao desempenho, então vamos ver o que acaba acontecendo.
Pelo menos agora, com muita atenção no STIBP, parece que uma abordagem sadia para proteger os processos do sistema quando necessário, sem prejudicar o desempenho geral do Linux, será alcançada quando o Linux 4.20 for lançado no final de dezembro ou início de janeiro. Mas é lamentável que esses patches do STIBP já tenham sido portados e lançados como parte do Linux 4.19.2, então esperamos que quaisquer mudanças sejam transferidas rapidamente também.
Até a próoxima !!
Nenhum comentário:
Postar um comentário