Los problemas derivados de Spectre van a dar dolores de cabeza durante mucho tiempo, puede que incluso más de una década si tenemos en cuenta los planes de Intel para combatir las vulnerabilidades que empezaron a ser publicadas a principios del presente año y que afectaron a todas las grandes marcas y arquitecturas de CPU.

La principal preocupación de solucionar Meltdown y mitigar Spectre (ya que el segundo es, al menos de momento, irresoluble) giraba en torno al impacto negativo que la aplicación de los parches tendrían en el rendimiento. Si bien este no fue tan dramático como se pintó en un principio, parece que todo cambiará a partir de Linux 4.20, que ha despertado fuertes y fundamentadas preocupaciones en este sentido.

En Linux 4.20 se ha incluido una mitigación contra los ataques Spectre v2 llamado Single Thread Indirect Branch Predictors (STIBP), que estaría habilitada por defecto en la mencionada versión del kernel en sistemas Intel que utilicen un microcódigo actualizado (sí, otro problema que parece solo golpear a la compañía con sede en Santa Clara). STIBP no viene sola, ya que según informan desde ZDNet, estará acompañada de otras actualizaciones de firmware como Branch Restricted Speculation (IBRS) y Indirect Branch Predictor Barrier (IBPB), las cuales pueden ser habilitadas a voluntad por los desarrolladores de sistemas operativos (los encargados de las distribuciones).

Sin embargo, nos centraremos en STIBP, que a fin de cuentas es la fuente de los problemas de rendimiento detectados en Linux 4.20. Básicamente se encarga de corregir los escenarios de ataque en ordenadores que hagan uso de Hyper-Threading, la implementación de la tecnología SMT de Intel. La situación ha llegado al extremo de ser bastante grave, lo que ha forzado a Linus Torvalds a tomar cartas en el asunto al detectarse, según palabras que él mismo ha recogido, una disminución en el rendimiento de hasta el 50% en algunas cargas.

¿Qué ha propuesto Torvalds para resolver esta situación? Pues no habilitar la mitigación STIBP por defecto, ya que desde la configuración de la BIOS o UEFI se puede inhabilitar SMT (Hyper-Threading para los usuarios de Intel) por completo, algo que satisfacería las demandas de las personas más preocupadas por la seguridad. La postura del ingeniero informático finés pinta derivar más del pragmatismo que otra cosa, ya que no tiene sentido habilitar por defecto un parche que disminuye el rendimiento del kernel hasta en un 50%.

¿Estamos ante el principio del fin de SMT? Viendo que desde Linux empieza a verse su desactivación como una medida a contemplar para evitar ataques de canal lateral y la publicación este mes de PortSmash, parece que el futuro de esta característica tan común en la última década quedará en entredicho, y es que a veces tomar atajos puede terminar saliendo muy caro.