Linus Torvalds chama de estúpido patch da AWS para Linux que corrige falha da Intel

Linus Torvalds chama de estúpido patch da AWS para Linux que corrige falha da Intel
linus

Linus Torvalds não perde a mania de usar palavras duras quando quer criticar algo. Desta vez, ele rejeitou um patch Linux da AWS para evitar ataque ao Intel CPU Snoop que classificou como ‘além de estúpido’. Linus simplesmente destruiu um patch dos engenheiros da Amazon Web Services (AWS) que visava mitigar o ataque Snoop às CPUs Intel. O problema foi descoberto por um engenheiro da AWS no início deste ano.

Os chamados ataques de ‘Amostragem de dados L1 assistida por Snoop‘ ou simplesmente Snoop (CVE-2020-0550) afetam uma variedade de CPUs Intel Xeon e Core e foram divulgados em março.

Por que Linus Torvalds chama de estúpido patch da AWS para Linux que corrige falha da Intel

O engenheiro da AWS Pawel Wieczorkiewicz descobriu uma maneira de vazar dados da memória de uma CPU Intel por meio de seu cache L1D, que fica nos núcleos da CPU, através de ‘bus snooping’ – a operação de atualização de cache que ocorre quando os dados são modificados no L1D.

Após a divulgação, o engenheiro da AWS Balbir Singh propôs um patch para o kernel Linux para que os aplicativos pudessem optar por liberar o cache L1D quando uma tarefa fosse desativada.

Isso impede que os dados sejam bisbilhotados ou vazem por canais laterais após a mudança de contexto da tarefa, explicou Singh em abril. O patch foi fornecido com o kernel Linux versão 5.8.

O recurso permitiria que os aplicativos, opt-in, chamassem o prctl (2) para liberar o cache L1D de uma tarefa assim que sair da CPU, supondo que o hardware o suporte.

O ataque de Linus

Mas, como observado pelo site Phoronix, Torvalds acredita que o patch permitirá que aplicativos que optarem pelo patch prejudiquem o desempenho da CPU para outros aplicativos.

Porque me parece que basicamente exporta instruções de liberação de cache para o usuário e fornece aos processos uma maneira de dizer ‘desacelere qualquer outra coisa’  escreveu Torvalds ontem. 

Em outras palavras, pelo que sei, isso pega o código ‘CPU da Intel com buggy e causa problemas para a virtualização’ do código (com o qual eu não me preocupo muito), e o transforma.  Isso afeta até pessoas e CPUs que não precisam dela e configurações onde é completamente inútil’.

Segurança falsa e maluca

A referência de Torvalds à virtualização foi direcionada à AWS que, como outros fornecedores de nuvem, vende CPUs virtuais frequentemente com o multithreading simultâneo (SMT) ativado.

Ele continua apontando que, com o SMT ativado, “deve desativar totalmente esse tipo de pseudo-segurança maluca, pois é completamente inútil nessa situação”.

No mínimo_, o SMT ativado deve desativar completamente esse tipo de pseudo-segurança maluca, pois é completamente inútil nessa situação, disse ele.

Em uma discussão com Singh, Torvalds observa que “liberar L1D $ no SMT” é uma loucura, uma vez que um invasor fica em um núcleo e ataca o conteúdo de L1 * antes * da troca de tarefas”.

Outros atores da discussão

Conforme observado pelo The Register, o engenheiro principal da AWS, Benjamin Herrenschmidt, também debateu sobre o patch em uma discussão com o colaborador do kernel do Red Hat Linux, Ingo Molnar.

Herrenschmidt admitiu que o patch não faz sentido com o SMT, mas contestou o argumento de que o patch era porque a AWS quer vender hiper threads como CPUs virtuais.

Sim, as VMs normalmente têm o SMT ativado. Porém, isso não é direcionado a elas. Um exemplo que foi dado durante as discussões foram os contêineres pertencentes a diferentes usuários, disse ele.

Outro exemplo seria um processo que lida com dados mais críticos, como informações de pagamento que o sistema deseja proteger (ou o administrador deseja que esse processo seja protegido) contra possíveis vazamentos de dados para processos menos confiáveis.

A AWS tem mais do que apenas VMs para alugar 🙂 Há uma pilha de ‘serviços’ de nível superior que nossos usuários podem usar e nem todos necessariamente executam em VMs por vCPU.

Herrenschmidt disse que os patches não estão tentando resolver os problemas que ocorrem dentro de uma VM de cliente executando SMT e tampouco sobre a proteção de VMs contra outras no mesmo sistema.

ZDNet

Acesse a versão completa
Sair da versão mobile