Alguns meses atrás, a Intel publicou orientações sobre o modo de instrução Data Operand Independent Timing (DOIT) que pode ser ativado com gerações recentes de processadores Intel. Isso serve para garantir a execução de tempo constante para um subconjunto do conjunto de instruções Intel. Assim, pode ser particularmente importante para algoritmos criptográficos. As discussões do desenvolvedor do kernel Linux fracassaram no ano passado sobre como lidar com essa funcionalidade DOIT para o que é descrito como uma vulnerabilidade de CPU com CPUs Intel recentes. Portanto, agora um patch de kernel Linux de um desenvolvedor do Google permitiria essa mudança incondicionalmente para CPUs Intel mais recentes, mas levanta preocupações de desempenho. Desenvolvedores Linux tentam corrigir “DOITM” para as CPUs Intel mais recentes.
Porém, foi divulgado pela Intel, bem como pela Arm, que as instruções sobre processadores recentes e futuros não têm garantia de “tempo constante” com relação a seus operandos de dados, a menos que um sinalizador de registro específico de modelo especial seja definido.
Isso causou preocupações principalmente em relação ao código de criptografia para Linux de que não há mais garantia de tempo constante e que o tempo de execução da instrução pode variar dependendo dos dados operados.
Desenvolvedores Linux tentam corrigir “DOITM” para as CPUs Intel mais recentes
A execução em tempo constante é necessária para evitar possíveis ataques de canal lateral. Só que ao habilitar o novo sinalizador da Intel para garantir tempo constante, ele vem com implicações de desempenho admitidas. Desenvolvedores Linux tentam corrigir “DOITM” para as CPUs Intel mais recentes.
O engenheiro do Google e desenvolvedor de kernel Linux de longa data, Eric Biggers, enviou um patch esta semana para habilitar o controle Intel Data Operated Independent Timing Mode para o kernel Linux que habilitaria esse sinalizador por padrão para CPUs Intel mais recentes. Ele é habilitado por padrão, mas também fornece um botão para desabilitar essa mitigação/recurso de segurança.
Biggers descreveu o problema e a motivação com esta mensagem de patch:
De acordo com a documentação que a Intel publicou recentemente, as CPUs da Intel baseadas no Ice Lake e microarquiteturas posteriores não garantem “temporização independente do operando de dados” por padrão. Ou seja, os tempos de execução das instruções podem depender dos valores dos dados operados. Isso é verdade para uma ampla variedade de instruções, incluindo muitas instruções que são muito usadas em criptografia e sempre foram consideradas de tempo constante, por exemplo, adições, XORs e até mesmo as instruções AES-NI.
Os algoritmos de criptografia requerem instruções de tempo constante para evitar ataques de canal lateral que recuperam chaves criptográficas com base em tempos de execução. Portanto, sem atenuar essa vulnerabilidade da CPU, geralmente é impossível fazer criptografia com segurança nas CPUs Intel mais recentes.
Também é plausível que essa vulnerabilidade da CPU possa expor dados de kernel privilegiados a processos de espaço de usuário não privilegiados de maneira mais geral.
Para atenuar essa vulnerabilidade da CPU, é possível habilitar o “Data Operand Independent Timing Mode” (DOITM) definindo um bit em um MSR. Embora a documentação da Intel sugira que esse bit só deva ser definido onde “necessário”, isso é altamente impraticável, dado o fato de que a criptografia pode ocorrer em quase qualquer lugar no kernel e no espaço do usuário, e o fato de que todo o kernel provavelmente precisa ser protegido de qualquer maneira.
Notícias Relacionadas
Novos recursos
SmartThings e o suporte ao Matter 1.4: Como os roteadores Wi-Fi serão integrados
O SmartThings está se preparando para integrar o Matter 1.4, trazendo novos recursos, como suporte a roteadores Wi-Fi, dispositivos de energia e maior compatibilidade entre plataformas.
mudança de preços
Max vai cobrar pelo compartilhamento de senhas
Max irá começar a cobrar por compartilhamento de senhas, seguindo o exemplo de outras plataformas. Entenda a nova estratégia e o que isso significa para os usuários.
Portanto, vamos simplesmente ativar o DOITM globalmente por padrão para corrigir essa vulnerabilidade. No máximo isso abre mão de uma “otimização” nas CPUs mais recentes, restaurando o comportamento correto das CPUs anteriores.
A documentação do kernel proposta para a vulnerabilidade Data Operand Dependent Timing (DODT) resume a situação como:
DODT – Data Operand Dependent Timing
Data Operand Dependent Timing (DODT) é uma vulnerabilidade da CPU que faz com que os tempos de execução das instruções dependam dos valores dos dados operados.
Essa vulnerabilidade potencialmente permite ataques de canal lateral a dados, incluindo chaves criptográficas. A maioria dos algoritmos de criptografia exige que uma variedade de instruções seja de tempo constante para evitar ataques de canal lateral.
CPUs afetadas
Essa vulnerabilidade afeta os processadores da família Intel Core baseados em Ice Lake e microarquiteturas posteriores, e os processadores da família Intel Atom baseados em Gracemont e microarquiteturas posteriores.
Mitigação
A mitigação dessa vulnerabilidade envolve a configuração de um bit de Registro Específico de Modelo (MSR) para habilitar o Modo de temporização independente de operando de dados (DOITM).
Por padrão, o kernel faz isso em todas as CPUs. Essa mitigação é global, portanto, aplica-se ao kernel e ao espaço do usuário.
Esta mitigação pode ser desativada adicionando doitm=off à linha de comando do kernel. É também uma das mitigações que podem ser desativadas por mitigations=off.
A orientação publicada da Intel sobre Data Operand Independent Timing apresenta os claros riscos de desempenho desse modo operacional:
O DOIT requer a desativação de otimizações de hardware e/ou recursos de desempenho em alguns processadores; por exemplo, habilitar a temporização independente do operando de dados pode desabilitar a pré-busca dependente de dados. Isso significa que o modo DOIT pode ter um impacto no desempenho, e a Intel espera que o impacto no desempenho desse modo seja significativamente maior em processadores futuros.
A orientação da Intel é basicamente usar esse modo DOIT com moderação e para uso por software que já aplicou outras técnicas recomendadas pela Intel para mitigar os canais laterais de temporização do software. O kernel do Linux com sua enorme base de código construída ao longo dos anos não está necessariamente em sintonia com todas as técnicas de software recomendadas pela Intel. Um tanto preocupante é que este modo DOIT pode ser “significativamente maior” para futuros processadores.
É notavel que, com o patch da lista de discussão do kernel do Linux, não há números de desempenho ou indicações de quão severa é a penalidade de desempenho, supostamente devido à falta de hardware e à procura de testes da comunidade do kernel.
Seguindo aquele patch de Eric Biggers, a discussão do kernel se seguiu se todo o kernel precisava ser protegido, ou se seria possível apenas proteger as operações de criptografia dentro do kernel e, se não fosse por esse cobertor, como o espaço do usuário poderia ser adequadamente protegido também. Não há consenso neste ponto, mas dada a falta de números sólidos… Tenho disparado alguns benchmarks iniciais nos sistemas Intel da geração atual.
