Início » Aplicativos e Software » Linus Torvalds rejeita correção “estúpida” da Amazon para Linux

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

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

Emerson Alecrim Por

Linus Torvalds é conhecido por não economizar palavras quando está contrariado. No episódio mais recente, ele rejeitou uma correção desenvolvida por um engenheiro do Amazon Web Services (AWS) para o Linux por considerá-la uma grande estupidez.

Computador Lenovo com Ubuntu Linux

No início do ano, Pawel Wieczorkiewicz, engenheiro do AWS, descobriu que é possível vazar dados do cache LD1 de determinados processadores Intel Core e Xeon a partir da exploração de um método de bus snooping — o truque consiste, essencialmente, em monitorar o cache para fazer uma captura de dados quando houver mudança nas informações existentes ali.

Algum tempo depois da divulgação da falha — que foi identificada como CVE-2020-0550 — Balbir Singh, também engenheiro do AWS, propôs uma correção para Linux que permite a softwares limpar o L1D assim que uma tarefa for finalizada para evitar que dados sejam vazados após uma mudança de contexto no cache.

O patch com esse recurso foi adicionado ao Linux 5.8. Porém, após revisão do código do kernel, Linus Torvalds resolveu tirá-lo de lá. Para ele, essa é uma solução “estúpida”, pois pode afetar o desempenho do sistema.

“Parece que isso basicamente exporta instruções de liberação de cache para o espaço do usuário e dá aos processos um jeito de dizer ‘desacelere qualquer outra coisa que eu agendar junto'”, explicou Torvalds.

Linus Torvalds

Linus Torvalds

Em outras palavras, o patch pode até ter algum efeito protetor sobre os dados do cache, mas permite que o software que faz uso dessa instrução degrade o desempenho da CPU para outros aplicativos. Isso porque, presumivelmente, a limpeza do cache pode remover dali dados de outros processos.

Essa discussão ilustra o quão difícil é para os mantenedores do kernel tratar de bugs relacionados a processadores. Não raramente, os “efeitos colaterais” podem inviabilizar as soluções propostas. De todo modo, o patch poderá ser aplicado ao Linux se os engenheiros do AWS puderem convencer Torvalds de que a correção apresentada realmente tem valor.

Com informações: The Register, ZDNet.

Comentários da Comunidade

Participe da discussão
7 usuários participando

Os mais notáveis

Comentários com a maior pontuação

Fabio Thiago Da Silva (@Neo_One)

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?

² (@centauro)

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

Fabio Thiago Da Silva (@Neo_One)

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.

João Eduardo Medeiros (@joaomedeiros95)

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.

Giovani (@Giovani)

Ó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.

Fabio Thiago Da Silva (@Neo_One)

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

Sérgio (@trovalds)

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?

Caleb Enyawbruce (@Enyawbruce)

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

Sérgio (@trovalds)

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.

Sérgio (@trovalds)

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.

Caleb Enyawbruce (@Enyawbruce)

show, obrigdo!