El cuelgue de los sistemas operativos Windows 95/98 tras 49.7 días
podría ser debido al desbordamiento de un registro de 32 bits.
El pasado 4 de Marzo, Hispasec envió un boletín en el que advertía que
Windows 95/98 podía colgarse tras 49.7 días de uso continuado. Dejando
al margen la dificultad de que algún usuario de dichos sistemas
operativos consiga mantener su ordenador el tiempo necesario para
poder verificar el problema, no hay ninguna explicación oficial
del mismo.
Numerosas personas, no obstante, se han dado cuenta de que en 49.7 días
hay 4294080000 milisegundos. Esa cifra es muy semejante a 2^32 =
4294967296. En otras palabras, un registro de 32 bits podría contar
4294967296 milisegundos o, lo que es lo mismo, 49’7103 días
(exactamente, 49 días, 17 horas, 2 minutos y 47’296 segundos).
El problema, por tanto, es semejante al que ocasionará en el 2000 el
desbordamiento de registros capaces de almacenar exclusivamente años
con dos dígitos.
Aunque resulta imposible ofrecer una explicación completa y segura sin
disponer del código fuente de Windows 95/98, podemos aventurar algunos
de los problemas que ocasiona un contador de milisegundos de sólo 32
bits, y que pueden provocar el cuelgue publicado.
Veamos un ejemplo:
En un sistema operativo existen multitud de procesos periódicos y
«timeouts». El funcionamiento general de los mismos es coger el tiempo
actual, sumarle el lapso que hay que dejar pasar, y esperar a que
transcurra dicho período. Por otro lado tenemos un proceso que se ejecuta
cada milisegundo, por ejemplo, y que incrementa en uno el contador de
«milisegundos transcurridos desde el arranque».
El proceso que se ejecuta cada milisegundo va incrementando el contador
y comprueba si se ha superado el tiempo de espera de alguno de los
procesos bloqueados en la cola de espera. Si es así, marca ese proceso
como «activo» para entregarle la ejecución.
Veamos ahora lo que ocurre:
Si un proceso dice al sistema que quiere esperar 50 milisegundos, por
ejemplo, y coincide que justo se desborda al contador de milisegundos,
tenemos la curiosa circunstancia de que:
tiempo actual + 50 milisegundos ES MENOR que tiempo actual.
Por tanto, el proceso que debía despertarse al cabo de 50 milisegundos
es invocado innmediatamente. Si lo primero que hace es planificar otra
temporización de 50 milisegundos (o se trata de una temporización
periódica automática), esa segunda instancia será ejecutada
instantaneamente. A su vez, dicha instancia planificará otra ejecución
en 50 milisegundos, que será ejecutada de inmediato y así sucesivamente.
En el caso de Windows las cosas no tienen que ser necesariamente así;
sencillamente ofrecemos una posible explicación al problema.
Por ejemplo, si el proceso en cuestión es un controlador que deshabilita
interrupciones (por ejemplo, el gestor de ratón), el sistema se quedará
bloqueado.
Lo que no es de ninguna forma justificable es que Windows tenga este
fallo.
Más información:
HispaSec
Microsoft
CNET
The Risks Digest
Deja una respuesta