La innovación en microprocesadores está en la base del progreso tecnológico: una industria que demanda velocidades de ejecución cada vez mayores, y que ha generado un progreso enorme a lo largo de las últimas décadas. Por eso, las nuevas vulnerabilidades descubiertas en los microprocesadores de todos nuestros dispositivos modernos y comunicadas de manera general ayer, Meltdown y Spectre, tienen un nivel de criticidad tan sumamente elevado, aunque en la práctica poco podamos hacer con respecto a ellas.
¿Qué deberíamos saber al respecto? Fueron descubiertas por investigadores en seguridad: la primera, Meltdown, se debe al trabajo independiente de tres equipos en la Universidad Técnica de Graz, en Cyberus Technology y en Google Project Zero; la segunda, Spectre, también en Google Project Zero y por el investigador Paul Kocher. El descubrimiento, como ocurre en muchas ocasiones en cuestiones relacionadas con la seguridad, se remonta a hace algunos meses, durante los cuales han podido presuntamente ocurrir cosas como que algunos de los implicados se preparasen para ofrecer seguridad a sus usuarios, y otros se dedicasen a vender rápidamente acciones de sus propias compañías.
¿En qué consisten? Todos los microprocesadores modernos utilizan una serie de capacidades de ejecución especulativa para los accesos de memoria: el microprocesador no solo lleva a cabo lo que le pedimos, sino que dedica una parte de sus recursos a especular que una condición determinada, por ejemplo, será verdadera, y a llevar a cabo los accesos a memoria correspondientes a que así fuese, y así optimizar su tiempo de ejecución. Si finalmente esa especulación no resulta cierta, las instrucciones ejecutadas especulativamente son descartadas. Sin embargo, aunque esa especulación y ese descarte no tienen ningún efecto en la ejecución de los programas (además de acelerarla, que no es poco), sí producen cambios en los componentes del microprocesador, tales como, por ejemplo, cargar determinados datos en la cache. La presencia de esos datos en la memoria cache o en otros componentes del microprocesador es detectable porque su acceso es más rápido que si no estuvieran ahí, y eso podría permitir el acceso a información sensible. Básicamente, hablamos de vulnerabilidades que, en el caso de Meltdown, rompen la frontera entre las aplicaciones del usuario y el sistema operativo, permitiendo así que un programa malicioso pueda acceder a la memoria y, por tanto, a datos de otros programas o del propio sistema operativo. En Spectre, más difícil de explotar que Meltdown pero también más difícil de parchear o solucionar, hablamos de la ruptura del aislamiento entre distintas aplicaciones, lo que permite que una aplicación maliciosa pueda engañar a otras aplicaciones sin errores para obtener datos de las mismas.
Todos los microprocesadores modernos utilizan ejecución especulativa, y de hecho, es una funcionalidad que está en la base de sus prestaciones y que los microprocesadores de Intel llevan a cabo de una manera particularmente agresiva. Los parches que se han puesto en marcha hasta el momento son una primera solución, ponen bajo control o eliminan las funciones especulativas, y provocan al hacerlo pérdidas de prestaciones de hasta un 30%. Renunciar a la ejecución especulativa no parece el camino a seguir, y la solución final podría demorarse bastante tiempo, durante el cual, indudablemente, surgirán actores capaces de explotar las vulnerabilidades en sistemas que no hayan sido parcheados. Algo tan evidente como que debes aplicar los correspondientes parches de seguridad no es en realidad tan sencillo: aunque en muchos casos esos parches se aplican de manera automática, no todos los usuarios tienen la cultura adecuada como para aplicarlos regularmente. Pero además, la solución debe considerarse como algo temporal: a lo que nos dirigimos es a un replanteamiento fundamental sobre el uso de la ejecución especulativa en microprocesadores, un proyecto de nueva arquitectura que solucione estos problemas de la manera adecuada que llevará mucho tiempo.
¿Es normal que pasen estas cosas? Sí, desgraciadamente, es lo que tiene que la industria avance a la velocidad que avanza. ¿Quiere decir que todo es vulnerable? ¿Estás en riesgo? Si simplemente usas un dispositivo, lo normal será que no, porque las vulnerabilidades no son suficientes – o no en su estado actual – para, por ejemplo, comprometer tu máquina a través de su navegador. Apple, por ejemplo, ha confirmado que todos sus dispositivos, tanto ordenadores como smartphones, están afectados, aunque no se conoce todavía ningún esquema de ataque, y dado que dichos ataques precisan de una aplicación o programa instalado en el dispositivo, recomiendan instalar únicamente software procedente de fuentes fiables. El riesgo fundamental es para los proveedores de servicios de computación en la nube, que por lo general ya habrán aplicado los correspondientes parches a costa de un descenso en su rendimiento, con todo lo que ello conlleva en términos de coste. Básicamente, un problema para el que no vas a poder hacer nada más – ni nada menos – que seguir una serie de instrucciones cuando estas vayan llegando, que debería servirte para extremar la precaución y las rutinas de seguridad – nunca es malo que lo hagas – y que se mueve a unos niveles que están muy por encima del usuario común.
This post is also available in English in my Medium page, “Vulnerable microprocessors: what are Meltdown and Spectre?»
Hay algo que no me cierra, y tal vez sea muy pronto para plantearlo, pero existe algo que se llama «pagar el precio» o «hacerse responsable de las consecuencias». Está claro que AMD se verá claramente beneficiada, al menos a nivel imagen e Intel no.
Pero eso es de rebote. Quisiera ver cómo se desarrollan los hechos y como ellos se hacen responsables de sus actos. Y con quién.
Una disculpa de parte de Intel no me va a acelerar la máquina en el porcentaje que se reduzca. La aceptación o la sumisión tampoco.
No hablo de tomar medidas, pero u hoy me levanté muy ingenuo o tengo un nivel de perplejidad que desconocía en mí.
El fallo tendrá consecuencias gravísimas para Intel. Al estar muy cerca de ser un monopolio en procesadores de puesto de trabajo y servidor no siente la necesidad de incrementar la innovación ni la fiabilidad de sus productos. Es lo que tienen los monopolios, éste ingenuamente creado por la industria (clientes y proveedores de servicios).
«… Quisiera ver cómo se desarrollan los hechos …» … Pues hombre como siempre, eso es como cuando el Penumbra dice «tal dia vendrán los extraterrestres» … llega tal dia y se le pregunta «¿ pero hombre donde estan ? » contesta que estan entre nosotros, dias mas tarde ya te avisará el Sombrita de que se han ido … pues lo mismo estas cosas de la informatica los procesadores, te avisan que van a venir, luego que aqui estan, y luego que se fueron, y hasta la proxima, como lo del 2000 del milenio y doble cifra y eso …
:D entiendo el contexto más no los personajes. Igual, gracias por tu respuesta Garepubaro.
Después de enviar el mensaje me acordé del Diesel Gate y entendí que eso de «pagar el precio» es un preocupante síntoma de que todavía tengo algo de esperanza viva dentro de mí… ahora mismo lo arreglo…
No creo que halla nada malo en ti ni que tengas que olvidarte de la esperanza. Simplemente esto de Intel y en el caso de Europa lo del diésel, son muestras de que vivimos en una época en la cual se ha perdido la ética y el sentido de responsabilidad. Actualmente uno puede nadar por la vida haciendo cagadas sin tener que afrontar las consecuencias de sus actos. Hay quienes dicen que la diferencia entre los animales y los humanos radica justamente en esa capacidad de decidir hacerse cargo de los actos propios, y por ende, de sus consecuencias.
De vuelta a Intel, parece no haber poder político alguno capaz de someter su cinismo y soberbia y que permite que una disculpa sea suficiente cuando no lo es.
Es inconcebible que una empresa del tamaño de Intel, que recluta a lo mejor del planeta y que invierte en desarrollo e innovación más que muchos países en 10 años no haya notado que tenía un error de diseño monumental y lo hayan dejado pasar como si nada.
De ese tamaño es su embuste.
Como usuarios particulares no sé hasta qué punto deberíamos preocuparnos por la posibilidad de vernos afectados por algún malware que haga uso de estas vulnerabilidades, al menos creo que no más de lo que debemos preocuparnos a diario para evitar cualquier malware más corriente. Además, según las noticias estas vulnerabilidades pueden ser explotadas sobre todo en sistemas virtualizados, usados sobre todo por las empresas de cloud computing (y las que deberían pedir responsabilidades millonarias). ¿Pero que hay de los usuarios domésticos? Pues en principio parece que tendremos que soportar un preocupante descenso en el rendimiento de nuestros PCs si queremos estar tranquilos.
Hace pocos meses actualicé mi ordenador a un i5 para poder editar vídeo HD con soltura. Ahora tengo que aceptar que quizá la bajada de rendimiento por aplicar un parche haga que mi procesador vuelva a arrastrarse al editar un vídeo, aunque todavía no he encontrado información exacta sobre acerca de los procesos que se verán más afectados.
De momento lo que voy a hacer es crear dos particiones con dos sistemas operativos: uno sin parchear y totalmente aislado del mundo, sin información sensible y con el software estrictamente necesario para editar vídeo. Y otra partición, esta vez con el parche de marras, para internet y tareas menos exigentes.
En mi opinión, el asunto es muy grave en servidores, gravísimo en servidores expuestos en Internet y extremadamente grave en servidores que prestan servicios en la Cloud pública. En PCs creo que las vulnerabilidades no son tan explotables.
Usemos el asunto de las particiones, o en versión real: una habitación para videar con colegas escogidos y otra para hacer fiestas de cumple con todo el mundo… y notaremos que la esencia en ambos casos (hasta ahora!) es comunicarse con otros humanos.
Pero en un mundo supertecnologizado podemos llegar a olvidar que es imposible mantener aisladas las habitaciones y que lo que en ellas se hace es intercomunicar humanos…
Pero si los humanos acaban por preferir el filete virtual (Matrix dixit), entonces el problema básico se traslada de la intercomunicación entre humanos a la intercomunicación humano-máquina, por lo que pasa a segundo lugar el problema de la «necesidad de parches», El ser humano es capaz de preferir la vulnerabilidad (como la falta de privacidad) a devaluar sus sensaciones vitales (aunque sean virtuales).
Ese sería el problema básico de la humanidad, acabar con la esencia de la comunicación humana; no que Skynet decida mandar terminators para matar predecesores o que nos invada nuestra privacidad «a la fuerza»… ¿como llevar a cabo una resistencia sin comunicación?
Y por eso también resulta muy importante preservar el lenguaje humano por mucha necesidad de programación que se tenga. En ese sentido la depauperación lingüística de los llamados «nativos digitales» puede ser una importante pérdida de «activo».
El fallo también afecta a móviles?
https://elpais.com/tecnologia/2018/01/04/actualidad/1515067320_972456.html
https://meltdownattack.com
Sí, también. Afecta a prácticamente todos los dispositivos que llevan microprocesador desde 1995…
En efecto, ningún fabricante se salva por lo que se va sabiendo. Y nunca hay que olvidar, yo nunca lo olvido, que, como decían nuestros amigos los hackers «La seguridad es sólo un estado mental».
Buen año 2018 (que va a ser de risa, comparado con el 2017).
Es responsabilidad exclusiva de Intel, no de los fabricantes de servidores.
Al parecer, el CEO de Intel ya había tomado las medidas oportunas para prevenir el fallo y que afectara lo mínimo posible a su bolsillo.
El CEO de Intel vendió muchas de sus acciones tras entersarse de las vulnerabilidades. https://www.cnbc.com/2018/01/04/intel-ceo-reportedly-sold-shares-after-the-company-already-knew-about-massive-security-flaws.html
Usar la arquitectura Von Neumann pareció una buena idea de principio, ahorraba importantes costes en aquella época, a la larga ha demostrado ser la mas importante fuente de problemas. La práctica totalidad de lo virus de ordenador existentes serían inefectivos en una arquitectura Hardvard.
Quizá ha llegado el momento de replantearse que arquitectura usar de ahora en adelante.
Por lo que he visto, el ataque sería igualmente posible en un ordenador con arquitectura Harvard. El ataque NO consiste en ejecutar código en un espacio de direcciones reservado para datos.
Para inyectar código en cualquier máquina este ha de ser previamente cargado como datos.
En una arquitectura Harvard no es posible mover datos al espacio de código, ergo no se puede ejecutar ningún código malicioso cargado en la maquina comprometida.
Este ataque NO consiste en inyectar código.
¿Estamos todos de acuerdo en que las Cloud Públicas no parcheadas están poniendo en grave riesgo los servicios de sus clientes?
Sí, estoy de acuerdo, pero con una importante limitación para el atacante: ha de ejecutar localmente en el servidor su propio programa. Eso implica que el atacante debe contratar el servicio en la nube. El atacante se debe registrar, pagar por el servicio, y solo tendrá acceso a los datos del servidor donde se ejecute su programa, de entre las decenas de miles de servidores que tiene una nube pública. El almacenamiento en una nube es en red, así que tampoco tendrá acceso a ningún disco duro.
Que conste que no pretendo minimizarlo, me parece la mayor cagada de seguridad que he visto en toda mi vida.
Sí, pero los proveedores de cloud públicas estaban avisados desde hace meses y han hecho sus deberes (preparar y probar parches del kernel para semejantes vulnerabilidades no se hace en dos días). Ej: Microsoft Azure:
«The majority of Azure infrastructure has already been updated to address this vulnerability. Some aspects of Azure are still being updated and require a reboot of customer VMs for the security update to take effect.»
Fuente: blog de Azure:
Securing Azure customers from CPU vulnerability
Lo que parece que ha ocurrido es que las vulnerabilidades se filtraron antes de que finalizara el embargo de su divulgación, e Intel, al verse señalada como único fabricante de CPUs afectado, emitió un comunicado para indicar que no eran los únicos, al menos para una de las dos vulnerabilidades.
Lo va a ser interesante ahora es ver lo que tardan las empresas en actualizar sus clouds privadas, sus servidores y los PCs de sus usuarios (la mía, y mis clientes, no han dicho ni «mú» aún…a ver el lunes. Menos mal que con el WannaCry del año pasado ya han espabilado y ahora parchean todos los meses). Para empezar, para que se instalen los parches de Windows de enero, los antivirus han de ser actualizados porque Microsoft les ha pedido que «señalicen» a Windows mediante una entrada en el Windows Registry que son «compatibles» con los mismos.
Como dice Enrique, los datos están más seguros en una nube pública gestionada por una empresa competente, que en otras partes…
Dicho todo esto, estas vulnerabilidades son épicas, y modificarán la arquitectura de los microprocesadores futuros. Lo que se está haciendo ahora es parchear una capa por encima, a nivel de software en el kernel del sistema operativo.
Pero si ahora hay que modificar los kernel de todos los sistemas operativos (todos son vulnerables), transferimos la vulnerabilidad a todos y cada uno de los kernel modificados.
Alguien malintencionado tendría que atacar a cada kernel, y no necesitaría profundizar hasta el nivel del propio procesador, cosa que parece algo más fácil.
Buenas noticias para los vendedores de microprocesadores que, paradójicamente, se pueden beneficiar de su propio error de décadas.
Este parece el mayor error desde que el matemático Thomas R. Nicely descubrió en 1994 que su cálculo empírico de la constante de Brun en un Pentium recién horneado no concordaba con valores de esa misma constante calculados previamente.
Además de la pérdida de rendimiento que suponen estos parches, el problema es que no parece haber ningún parche de SO que solucione por completo todas las posibles formas de ataque.
Curiosamente, hace un par de meses se me hizo muy raro que mi ordenador con la última versión de Ubuntu (un ordenador de hace más de 10 años con Core 2 duo T7100), actualizase el firmware del microprocesador.
No lo había visto nunca (o por lo menos no me había fijado).
En cuanto a la seguridad completa, es verdad que no se puede conseguir, siempre es como un gato intentando atrapar a un ratón en círculos alrededor de un árbol, pero sin conseguir capturarlo nunca.
Por algo nunca he sido yo 100% partidario de usar el cloud-computing, al menos no a día de hoy, ni con cualquier tipo de documento. Al final ha salido lo que yo esperaba que alguien descubriera, tarde o temprano.
Bueno, en cualquier caso, tampoco hay mucha diferencia entre estar infectado con malware de cualquier tipo, te pueden robar la información igualmente y ser igualmente expuesta la información sensible.
De cualquier manera, dado el descenso de la venta de PCs, no sería mala idea como estrategia.
Creo que hoy la explicación de Enrique fue una breve excepción a sus siempre excepcionalmente brillantes artículos. En especial para aquellas personas que no comprenden bien la parte técnica del problema, por lo que recomiendo el texto de Chema alonso: http://www.elladodelmal.com/2018/01/el-caos-que-genera-metldown-spectre-con.html
Excelente enlace, parece que sabe muy bien de lo que habla. Por lo que el futuro no es nada halagüeño.
La opinión de Linus Torvalds, las demandas contra Intel, etc.
IBM reconoce que sus procesadores Power están también afectados:
https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/
Intel y otros gigantes dicen que no hay impacto sobre el rendimiento real de sus cargas de trabajo. Afirmación un poco vaga y que no clarifica en qué casos afecta y en qué casos no afecta.
https://newsroom.intel.es/news-releases/las-pruebas-realizadas-por-el-sector-demuestran-que-las-actualizaciones-de-seguridad-publicadas-recientemente-no-afectan-al-rendimiento-en-implementaciones-reales/
Usuarios negando lo que dicen los gigantes, es decir, constatando que mienten.
AWS users experiencing significantly increased CPU utilization
https://forums.aws.amazon.com/thread.jspa?threadID=269858&tstart=0
Buena la explicación de Randall Munroe, XKCD…
La propuesta de Oracle para securizar la memoria de sus sistemas con los procesadores SPARC M7, SPARC S7 y SPARC M8.
Una introducción muy básica:
We have seen security hacks everywhere and valuable resources and data is being compromised on a regular basis through secure servers deployed in enterprises. Whether its Target or Home Depot or several other firms that have suffered similar, malicious attacks, security and data integrity have suddenly become of prime importance.
SPARC M7 has a very interesting feature, called Realtime Silicon Secured Memory (SSM, for short), that is designed to safeguard against invalid, stale memory reference and buffer overflows. The hardware does this by allowing software to mark software buffers with special versions. Part of the Pointer can be used to store a version number and this version number is also maintained in the memory cache lines. When a pointer accesses memory, the hardware checks to make sure the two versions match. A SEGV signal is raised when there is a mismatch.
This can also be done in Software, but it is very slow (often 100 times slower) as it requires annotating code at every load and store and writing routines to check. By doing these checks in hardware, applications run at near clock speeds, thereby removing a key obstacle of using this in development cycle only. This feature can be used by the Database, user applications that manage memory and the OS.
With this feature, you can:
Catch memory reference errors in production code with low impact on performance
Run more tests, faster and find more bugs during regular testing
Continue checking in deployed code, at customer sites
https://swisdev.oracle.com/_files/What-Is-SSM.html
Había una vez una marca de smartphones, con el logotipo de una frutita creo recordar…que con la buenista intención de que no se nos resetease de forma inesperada el terminal..publicó 1 bonito…e inocente :-) parche de software para prevenir el «apagoncito» y que así no eXPerimentásemos consecuencias colaterales indeseadas…Tan sólo una «caidita» en el rendimiento funcional de entre el 30 y el 40 por ciento de la velocidad de ejecución…Ya te digo. Cosa de poco. ¿Quién lo iba a notar ?? A fin de cuentas..lo que más valoramos los usuarios de nuestros dispositivos digitales es que el logo sea «cool» y que brille mucho ¿no? Eso es «lo máximo» de la eXPeriencia de usuario ;-)
Pero si ahora nos suponemos, que al mismo teléfono hay que ponerle otro parchecito buenista (e inocente) para vacunarlo del Meltdown y que no se nos «funda» durante el uso : otro 15 % menos de fluidez ( ya cantamos línea… ) Y además hay otra «cepa» denominada Spectre que para que nuestro equipo no tenga un comportamiento «fantasma»..pues la vacunamos también con 1 inofensivo Update ( otro -20% de desempeño…buff !!! ya con este tiki-taka de parcheos..ya vamos para bingo…si es que no lo hemos cantado ya ¿no? ;-) ¡ Qué barbaridad !! Esos equipos se deben quedar ya *Zetas*!!! Vamos que ya podemos pedirle a los Reyes uno nuevo..!!!! Vaya..vaya…Qué renovaciones tan «estudiadas» del parque tecnológico nos esperan para este 2018 !!!
Me pregunto: ¿se podrá hacer lo mismo con los futuros coches conectados y palmarles la velocidad del vehículo con el «pretexto» de 1 update de «seguridad» vía OTA?? Me dá miedito contestarme..porque creo que sé la respuesta…
Mi personal y modesta conclusión: El ADN de la Obsolescencia P. acaba de encontrar la manera de recombinarse con éxito con el ADN de los Updates..Y está creciendo una especie nueva…Vaya 1 bicharraco hostil con el que vamos a tener que bregar los usuarios y los profesionales, si no lo arreglamos haciendo algo entre tod@s para evitarlo..Creo que hay virus de la gripe, que son más amigables..y más fáciles de controlar que este nuevo bicho. Desde luego este 2018 pinta que va a ser tecnológicamente muuy pero que muuy entretenido !!
**Nota: los Zetas son los zombies ;-)
Un buen resumen de cómo está ahora mismo el tema de los parches:
https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/
Me pregunto si saliera un detector de esos ataques exploit sería más conveniente que reemplazar el microprocesador o mermar su rendimiento a base de parches. Así, se achacaría siempre el problema a un software determinado. Pero lo mismo me equivoco y no es tan sencilla la cosa. ¿Qué opináis? Ya que no es algo que se pueda eliminar como antídoto como en otros casos eliminando archivos, cadenas víricas o entradas residuales.
En mi opinión, este fallo se debe a la falta de competencia que tiene Intel por disfrutar de un monopolio de facto. La industria y los clientes han decidido que es mejor que Intel se coma todo el pastel, desplazando a AMD y a los procesadores RISC (Power, SPARC) y ya estamos disfrutando de la falta de competencia.
Vamos a ver las vulnerabilidades no se explotan solas, salvo que tengas cosas a la escucha como.el gusano que afectaba a MS SQL Server por sus puertos abiertos.
Como proponen algunos, puedes tener una partición sin parcheo solo para trabajar pero… Como se puede leer en el enlace que han publicado en otro mensaje, ya han descubierto como usar Javascript para lograr el ataque.
Esto quiere decir que deberías tener un equipo con el cable.de red desconectado, o solo para los muy avanzados, con una IP fija a la que el router prohibiera cualquier accedo a internet aceptado solo la intranet para poder dejar el trabajo en el NAS … Y estar muy seguro.de que ni el.router ni el.NAS van a ser contaminados.
Yo uso un portátil con I5 para trabajar que no se conecta a internet para el trabajo (parte lo hago en los trenes sin módem 3G)/pero que necesita hacerlo para actualizar parches del OS o de las herramientas.
Vamos que aunque solo vistes google, Microsoft y los webmails, basta con que alguien cuele un anuncio malintencionado (y OS puedo jurar que entre los que suministra sazón abundan) que ejecute ese javascript para que te veas comprometido.
¿Pero hasta que punto? Porque nadie te ha dicho si te pueden convertir en.zombie de botnet, robarte los bitcoins o hacerse con tu pin de la VISA o de PayPal
Pero tidoesto viene de que como nadie ha exigido seguridad pero si prestaciones… «Ten cuidado con.lo que pides a Ala, que te lo puede conceder»
Para Meltdown ya hay parche, y Spectre es más difícil de aprovechar para el atacante. Los navegadores ya empiezan a tomar medidas para dificultar un ataque por Javascript (a base de degradar la precisión de las medidas de tiempo), y el ataque por Javascript siempre fue más limitado en sus efectos (solo se podía obtener información del proceso del propio navegador, no de otros procesos).
Estoy totalmente en desacuerdo con tu último párrafo. Por supuesto que la gente quería prestaciones, pero se nos decía que un proceso no podía leer la memoria asignada a otro proceso. Todo esto de Meltdown y Spectre viene porque en la ejecución especulativa a las instrucciones sí se les permite realizar esas lecturas, en lugar de comprobarse los límites de seguridad antes de ejecutar la instrucción.
Vamos, que no es otra cosa que una cagada de los fabricantes de procesadores, que además no todos han metido la zarpa por igual. Los clientes no hubieran comprado los procesadores afectados de haberlo sabido. Habrá gente que no sepa de estas cosas, pero Amazon, MS, y Google no habrían comprado esos procesadores para sus nubes ni para ninguna otra cosa, al igual que los bancos y otras grandes empresas, y lo mismo yo o cualquier otro con conocimiento del tema.
En el ámbito de los servidores, la comoditización de la capa de proceso en la arquitectura X86 de Intel, para reducir los costes de cómputo, comparado con arquitecturas RISC (SPARC y Power, que también está afectado por Meltdown) ha conllevado un monopolio de-facto de Intel. Que como todos los monopolios implica una disminución drástica del I+D. Empezamos a tener resultados del monopolio.
Me llama la atención que ARM, que también tiene arquitectura RISC, y también se ve afectado. No se trata de CISC vs RISC sino de la necesidad de un mercado SANO de procesadores, con competencia real, que no existe en servidores y PCs.
Por supuesto, cuanta más competencia mejor. Pero no todos los procesadores de Intel están afectados (sí la gran mayoría), y como dices también hay algunos procesadores de ARM y otros fabricantes que están afectados.
No parece haber tenido nada que ver con ningún monopolio. Un ejemplo sencillo: el Cortex-A53 no está afectado, el Cortex-A57 sí. Ambos son de ARM, y de características similares. Se da la paradoja de que hay aparatos que tienen ambos tipos de cores (mi móvil, por ejemplo, tiene 4 cores A53 y otros 4 A57).
Por tanto, si un malware intenta Meltdown en mi móvil todavía sin parchear, el ataque fallará si el malware se está ejecutando en alguno de los cores A53, y tendrá éxito si se está ejecutando en un A57. Y lo mismo (o casi) para Spectre (en Spectre, el proceso que debe ejecutarse en un A57 para que el ataque tenga éxito es el proceso atacado, no el proceso atacante).
Vamos, que un parche que me evitase cualquier posibilidad de ser atacado, incluso con el difícil de parchear Spectre, sería aquel que el kernel deshabilitase el uso de los cores A57. Mi móvil sería invulnerable… a costa de perder 4 de los 8 cores :-)
Voces que piden una nueva arquitectura de CPU:
http://www.zdnet.com/article/why-intel-x86-must-die-our-cloud-centric-future-depends-on-open-source-chips-meltdown/
https://www.extremetech.com/computing/261678-spectre-meltdown-death-knell-x86-standard
Interesantísimo, los fixes de Intel no funcionan:
https://www.theregister.co.uk/2018/01/22/intel_spectre_fix_linux/