Um hack feio dentro do kernel Linux que está na linha principal há mais de três anos foi anunciado. Devido a um buggy X.Org Server / xf86-video-modesetting DDX, o kernel Linux tem imposto um comportamento diferente sobre se um processo inicia com "X" e, por sua vez, desabilita o suporte de configuração de modo atômico.
O pesquisador de segurança do Linux Jason Donenfeld (que também é conhecido por criar o WireGuard), se deparou com esse hack feio de código dentro do kernel.
Donenfeld comentou neste fim de semana na lista de discussão do kernel :
Isso reverte 26b1d3b527e7 ("drm/atomic: Tire os brinquedos atômicos de X"), um kludge tipo rootkit que não tem nada a ver dentro de um kernel de uso geral. É o tipo de hack de depuração que usarei momentaneamente, mas nunca cometerei, ou uma espécie de truque de malware babbies-first-process-hider.
A história de fundo é que algum código de espaço do usuário - xorg-server - tem um DDX de configuração de modo que não está realmente codificado corretamente. Com ninguém querendo mais manter o X11, em vez de corrigir o código com bugs, o kernel foi ajustado para evitar ter que tocar no X11. Uma chatice, mas é justo: se o kernel não quiser mais suportar alguma API de espaço do usuário, a coisa certa a fazer é providenciar um fallback gracioso onde o espaço do usuário pensa que não está disponível de maneira gerenciável.
No entanto, a *forma* de fazer isso é apenas verificar `current->comm[0] == 'X'`, e desativá-lo apenas para esse caso. Então isso significa que *não* é simplesmente uma questão de o kernel não querer mais suportar uma API de espaço de usuário específica, mas sim o kernel não querer suportar xorg-server, em teoria, mas na verdade, acontece que são todos os processos que comece com 'X'.
Jogar jogos com current->comm como este é obviamente errado, e é muito chocante que isso tenha sido cometido.
A confirmação para este kernel com a verificação do primeiro caractere "X" foi feita em setembro de 2019. O argumento nessa confirmação do kernel Linux na época era:
O -modesetting ddx tem uma ideia totalmente quebrada de como o atomic funciona:
- não desabilita conectores antigos, supondo que eles sejam desabilitados automaticamente como com o setcrtc legado
- assume que ASYNC_FLIP está conectado para o atomic ioctl
- nem uma única chamada para TEST_ONLY
[Em outras palavras] a implementação é uma tradução 1:1 do legado ioctls para atomic, que é a) quebrado b) inútil.
Já temos bugs tanto no i915 quanto no amdgpu-DC, onde isso nos impede de habilitar recursos interessantes.
Se alguém se importa com o atômico em X, podemos facilmente adicionar um novo nível atômico (req->value == 2) para X para recuperar os brinquedos brilhantes.
Como essas versões quebradas de -modesetting foram enviadas, não há outra maneira de sair desse vínculo.
A "boa" notícia é que, desde então, no lado do espaço do usuário, em 2019, o código xf86-video-modesetting foi em frente e desativou o suporte atômico por padrão. Então, tecnicamente, se estiver executando uma pilha X.Org atualizada nos últimos três anos, esse hack do kernel não é mais necessário, pois o espaço do usuário está evitando a API atômica.
Veremos se Linus Torvalds concorda com a remoção desse hack, pois, afinal, ele vai contra seu princípio de "não quebrar o espaço do usuário" ao regredir o sistema se ficar com uma pilha desatualizada do X.Org Server e querer executar com uma versão futura do kernel. Veremos, mas surpreendentemente, levou três anos para que esse código sujo fosse criticado.
Até a próxima !!
Nenhum comentário:
Postar um comentário