Na semana passada, os desenvolvedores do Linux estavam avaliando uma nova mitigação de segurança "DOITM" para as CPUs Intel mais recentes . Embora o custo por enquanto de ativar a funcionalidade Data Operand Independent Timing Mode (DOITM) seja mínimo, seguindo as discussões internas de engenharia da Intel, parece que os patches do kernel Linux precisarão ser retrabalhados com essa funcionalidade que não deve ser sempre habilitada.
Conforme resumido no artigo de teste da semana passada, os processadores Intel recentes e futuros não têm garantia de "tempo constante" em relação aos seus operandos de dados, a menos que um sinalizador de registro específico do 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. A execução em tempo constante é necessária para evitar possíveis ataques de canal lateral. Mas ao habilitar o novo sinalizador da Intel para garantir tempo constante, ele vem com implicações de desempenho admitidas.
As implicações de desempenho com os processadores da geração atual não acabaram sendo tão significativas, mas a documentação da Intel indica que isso pode aumentar no futuro. Com o manuseio do Linux em sua forma atual, trata-se de sempre ter o Data Operand Independent Timing Mode ativado. Mas agora a Intel está alertando contra tal movimento.
Novas postagens da lista de discussão do kernel Linux dos engenheiros da Intel lançaram mais luz sobre isso. Este post observa que quaisquer patches DOITM devem esperar antes de serem colocados na linha principal:
Temos falado sobre isso dentro da Intel. Basta dizer que o DOITM não foi projetado para ser ativado o tempo todo. Se o software o ligar o tempo todo, ele não realizará o que foi projetado para fazer.
A coisa _mais_ provável que vai acontecer é que o DOITM seja redefinido para ter um escopo muito mais limitado. A arquitetura DOITM atual é muito ampla, mas as implementações têm efeitos muito mais limitados. Isso significa que a arquitetura provavelmente pode ser restrita e ainda corresponder ao hardware existente hoje. Isso é pura especulação (ha!) Da minha parte.
Acho que devemos adiar a fusão de quaisquer patches DOITM até que a poeira baixe. Tanto quanto eu sei, não há nenhuma razão prática premente para aplicar algo com urgência.
Um post de acompanhamento continua a observar:
Ele foi projetado com a ideia de que o código sensível ao tempo e *APENAS* sensível ao tempo seria agrupado com DOITM. Envolver esse código permitiria que o restante do sistema operasse com segurança com novas otimizações sofisticadas que exibem tempo dependente de dados.
Mas, antes de tudo, esse código não é agrupado com APIs de produção de DOITM hoje. Esse modelo desmorona com o software atual nas implementações DOITM atuais.
Em segundo lugar, consideramos que o kernel em geral é sensível ao tempo o suficiente para que desejemos o comportamento DOITM=1 no kernel.
Esses líderes de software definem DOITM = 1 o tempo todo. A consequência disso é que ninguém jamais usará essas novas otimizações sofisticadas. Se ninguém pode aproveitá-los, o silício não deve ser desperdiçado com eles em primeiro lugar.
Basicamente, o DOITM foi criado para abrir a porta para a adição de novas otimizações sofisticadas. É um fracasso se não fizer isso.
Espera-se que a Intel tenha mais informações para compartilhar sobre o assunto nos próximos dias, mas, para encurtar a história, parece que os patches de kernel do Linux propostos na semana passada provavelmente serão descartados / significativamente retrabalhados para que esse modo nem sempre esteja ativo.
Até a próxima !!
Nenhum comentário:
Postar um comentário