Confira !!
Como parte do conjunto inicial de alterações hoje mescladas no Linux 5.8, estava o material x86 / mm que incluía o recurso controverso da liberação opt-in do cache de dados L1 na alternância de contexto . Linus Torvalds acabou decidindo reverter essa funcionalidade, por enquanto, pelo menos ele a vê como louca.
Embora esse recurso seja ativado por meio de novas opções prctl e não seja ativado por padrão e feito em nome de ajudar os interessados em vulnerabilidades de amostragem de dados assistida por bisbilhoteiros ou vazamento de cache por canais laterais e ainda a serem descobertas vulnerabilidades de CPU, por enquanto Linux o criador Linus Torvalds não está convencido.
Aqui estão os destaques de seu comentário que ele acabou de postar na lista de discussão do kernel desta alteração no PR x86 / mm:
Estou lendo errado isso?
Porque, para mim, isso basicamente exporta instruções de liberação de cache para o espaço do usuário e fornece aos processos uma maneira de dizer "diminua a velocidade de qualquer outra pessoa com quem eu agendar".
Não vejo uma maneira de um administrador do sistema dizer "isso é estúpido, não faça isso".
Em outras palavras, pelo que posso dizer, isso pega o código louco de "CPUs da Intel com buggy e causa problemas para virtualização" (com os quais eu não ligava muito), e o transforma em "qualquer um pode optar por esta doença , e agora afeta até pessoas e CPUs que não precisam e configurações onde é completamente inútil ".
Para piorar as coisas, ele tem um fallback de descarga de SW que nem sequer é arquitetônico do que eu lembro da última vez em que foi discutido, mas certamente perderá muito tempo analisando os movimentos que podem ou não liberar o L1D depois de tudo.
Eu não quero que algum aplicativo funcione "Oh, eu sou muito especial e bonita e uma flor tão delicada, que desejo liberar o L1D em cada comutador de tarefas, independentemente da CPU em que estou, e independentemente de haver são erratas ou não ".
Como esse aplicativo não está apenas diminuindo a velocidade, também está diminuindo os outros.
Tenho dificuldade em saber se tudo isso pode ter como resultado as condicionais de ramificação estática do STIBP e, portanto, pode ser pelo menos limitado apenas às CPUs com problema em primeiro lugar.
Mas acabei retirando o valor porque não consigo descobrir isso, e as explicações nos commits não esclarecem (e implicam que seja independentemente de qualquer outra errata, já que é para "erratas futuras não descobertas").
Porque eu não quero uma bandeira aleatória "Eu posso fazer o kernel fazer coisas estúpidas" para as pessoas optarem. Eu acho que precisa de uma dupla aceitação.
No mínimo, o SMT ativado deve desativar completamente esse tipo de pseudo-segurança maluca, pois é completamente inútil nessa situação. O agendamento simplesmente não é um ponto de sincronização com o SMT ativado; portanto, dizer "claro, vou liberar o L1 na troca de contexto" é mais do que estúpido.
Eu não quero que o kernel faça coisas que parecem "além de estúpidas".
Porque eu realmente acho que isso é apenas RP e pseudo-segurança, e acho que há um custo real em fazer as pessoas pensarem "ah, sou tão especial que devo permitir isso".
Estou mais do que feliz em saber por que estou errado, mas por enquanto estou descartando por falta de dados.
Talvez isso nunca aconteça no SMT por causa de todas essas regras sutis de ramificação estática, mas eu realmente gostaria que isso fosse explicado.
Veremos se o engenheiro da Amazon responsável por este patch original funciona, os outros envolvidos na revisão do código, ou a equipe de código aberto da Intel, têm justificativa suficiente para recuperar esse código no kernel Linux principal.
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário