Linus Torvalds rejeita correção "estúpida" da Amazon para Linux

Originally published at: https://tecnoblog.net/344152/linus-torvalds-rejeita-correcao-kernel-linus-amazon-aws/

Para Linus Torvalds, correção para bug apresentada por engenheiros do AWS pode prejudicar desempenho do Linux

Pergunta honesta para os especialistas: neste caso a possível perda de desempenho seria mesmo assim tão significativa a ponto de ser mais viável ter uma brecha de segurança no sistema?

1 curtida

Isso vai depender do que você considera perda de desempenho “significativa” e a gravidade da brecha de segurança no sistema.

4 curtidas

Meu vídeo que renderiza em 30 min agora renderiza em 32 min, meu jogo que rodava a 65 fps agora roda a 60. Troco tudo isso pela solução de segurança. Meu vídeo renderiza em 45 min ao invés de 30 min. Meu jogo não passa de 30 fps. Opa, agora acho que não vale tanto a pena assim. Porém, ao analisar a descrição da falha na metéria creio que ela seja mesmo problemática em servidores.

6 curtidas

Pra você realmente não faria muito sentido a perda de desempenho mas lembre-se que o Linux é usado em diversas aplicações e servidores não só para pessoas finais.

Muitas aplicações de alta performance até usam algumas técnicas para ter dados do tamanho dos Caches do processador para que elas não fiquem saindo do cache no meio do processamento, quanto mais saídas e entradas do cache maior será o tempo de processamento já que principalmente o Cache L1 é infinitamente mais rápido que a memória RAM.

Trabalhei com uma aplicação de alta performance e gerenciar exatamente o uso desses Caches faz muito diferença para processamentos muito pesados.

Espero ter ajudado a esclarecer o ponto do Linus.

10 curtidas

Ótima a sua forma de perguntar, apesar de eu não saber a resposta para a pergunta não pude deixar de comentar, fico triste quando o Zé la do interior da floresta tropical chega chutando o balde nos comentários, dizendo que o “inventor” do negócio está errado, e ele que está certo, porque é melhor perder desempenho do que ter uma falha e blablabla. Acontece muito em noticias de operadoras de celular, a empresa XYZ testa bilhões de conexões durante meio ano, mas quem ta certo é o “Jaum”, porque ele não conseguiu 100Mb na rede apontada como líder pela pesquisa e portanto é mentira.

4 curtidas

Ajudou sim João, obrigado por responder. Imaginei mesmo o problema sendo maior em servidores e comentei isso na seguinte resposta Linus Torvalds rejeita correção "estúpida" da Amazon para Linux - #5 por Neo_One

1 curtida

O problema é que a solução proposta seria submetida ao kernel pra tudo mundo. Até aí nada demais. Mas o texto o Linus explica bem a questão e o patch pode afetar sobremaneira o desempenho. E isso em se tratando de mercado corporativo e computação na nuvem, pode refletir em aumento de custos para as empresas que contratam serviços da amazon, por exemplo.

Explicando grosseiramente: os serviços da Amazon de uma forma geral são cobrados de acordo com o tempo usado para processar determinado bloco de dados. Digamos que você gaste, digamos, 200 minutos por dia de processamento normalmente. Com esse patch, basicamente o tempo poderia aumentar de 200 minutos pra 210 minutos. Parece pouco mas multiplique isso por 30. São mais 300 minutos de processamento por mês na sua conta. E isso é apenas um exemplo hipotético de um serviço pequeno. Agora imagina uma Netflix da vida que usa os serviços da Amazon, o quanto isso impactaria na despesa?

2 curtidas

Nao teria uma forma de limitar a limpeza aos dados do próprio software?

Ter tem. A grosso modo:

O processo PODE informar ao cache que ele foi encerrado e limpar os dados que usou. Até aí OK.

MAS aí começam os problemas:

  • Pro processo fazer isso, ele consome tempo. E isso impacta em performance.
  • Em alguns casos os dados são compartilhados por vários processos diferentes (ou várias instâncias do mesmo processo). Se uma instância for terminada e limpar os dados, o processo vai ter que reconstruir o cache, o que novamente custa tempo de processamento.

E o cache é justamente pra… ganhar tempo de processamento armazenando informações que um determinado processo usa com frequência.

Enquanto a Intel não repensar a arquitetura de cache e colocá-la no mercado, existem algumas saídas pras empresas de infraestrutura: conviver com a falha a custo de comprometer os dados próprios e/ou de clientes, conviver com o processamento extra a custo de ter suas receitas encolhendo ou repassando isso pra quem usa o serviço OU na mais radical das situações começar uma migração de infraestrutura para processadores da AMD, que estão livre de quase todas essas falhas.

2 curtidas

O seu umbigo é só seu.

A Intel e o mercado não estão dando a mínima pros usuários domésticos. O problema se chama mercado corporativo. Infraestrutura com milhares de servidores trabalhando 24/7 em que um impacto de 1s na performance de 1 processador pode custar HORAS de processamento. Aquela indexação de um banco de dados de 10 bilhões+ de registros que levava 2 horas e agora leva 3 horas (e que é um processo crítico que compromete o acesso sobremaneira), a Netflix pagando por milhares de hora/CPU a mais pra Amazon pra processar o mesmo volume de informações e mais milhares de empresas em que cada segundo ganho em um processamento significa milhares de horas a mais em questão de produtividade e que com as vulnerabilidades perderam isso e mais.

A Intel está em uma enrascada jurídica enorme por causa dessas falhas. Se as empresas tiverem cada vez mais que fazerem remendos a custo de performance em suas infraestruturas, os custos vão ter que ser pagos por alguém. E das duas uma: ou vai ser o consumidor ou vai ser a Intel. E eu aposto que vai pipocar uma ação das grandes contra a empresa azul na casa dos bilhões de dólares pelos prejuízos causados pelas falhas.

show, obrigdo!

1 curtida

Este tópico foi automaticamente fechado após 92 dias. Novas respostas não são mais permitidas.