Varios parches en revisión, destacando: Un uso incorrecto de la barrera en la predicción de saltos indirectos puede tener un impacto en el rendimiento de las CPUs AMD al contravenir las recomendaciones de AMD y también conlleva exponer inadvertidamente a las aplicaciones a ataques de la variante 2 de spectre. Un segundo problema descubierto es debido a una optimización que intenta evitar operaciones de escritura muy costosas pero que permitiría a un atacante sobrepasar ciertas protecciones y exponer a procesos a la variante 4 de spectre.
Comentarios
#5 No es exactamente de la arquitectura. El problema es que el todo es más que la suma de las partes. En este caso concreto, la ejecución especulativa per-se no tiene ningún fallo. Tampoco las memorias caché tienen tales fallos. El problema es al combinar ambas cosas, ahí es cuando surge el problema.
Ahora la cuestión que sin ejecución especulativa Y cachés, es imposible conseguir rendimientos decentes. Volveríamos a la época del Pentium.
#8 Todo lo que describes se puede resolver con una nueva arquitectura.
#10 Perfecto. Pues si quieres, te dejo una libreta y vas empezando.
Digo yo que si fuese tan sencillo no afectaría a TODOS los procesadores con ejecución predictiva y caché, sin importar su arquitectura ni juego de instrucciones. Porque lo que tú pretendes es tirar a la basura dos paradigmas (no "arquitecturas") que han demostrado su validez desde hace más de cuarenta años.
#11 Claro, por que los diseñadores de las arquitecturas previas no eran conscientes de esos retos durante el diseño y las "mejoras" que se han incorporado en una si han sido exitosas se han incorporado en otras, incorporando también problemas comunes.
Si diseñas desde cero siendo consciente de los problemas que se han encontrado las arquitecturas previas tienes mucha ventaja sobre el resto y puedes incorporar todo lo que ha traído problemas de forma no añadida si no desde el diseño base para que no tenga la misma tipología de problemas que las arquitecturas anteriores.
#12 A ver... creo que nos estamos liando porque tú hablas de una cosa y yo de otra. Es cierto que hay algunos fallos de esta familia que solo afectan a Intel. En ese caso te doy toda la razón. Pero lo que yo digo es que esos fallos pertenecen a una categoría más general, la cual afecta no sólo a los procesadores de Intel; ni siquiera sólo a la arquitectura x86 (o x86-64), sino a absolutamente cualquier procesador que utilice los paradigmas de "memoria cache" y "ejecución especulativa", y da igual que sea un core i9 de última generación, un Zen, un MIPS, un PowerPC, un ARM o incluso un Z80 (si es que hay alguno que tenga ejecución especulativa). Ahí no se trata de un problema de arquitectura, sino de una característica emergente de la unión de esos dos paradigmas, y la solución no es tan sencilla como "tirar el diseño actual a la basura y hacer uno desde cero", pues, como digo, no es un fallo de diseño, sino un fallo inherente a la unión de ambos paradigmas.
#13 El motivo por que tienes que unir dos paradigmas es por que la arquitectura inicial no incorporaba el segundo paradigma. Es algo añadido a posteriori intentando no romper la compatibilidad con lo anterior.
De ahí que proponga que una arquitectura nueva, que se diseñe con conocimiento de los problemas de las anteriores, pudiera resolver el problema.
#14 Tu no propones una arquitectura nueva, tu propones un paradigma nuevo... Y eso puede suponer, si no se pueden implantar sobre dicho paradigma las arquitecturas actuales, que no se puedan ni siquiera recompilar los programas actuales.
Por otro lado, fíjate en el problema que hubo con el Itanium... quien ganó fue AMD con x86-64, porque no obligaba ni siquiera a recompilar.
#15 Obviamente lo que he propuesto no he dicho que fuera fácil ni que fuera compatible con lo anterior. Es una propuesta de solución drástica a un problema que no parece tener final.
#16 Hombre, ya... pero el mercado te va a decir que ni de coña... Como te digo, con el Itanium la intención de Intel era cambiar la arquitectura completamente para implantar unos 64 bits "limpios", y mantener la compatibilidad hacia atrás mediante una emulación. En cambio AMD sacó x86-64... Y ya ves... Microsoft dijo que se negaba a mantener dos arquitecturas de 64 bits, la emulación en Itanium no era buena, x86-64 daba el mismo rendimiento que x86 y añadía 64 bits... y ya ves lo que hizo el mercado.
#17 Itanium nunca fue viable más allá del mundo de los servidores. Incluso allí lo tuvo muy complicado por sus peculiaridades: eran muy caros de producir, consumían bastante y era muy muy complicado optimizar las cosas (así que no le sacaban rendimiento a la inversión).
Fíjate que con ARM es todo lo contrario (son muy baratos, consumen poco y es muy fácil optimizar para ellos) y pese a todo les está costando entrar un montón en el mercado servidor. Y ni siquiera ha tenido mejor suerte en el mercado casero (me refiero a ultraportátiles y demás, salvo los chromeos) por la misma razón que el itanium nunca saltó al mismo: la compatibilidad con otras arquitecturas y software es un dolor (en implementación y en pérdida neta de rendimiento).
Aparte ARM tiene otra desventaja: demasiadas familias derivadas de ARM dispersan los esfuerzos y provocan incompatibilidades de software entre ellas, en lugar de compartir y aunar esfuerzos que les beneficien a todas. La X86_64 tenía toda la inercia y ventajas del mundo y así triunfó. Lo que lastra al x86 ahora es la falta de competencia/fabricantes/innovación más allá de Intel y AMD. En su momento VIA atacó por la parte del consumo, pero la gente pedía rendimiento... si hubieran sido más fuertes, quizá ahora podrían tener presencia en otros nichos como tablets y móviles y podrían estar dando guerra también en servidores.
#18 Si me estás dando la razón
#19 No pensaba quitártela, simplemente matizar (porque Itanium nunca desembarcó en los ordenadores domésticos).
(como comentario personal más allá de la noticia, algunas optimizaciones para intentar que las mitigaciones hagan perder menos rendimiento a las CPUs afectadas han resultado ser armas de doble filo... o hay ingenieros haciendo mal su trabajo por descuído, o hay mucho interés por parte de cierto fabricante en recuperar el rendimiento perdido a toda costa, sin descartar la opción paranóica de que están tratando de desmontar los parches que limitan el poder espiarnos a todos; eso sin contar que otro de los parches perjudica claramente a la competencia, no sé en qué grado ni si ha sido de forma premeditada, pero ahí está)
Que inventen una nueva arquitectura y empezamos de cero.
#3 El problema no (sólo) es la arquitectura, es el diseño de ciertas funcionalidades de las arquitecturas modernas (la ejecución especulativa, los problemas de coherencia y seguridad en cachés multinivel en entornos multiproceso y multiprocesador y más allá en nodos de computación heterogeneos, etc). Estamos llegando a un nivel en la complejidad del diseño de procesadores que es muy fácil no pensar en todos los casos posibles que puedan darse y a la vez también es muy sencillo meter la pata.
Hoy en día hay una cierta flexibilidad debido a que puedes descargarte microinstrucciones, los procesadores pueden "flashearse" hasta cierto punto para poder añadir y corregir cosas (no todo es hard hard), pero aún así es muy complicado.
#4 Pues eso, la arquitectura.
#5 Ya sabía Intel que tenía que tirar por VLIW cuando presentó los Itanium
#4 Entiendo lo que dices.
Curiosamente cuando salio el fallo de la coma flotante de los primeros Pentium, Intel prefirió enviar CPUs nuevas a "flashear" las CPUs. Decían que por tema de seguridad, pero es algo que nunca entendí. ¿Si no lo utilizas en un fallo tan grave, para que das la opción de actualizar?
Ahora si que intentan mitigar mediante parches los ataques tipo spectre, pero tampoco lo consiguen solucionar.
#7 Es que no es lo mismo modificar una microinstrucción (que no sé si en época del pentium ya había esa posibilidad; aquí están los microcódigos actualizados de los fabricantes de x86 (no sé qué identificador tiene cada modelo): https://github.com/platomav/CPUMicrocodes) durante el arranque que cambiar físicamente el chip. Me da que el problema estaba en algún punto de las unidades de ejecución de números flotantes y por lo tanto no era arreglable con un cambio en las microinstrucciones.
Por seguridad porque era un error que sólo se daba en unas condiciones muy determinadas y que en el día a día en principio no iba a afectar a nadie (para un uso personal). Pero ponte en la piel de una empresa financiera, un sólo error de cálculo y a saber las implicaciones que podría tener eso. O en la industria, donde la precisión es un valor muy importante.
El problema de mitigar es que es eso, hacer más difícil que puedan aprovechar un problema que hay y que no tiene solución. El problema sigue ahí, sólo que gracias a que metes instrucciones por medio, controlas mejor los saltos, etc. consigues mediante software que sea muchísimo más complicado conseguir las condiones idoneas que son necesarias para explotar el fallo. Compáralo con los fallos por el efecto del año 2000, es un fallo de diseño de hardware, pero se puede hacer software que detecte cuándo se va a dar y conseguir interpretar correctamente los valores a partir de entonces (y de hecho, se hizo). Se podría decir que se ha mitigado el fallo, pero en realidad el fallo sigue ahí, y si tu parche de software no está lo suficientemente bien hecho, hay programas que todavía podrían sufrir sus efectos.
Han sido enviados de manera urgente, están en proceso de revisión y probablemente pronto estén portándose a los distintos kernels con soporte y distribuyéndose por parte de las distros.