Durante anos o desenvolvimento do kernel Linux vem se preparando para o ano 2038 e esta tarefa continua em execução na janela de merges da versão 4.18.
Para os que não estão familiarizados com o problema, os sistemas Unix-like utilizam um padrão de tempo chamado Unix time-stamp que começa em 1 de Janeiro de 1970 e quem (ainda) utiliza um signed int 32-bit para armazenar data terá o último segundo marcado em 19 de Janeiro, hora 03:14:07 UTC. Quando o bit do próximo segundo for virado os sistemas voltarão para a data original e comportamentos não adequados podem ocorrer com os softwares.
Como o kernel Linux possui cerca de 20 milhões de linhas de código, mitigar este problema de forma que englobe todas as arquiteturas de processador suportas não tem sido uma tarefa fácil e continua gerando novos merge requests. As partes do Kernel que precisam de adequação devem adotar o mecanismo COMPAT_32BIT_TIME e fazer limpezas de código que geram bastante trabalho. O último merge request que se tem notícia implementa tal mecanismo para SySV IPC UAPI.
Y2K38 é tão grave assim?
Pode parecer um exagero mas não possuímos “emuladores de catástrofes” que possam avaliar os riscos e a extensão dos danos de uma CPU embarcada em operações de uma usina ou de equipamentos médicos(marca-passo) usando um Unix-like vulnerável ao y2k38, como foi explicado pelo Theo de Raadt na EuroBSDCon de 2013. O OpenBSD 5.5 foi um release especial deste OS tratando da conversão do tempo para 64 bits em todo o sistema, motivo pelo qual o Theo bateu bastante nesta tecla em 2013 e 2014 e cobrou uma atitude de outros sistemas operacionais abertos.
Outro detalhe: Mesmo com o surgimento de novos processadores 64 bits o 32-bit ainda é o rei dos embarcados quando se trata de equipamentos de rede. Alguns destes dispositivos possuem um hardware contador 32bit signed para armazenar a data e a troca de signed para unsigned não é trivial e exigiria no mínimo a implementação de um contador por software que adicionaria 1 bit de sobrevida(68 anos) ao dispositivo, tentando gerar um overhead menor que uma implementação de tempo de 64 bits. É claro que esta solução não passa de uma gambiarra que poderia aumentar consideravelmente a latência em sistemas críticos como microcontroladoras e dar uma dor de cabeça grande para propagar esta solução para o restante dos dispositivos.
Esta matéria do site LWN também explica detalhes das falhas que softwares essenciais para o Linux terão se nada for feito nestes “apenas 20 anos” que restam para corrigir o problema.
Fonte: Phoronix
