Los ingenieros de Red Hat están trabajando para solucionar el problema de que la especulación restringida de ramas indirectas (IBRS) es demasiado costosa para mitigar Spectre V2 y Retbleed en los procesadores escalables Intel Xeon más antiguos. Se lanzó un nuevo parche para deshabilitar IBRS cuando está inactivo y está funcionando bien al menos para Red Hat Enterprise Linux 9, aunque aún no está claro si se aceptará en el kernel ascendente.
El parche de Waiman Long de Red Hat explica los problemas que aún enfrentan en relación con Intel IBRS para lidiar con Spectre y Retbleed:
Para los procesadores Intel que necesitan activar IBRS para protegerse contra Spectre v2 y Retbleed, el bit IBRS en SPEC_CTRL MSR afecta el rendimiento de todo el núcleo, incluso si solo un subproceso lo enciende cuando se ejecuta en el kernel. Para aplicaciones con mucho espacio de usuario, el impacto en el rendimiento de encender IBRS ocasionalmente durante las llamadas al sistema no debería ser significativo. Desafortunadamente, ese no es el caso cuando el subproceso hermano está inactivo en el núcleo. En ese caso, el impacto en el rendimiento puede ser significativo.
Cuando DPDK se ejecuta en un subproceso de CPU aislado que procesa paquetes de red en el espacio del usuario mientras su subproceso hermano está inactivo. El rendimiento del subproceso DPDK ocupado con IBRS activado y desactivado en el subproceso inactivo hermano es:
IBRS activado IBRS desactivado
—————
paquetes/segundo: 7,8M 10,4M
promedio de ciclos tsc/paquete: 282,26 209,86
Esta es una degradación del rendimiento del 25 %. El sistema de prueba es una CPU Intel Xeon 4114 a 2,20 GHz.
Esta serie de parches desactiva IBRS cuando está en varios modos inactivos para eliminar el impacto en el rendimiento del subproceso inactivo en su subproceso hermano ocupado.
Ay, un 25 % de éxito en Xeon Scalable Skylake para el Data Plane Development Kit (DPDK) de código abierto.
Hay este subproceso del kernel donde se flota el parche para desactivar IBRS cuando está inactivo. Sin embargo, el destacado ingeniero de Intel Linux, Peter Zijlstra, ha sugerido otro parche que actualmente no está adaptado a RHEL9. Además, la posibilidad de usar Call Depth Stuff/Tracking en lugar de IBRS. En mis pruebas, el seguimiento de profundidad de llamadas que se encuentra en la línea principal de Linux 6.2+ ofrece ayudar a recuperar parte del rendimiento perdido en las CPU de la era Intel Skylake que, de lo contrario, dependen de IBRS. Así que veremos a dónde va la actividad del kernel ascendente o si Red Hat termina llevando este parche como parte de su kernel RHEL9 por el momento hasta que vuelva a portar nuevas opciones. En cualquier caso, este último hilo de la lista de correo del kernel continúa mostrando los dolores de mitigación que aún experimentan los usuarios empresariales de Linux a mediados de 2023 en plataformas más antiguas.
