O Kernel Linux Obtendo Nova Opção então, o SSBD não é super-protetor - ajudando no desempenho

Confira !!



Para o manuseio de desativação de desvio de armazenamento especulativo (SSBD) do kernel do Linux para proteção do Specter Variant 4, há suporte para processos que optam pela desabilitação forçada da especulação por meio de uma interface prctl (). Atualmente, quando a especulação é desativada, isso é realizado para novos processos iniciados através da chamada de sistema execve (). Mas um novo bit permitirá limpar esse estado quando um novo programa for iniciado por um processo que, de outra forma, depende de PR_SPEC_DISABLE, no que ajudará o desempenho em tais casos.

Enfileirado para introdução ao kernel Linux principal é um novo PR_SPEC_DISABLE_NOEXECopção para prctl como parte das opções de Desativação de Armazenamento Específico da Loja, mas onde o estado é limpo em chamadas execve (). A premissa é que os programas que optam por desabilitar a especulação estão fazendo isso, mas os programas que não são vulneráveis ​​às irregularidades relacionadas à especulação normalmente não estão verificando se o bit PR_SPEC_ENABLE está definido e assumindo apenas o status quo. Assim, com o comportamento PR_SPEC_DISABLE atual, programas gerados via execve () podem ser protegidos quando eles realmente não precisam ser e carregando com isso a sobrecarga de desempenho adicional.

Processos usando execve () e sabendo que esses programas não precisam dessa proteção especulativa serão capazes de definir o bit PR_SPEC_DISABLE_NOEXEC para indicar como tal e, assim, garantir o desempenho ideal para esses programas.

Waiman Long, da Red Hat, autor do patch agora enfileirado em tip.git explica:

Com o modo padrão SPEC_STORE_BYPASS_SECCOMP / SPEC_STORE_BYPASS_PRCTL, o bit TIF_SSBD será herdado quando uma nova tarefa for forjada ou clonada. Ele também permanecerá quando um novo programa for executado.  

Apenas determinadas classes de aplicativos (como Java) que podem ser executadas em nome de vários usuários em um único encadeamento exigirão a desativação do desvio de armazenamento especulativo para fins de segurança. Esses aplicativos chamarão prctl (2) no tempo de inicialização para desabilitar o SSB. Eles não confiam no fato de o SSB ter sido desativado. Outros aplicativos que não precisam do SSBD irão apenas seguir em frente sem verificar se o SSBD foi ativado ou não.  

O fato de que o TIF_SSBD é herdado através do limite execve (2) fará com que o desempenho dos aplicativos que não precisam do SSBD, mas de seus antecessores, tenham o SSBD impactado involuntariamente, especialmente se eles gravarem muito na memória.

Obviamente, os aplicativos que desejam o comportamento atual podem continuar usando esse bit ou o PR_SPEC_FORCE_DISABLE se quiserem forçar a funcionalidade SSBD e não permitir que ela seja potencialmente desfeita.


Fonte

Até a próxima !!