¿Hyper-Threading es un riesgo de seguridad fundamental?

Desde que Intel introdujo Hyper-Threading (conocido genéricamente como Multi-Threading simultáneo), los debates sobre si desactivar o no la función han girado casi por completo en torno a su impacto en el rendimiento. Cuando la función debutó, no era inusual que los programas malinterpretaran lo que significaba que un sistema tuviera un núcleo de CPU virtual en lugar de un segundo chip físico (en ese entonces, era un núcleo por socket, sin excepciones, y los programas no diferenciaron entre un núcleo de CPU físico y uno lógico). A medida que se actualizaron el software y los sistemas operativos, HT se estabilizó y hoy en día es menos común tener que apagarlo para preservar el rendimiento. Pero a raíz de Spectre, Meltdown y Foreshadow, se han planteado serias preocupaciones sobre las implicaciones de seguridad de Hyper-Threading.

Theo de Raadt, el fundador de OpenBSD, sostiene que ya no se puede confiar en HT y debería estar deshabilitado por defecto. 2007es.com se acercó a De Raadt para discutir el problema y por qué él y otros desarrolladores de la comunidad de software de código abierto están preocupados por los riesgos de seguridad de Hyper-Threading.

Según de Raadt, cada sistema operativo agrega la capacidad de deshabilitar el subprocesamiento múltiple simultáneo (el Hyper-Threading de Intel es una implementación específica de SMT) o modifica sus programadores 'para evitar la coincidencia en cpus SMP de diferentes dominios de seguridad'. El multiprocesamiento simétrico, o SMP, se refiere a la práctica moderna de tener múltiples núcleos de CPU en un solo dado, todos con acceso a un conjunto combinado de memoria y dispositivos. Por el contrario, Hyper-Threading de Intel comparte ciertos recursos entre el núcleo físico y su contraparte lógica, incluidos los búferes de búsqueda de traducción (TLB), la caché de datos L1 y la caché de destino de rama (BTC) sin proporcionar ninguna capacidad para diferenciar entre dominios de seguridad y aislar los datos entre los dos núcleos de la CPU.



Como hemos comentado anteriormente, Spectre, Meltdown y Foreshadow son defectos que explotan cierto comportamiento en el que participan las CPU de Intel cuando ejecutan instrucciones de forma especulativa. Si bien la ejecución especulativa es una técnica probada y de larga data para mejorar el rendimiento general de la CPU, de Raadt identifica tres problemas distintos que se han combinado para crear estos problemas. El escribe:

1) Las CPU Intel recuperan, decodifican y ejecutan instrucciones, incluidas las cargas de datos, sin realizar ningún control de seguridad, y luego las desenrolla si estaban equivocadas después del hecho. Las CPU de otros proveedores han experimentado problemas menores con el espectro, pero Intel lo lleva a un nivel completamente nuevo.

2) Dado que no realizan comprobaciones de seguridad por adelantado y vinculan su L1D a su TLB, Intel tiene un error realmente asombroso 'de dónde vino una línea de caché, no nos importa' en su caché L1D, que da como resultado los datos en una línea de caché de un dominio de privilegios diferente se vuelven visibles para instrucciones especulativas, lo que crea un problema de espectro adicional.

3) La misma especulación sin control de seguridad se aplica a los registros. Intel ni siquiera verificó si la FPU está habilitada, antes de acceder a los registros de FPU. Por lo que realmente no hacen * ningún control de seguridad * antes de ejecutar una instrucción. TODAS las decisiones se toman al final. Eso significa que TODAS las secuencias de instrucciones tienen efectos secundarios espectrales, y simplemente estamos esperando que las personas encuentren peores consecuencias y las publiquen.

de Raadt también criticó las políticas de divulgación de Intel, señalando que OpenBSD ha tenido que estudiar soluciones alternativas en otros proyectos, como Xen y FreeBSD, para crear sus propias soluciones. Él cree que es probable que sigamos viendo más fallas de seguridad relacionadas con Spectre y que existe la posibilidad de que los sombreros negros combinen diferentes métodos de explotar estas fallas para romper los modelos de seguridad. Presagiar, se podría argumentar, es uno de esos ataques. Si bien es más complejo que las primeras variantes de Spectre, también se puede usar para romper las eXtensiones de protección de software de Intel, o SGX, y se suponía que SGX era inmune a este tipo de ataque. Incluso existe la posibilidad de que estos ataques se puedan utilizar para filtrar información de direcciones, lo que significa que Spectre y Rowhammer podrían combinarse. Es el regalo que sigue dando.

Imagen de XKCD. Flavor text: 'Además de Rowhammer, resulta que muchos servidores también son vulnerables a los martillos regulares'.

Hasta ahora, OpenBSD es el primer sistema operativo que pide deshabilitar HT por completo; la guía oficial de Intel es que HT no necesita deshabilitarse si se han implementado todas las demás correcciones y parches. Pero es increíblemente difícil garantizar prácticamente que todos los contextos de seguridad necesarios se mantendrán y respetarán en ausencia de restricciones de hardware que impidan que dos procesos diferentes que operan en diferentes dominios de seguridad se ejecuten al mismo tiempo. Incluso si puede asegurarse de que los procesos que se ejecutan en una CPU sean compatibles desde la perspectiva del dominio de seguridad, tan pronto como el dominio de seguridad de uno de esos procesos cambie, tendrá que desalojarlo del núcleo de la CPU en el que se está ejecutando y colocarlo en otro lugar, vaciando las cachés y TLB en el proceso. Los programadores de sistemas operativos modernos mueven regularmente cargas de trabajo a través de los núcleos de la CPU para optimizar la ejecución, pero obligar a una CPU a hacer esto en nombre de la seguridad puede tener un gran impacto en el rendimiento. Ya hemos visto alguna evidencia de esto en Spectre, aunque las pruebas que lo expusieron tendieron a ser los peores escenarios.

¿Se ve afectada la AMD?

Hasta ahora, casi toda la discusión sobre Spectre, Meltdown y Foreshadow se ha centrado en Intel. Hay una razón práctica para esto. Se cree que estos ataques amenazan la seguridad de los proveedores de servidores empresariales y en la nube, e Intel domina estos mercados. Antes del lanzamiento de Epyc, Intel tenía el 99% del mercado de servidores x86 y la inmensa mayoría de los servidores vendidos por año son máquinas x86. AMD ha comenzado a reducir el dominio del mercado de Intel, pero la directora ejecutiva Lisa Su ha declarado que su empresa apunta a porcentajes medios de un solo dígito del mercado para fines de 2018. Incluso si AMD e Intel estuvieran igualmente expuestos técnicamente, Intel estaría asumiendo virtualmente toda la exposición efectiva.

Pero aunque esto podría cambiar en el futuro, la evidencia actual sugiere CPU AMD no son casi tan vulnerables como sus homólogos de Intel. AMD ha publicado una declaración que indica que no se ve afectado por Foreshadow, que Intel llama L1TF (Falla de terminal L1). Recomienda a sus clientes no implementar Presagia las protecciones en este momento y afirma que sus CPU están protegidas por protecciones de arquitectura de paginación de hardware integradas en las CPU Epyc.

AMD-SMT-Zen

Una prueba adicional a favor de AMD es que se sabe que la implementación de SMT de la empresa es diferente de la de Intel. Anteriormente, solo discutimos estas diferencias en términos de su impacto en el rendimiento, pero la diapositiva anterior señala que las ITLB L0 / L1 / L2 y las DTLB L1 / L2 se comparten pero tienen 'etiquetas SMT', lo que significa que solo se puede acceder a ellas. por el hilo que los posee. El diablo está absolutamente en los detalles sobre temas como este, y no queremos dar a entender que esta sola diapositiva establece el grado en que la implementación de SMT de AMD es o no segura, pero AMD parece haber implementado protecciones en ciertas áreas que Intel carece. Es posible, por ejemplo, que los ataques futuros se basen en desalojos de caché en lugar de cargas especulativas, y este tipo de etiquetado podría no proteger contra estas alternativas. En nuestra conversación, de Raadt señala que OpenBSD también ha realizado cambios para deshabilitar SMT y CMT (esa es la tecnología de intercambio de núcleos de Bulldozer) en las CPU de AMD por precaución, a pesar de no saber si las CPU finalmente demostrarán ser vulnerables a esto. tipo de ataque.

En el momento de escribir este artículo, OpenBSD 6.4 (previsto para octubre / noviembre) es el primer sistema operativo que evita todo uso de Hyper-Threading y lo deshabilita de forma predeterminada, pero otros sistemas operativos, como Red Hat, han anunciado que enviarán kernels con controles actualizados que permitan a los usuarios elegir si deshabilitar la función o no. El hecho de que otros proveedores sigan el ejemplo de Theo de Raadt puede depender de las divulgaciones de vulnerabilidades siguientes y de la gravedad de la siguiente ronda de exploits. Intel ha anunciado que su próxima plataforma Cascade Lake contendrá correcciones de hardware para algunas variantes de Spectre, mientras que otras aún serán mitigadas por soluciones de software o una combinación de las dos. Ese es un punto en el que todos en la industria de la seguridad parecen estar de acuerdo: habrá nuevas divulgaciones y problemas de seguridad relacionados con Spectre que aún no han sucedido.

Ahora lee: ¿Qué es la ejecución especulativa?, Intel detalla las mitigaciones de hardware de Cascade Lake para Meltdown, Spectrey Nueva falla de seguridad presagiada rompe Intel SGX

Copyright © Todos Los Derechos Reservados | 2007es.com