Recientemente el líder del desarrollo del Kernel de Linux Linus Torvalds propuso revisar el mecanismo para activar los parches STIBP (Predictores de rama indirecta de hilo único), que ofrecen protección adicional contra las vulnerabilidades de clase Spectre v2.

Estos parches se han incluido recientemente en la rama del Kernel de Linux 4.20 en desarrollo y se han vuelto a exportar a la versión estable del Kernel de Linux 4.19.2.

Al usar STIBP en su forma actual, los usuarios notaron una disminución significativa en el rendimiento de algunas aplicaciones al usar esta tecnología de subprocesamiento múltiple simultánea (SMT o Hyper-Threading).

Dado que la caída del rendimiento puede llegar a alcanzar el 50%, según a palabras del propio Linus Torvalds, el uso de STIBP en su forma actual no tiene sentido, ya que es más fácil y más confiable desactivar SMT / Hyper-Threading por completo, lo que las personas conscientes de la seguridad suelen hacer.

La mayor desaceleración causada por el nuevo kernel de Linux 4.20 se debe a una mitigación para la variante 2 de Specter que el fundador de Linux, Linus Torvalds, ahora quiere restringir.

Aquí es cuando surge la pregunta de si que es necesario habilitar el STIBP de manera predeterminada, cuando SMT / Hyper-Threading ya está deshabilitado para aquellos que realmente se preocupan por la seguridad.

Mientras que, para los usuarios normales, una pérdida de rendimiento del 50% es un factor significativo que puede representar algunas cuestiones y que es dudoso que valga la pena bloquear estas vulnerabilidades teóricas.

Torvalds exige que STIBP ya no se habilite de forma predeterminada

Por su parte Linus Torvalds considera que es poco probable que surjan ataques prácticos basados ​​en Spectre v2, ya que, en los sistemas de usuarios normales.

Linus Torvalds argumenta que los navegadores son el objetivo principal de los ataques, que ya han agregado protección a su nivel (la amenaza es para procesos JIT aislados para los cuales se puede desarrollar un método de protección selectiva).

Se propone utilizar por defecto solo los métodos de protección de Spectre, que no conducen a una gran caída en el rendimiento, sino que utilizan métodos adicionales de forma selectiva o como opción.

Entonces, ¿por qué ese STIBP se ralentiza de forma predeterminada cuando las personas que * realmente * se preocupan ya deshabilitan el SMT?

Creo que deberíamos usar la misma lógica que para L1TF: de manera predeterminada, no podemos eliminar el rendimiento. Avise una vez al respecto y deje que los locos digan “Prefiero tener un 50% de éxito en lugar de preocuparme por un problema teórico”. Linus Torvalds

El uso predeterminado de STIBP se debe revertir

Por otro lado, Arjan van de Ven, de Intel, dijo que por la parte de Intel y AMD no recomiendan el uso de STIBP de forma predeterminada, ya que esta funcionalidad puede compararse con un martillo muy pesado, dado que no se usa en el trabajo diario, pero es necesario en ciertas circunstancias.

El argumenta que el mecanismo STIBP propuesto en la actualización del microcódigo le permite controlar el apagado de las memorias caché del procesador mediante la configuración de un bit especial en el registro CR0, que no debe hacerse en todas partes, pero solo en situaciones particularmente críticas.

Tim Chen de Intel, propuso que el bloqueo selectivo de los ataques de espacio aislado incluyan a STIBP solo cuando este se solicite explícitamente a través de prctl o para procesos que prohíban la creación de volcados de memoria central (PR_SET_DUMPABLE), como sshd.

En cuanto a la caída del rendimiento cuando se usan parches STIBP en el Kernel de Linux 4.20, el resultado depende en gran medida del tipo de carga.

Por ejemplo, las pruebas que se han realizado han demostrado que en el paquete SpecInt Rate 2006 muestran una reducción en el rendimiento del 21%, mientras que las pruebas de Phoronix muestran una degradación del rendimiento desde el 3% hasta un 20%.

Ingo Molnar un muy conocido desarrollador del Kernel de Linux y autor del Programador de tareas de CFS, comentando la situación, sugirió que se agregue la lista de cambios en la información de pruebas de rendimiento cuando se agreguen soluciones a los problemas.

El artículo Torvalds planteó la cuestión de una protección extendida contra Spectrev2 ha sido originalmente publicado en Linux Adictos.