Meltdown y Spectre: Tu microprocesador Intel es inseguro desde 1995

Por Francisco R. Villatoro, el 4 enero, 2018. Categoría(s): Ciencia • Informática • Noticias • Recomendación • Science ✎ 29

Dibujo20180104 meltdown failure and solution from KASLR is Dead Long Live KAISER

El 3 de enero de 2018 será recordado en los libros de Historia de la Informática como el día que se desveló la existencia de Meltdown y Spectre. El día a partir del cual todo se hizo más lento. Meltdown es un fallo de seguridad que afecta todos los microprocesadores de Intel desde 1995; ya hay parche (KAISER), pero a costa de ralentizar tu procesador hasta un 30%. Spectre (1 y 2) es un fallo de seguridad que afecta a todos los microprocesadores modernos (Intel, AMD y ARM); aún no hay parche y podría tardar muchos años, pues requiere cambiar la arquitectura física del procesador. Cualquier programa, incluso un simple JavaScript que ejecutas desde una página web como si nada, puede aprovechar estos fallos de seguridad del microprocesador para leer la memoria de tu ordenador. Por ejemplo, tus palabras de paso cuando las tecleas.

El gran aporte a la humanidad de Bill Gates ha sido acostumbrarnos a todos a que los ordenadores fallan y son inseguros. Todo el mundo sabe que Windows puede fallar en cualquier momento; pero a muy pocos parece preocuparles. Todo el mundo sabe que Windows es inseguro; por eso Microsoft recomienda instalar parches de seguridad casi todas las semanas. Todos convivimos con ello porque así tiene que ser, como si no pudiera existir un mundo diferente. Gracias a Microsoft la vida de todos los informáticos es mucho más fácil. Gracias, Bill, todos honramos tu legado.

Pero pocos imaginaban que Intel, AMD, ARM y otros fabricantes de microprocesadores, sometidos al yugo de la ley de Moore, han sacrificado seguridad por velocidad. El kernel que gestiona los accesos a la memoria es inseguro; para solventar el problema hay que puntearlo por software. La industria microelectrónica tiene que cambiar de paradigma; bueno, ya lo ha hecho, como conté en «El futuro de la ley de Moore», LCMF, 10 Feb 2016. Cada dos años los grandes fabricantes de semiconductores publicaban una hoja de ruta para cumplir con la ley de Moore. En 2016 la Semiconductor Industry Association (SIA) cambió su objetivo a reducir el consumo eléctrico. En 2018 se augura un nuevo cambio hacia el objetivo de incrementar la seguridad. La ley de Moore pronto será un recuerdo del pasado.

Todos los servicios en la nube están siendo parcheados contra Meltdown, pero no se sabe cuánto tiempo serán inseguros para Spectre. ¿Deberías preocuparte? Si no lo has hecho hasta ahora, tranquilo, no tienes por qué hacerlo a partir de ahora. Más información divulgativa sobre estos fallos de seguridad: «Your computer may run 30 per cent slower due to Intel chip bug,» New Scientist, 03 Jan 2018; Zack Whittaker, «Critical flaws revealed to affect most Intel chips since 1995,» ZD Net, 03 Jan 2018; Chris Duckett, «Google reveals trio of speculative execution flaws, says AMD affected,» ZD Net, 03 Jan 2018; Tom McKay, «Report: All Intel Processors Made in the Last Decade Might Have a Massive Security Flaw,» Gizmodo, 03 Jan 2018; y muchos otros sitios.

Los informáticos interesados en los detalles técnicos de estos ataques disfrutarán de Moritz Lipp, Michael Schwarz, …, , Mike Hamburg, «Meltdown,» Meltdown Paper, 03 Jan 2018 [PDF]; y de Paul Kocher, Daniel Genkin, …, , Yuval Yarom, «Spectre Attacks: Exploiting Speculative Execution,» Spectre Paper, 03 Jan 2018 [PDF]. La información más actual seguro que aparecerá en la wikipedia: Meltdown y Spectre; también hay una página web específica Meltdown and Spectre.

[PS 05 Ene 2018] Este artículo ha recibido muchas críticas de informáticos. Por ejemplo, Sergio Lopez‏ @slp1605 dice «Uff… Hasta el momento me habían gustado todos los artículos de @emulenews, pero éste está plagado de errores. No se puede salvar nada. [Y añade que,] probablemente, lo más sangrante sea la propia explicación de los ataques. Ayer escribí un hilo al respecto, [lo] enlazo por si te pudiera servir de alguna ayuda». He incluido el hilo al final de este post, pues quizás algunos lectores de este blog no sean habituales de Twitter y estarán interesados en este hilo de Sergio, basado en el artículo de Jann Horn, «Reading privileged memory with a side-channel,» Google Project Zero, 03 Jan 2018. [/PS]

[PS 08 Ene 2018] Recomiendo leer a Brian Krebs, «Scary Chip Flaws Raise Spectre of Meltdown,» Krebs on Security, 05 Jan 2017. [/PS]

Dibujo20180104 Simplified illustration single core Intel Skylake microarchitecture meltdown Moritz Lipp et al

Esta figura simplificada ilustra la microarquitectura Skylake de un núcleo (core) en los procesadores de Intel. Con objeto de primar la velocidad se predice qué instrucciones serán las próximas que se ejecutarán y qué datos serán demandados, almacenando dicha información por anticipado en sendas memorias caché de instrucciones y datos. Los procesadores de otros fabricantes (AMD, ARM, etc.) usan una microarquitectura similar para la ejecución especulativa. Los fallos de seguridad Meltdown y Spectre aprovechan un puerta trasera en este sistema de predicción. Al primar la velocidad, no se ha implementado ningún sistema de seguridad que impida que un proceso acceda vía la caché de un núcleo a los datos en memoria de otro proceso (incluso si el sistema operativo en ejecución prohíbe estos accesos).

Dibujo20180104 our-of-order exception handler meltdown Moritz Lipp et al

El ataque Meltdown fuerza cortes en el flujo de instrucciones (out-of-order exceptions) para que se refresquen las cachés de instrucciones y de datos internas de cada núcleo del procesador; como resultado, se copian trozos de memoria de otros procesos y/o usuarios, que están disponibles de forma abierta e insegura para el proceso atacante (hacker). El parche defensivo KAISER, que ya estaba desarrollado para otro fallo, tiene como efecto colateral que evita el ataque Meltdown. Por ello este parche se ha desarrollado muy rápido y muchas empresas informáticas de servicios en la nube ya lo han instalado; Microsoft también lo ha incluido entre sus nuevos parches de seguridad para quienes actualizan de forma automática su Windows; en Linux y otros sistemas operativos se ha hecho lo propio.

Dibujo20180104 meltdown attack Moritz Lipp et al

El ataque Spectre (hay dos variantes llamadas 1 y 2) también usa un fallo en la microarquitectura de ejecución especulativa del procesador. Se aprovecha un fallo que no debería ocurrir nunca en un programa correcto, pero que solo se puede evitar si se rediseña el sistema de ejecución especulativa en la propia microarquitectura del procesador, algo que puede costar años, y la posterior sustitución de todos los microprocesadores del mercado, algo inviable. Por desgracia, el parche defensivo KAISER no funciona en este caso, y no parece fácil desarrollar una solución software que puntee al procesador usando ideas similares. Por supuesto, que ahora no haya parche para este fallo de seguridad solo significa que muchos jóvenes informáticos se pondrán a trabajar muy duro para desarrollarlo. La imaginación es poder.

En resumen, no quiero asustar a nadie; todos debemos asumir que nada es 100% seguro en informática. Ni tu teléfono móvil, ni tu tableta, ni tu ordenador de sobremesa, ni los ordenadores que se usan en tu trabajo son seguros. Siempre que sea posible hay que instalar parches de seguridad de forma continua. Muchos informáticos trabajan en seguridad y debemos confiar en que se encontrará un parche para Spectre. Estos parches puede que hagan que todo vaya hasta un 30% más lento, pero hoy en día los procesadores son tan rápidos que la mayoría de usuarios domésticos no notarán la diferencia (salvo quizás en los juegos por ordenador). En la práctica es como usar un equipo un par de años más viejo. Así que, tranquilidad.

[PS 05 Ene 2018] Os copio aquí el hilo en Twitter de Sergio Lopez‏ con la explicación de los ataques (está escrito el 4 de enero de 2018): «Project Zero de Google ya ha publicado un artículo detallando el problema. Se trata de una familia de ataques que explotan ciertas vulnerabilidades de las CPUs modernas, agrupadas en dos tipos: Spectre y Meltdown. Ambos ataques son muy complejos, combinando ejecución fuera de orden, ejecución especulativa, predicción de rama, y el abuso de las líneas de caché. Si te es posible, te recomiendo que te leas los papers mencionados arriba. Son muy interesantes y están muy bien escritos. Voy a atreverme a intentar dar una explicación sencilla de los mismos. Ya os adelanto que, en virtud de la simplificación, va a haber omisiones e inexactitudes. Allá voy».

«Para empezar, necesitas saber que una CPU moderna, para obtener el máximo rendimiento, trata de «predecir el futuro», adelantándose al programa y ejecutando instrucciones que se encuentran más adelante de «la que toca». Si finalmente resulta que el programa pasa por el segmento de código que ha «predicho», puede entregar el resultado inmediatamente, porque ya ha sido ejecutado. En caso de que el programa bifurque por otro segmento distinto, la CPU simplemente descarta el resultado obtenido en la «predicción». Pero, y aquí viene lo importante, la ejecución de esa «predicción» deja un rastro que puede ser observable por un tercero».

«En Spectre, el ataque consiste en «engañar» a la víctima (p.ej. el kernel) para que ejecute una predicción (concretamente, una predicción de rama) falsa que mueve información sensible a una posición de memoria controlada por el atacante. En la ejecución real, la víctima no realiza realmente ese movimiento, pero la predicción ha dejado un rastro que el atacante puede emplear para determinar el valor de dicha información sensible. En primera instancia, Spectre podría parecer más grave, ya que no se puede evitar con KPTI (antes llamado KAISER) y afecta a todas las arquitecturas probadas (Intel, AMD y ARM), pero lo cierto es que es bastante difícil de explotar en un escenario real, al menos a priori. Spectre requiere que exista código en la víctima susceptible de ser explotado de esta manera, y aunque es probable que así sea, se podría ir parcheando individualmente. Tampoco me extrañaría que en breve aparecieran técnicas en los compiladores que evitaran generar código susceptible se ser explotado mediante Spectre».

«Por su parte, Meltdown utiliza una técnica similar, pero abusando de otro tipo de predicción (ejecución fuera de orden), y aprovechándose de un bug específico de ciertos procesadores Intel. Resulta que, algunas CPUs de Intel, el «motor» que ejecuta las predicciones no tiene en cuenta los permisos de acceso a las páginas de memoria, por lo que puede acceder a cualquier región mapeada en el espacio del proceso. Como ya expliqué en el otro hilo, es habitual tener mapeado el kernel en el espacio de todos los procesos, por cuestión de simplicidad y eficiencia. Además, es habitual que el propio mapa del kernel contenga toda o parte de la memoria física, lo cual habilita al atacante a volcar virtualmente cualquier región de la RAM. Al igual que pasaba con Spectre, el resultado de la predicción (en este caso, una lectura de una dirección de memoria virtual de una víctima, como el kernel) se descarta, pero deja un rastro observable por el atacante, que puede utilizar para obtener la información sensible. Para agravar aún más el problema, las extensiones TSX de Intel, introducidas en Haswell, hacen el ataque más eficiente, evitando generar una excepción en cada iteración».

«Meltdown sí que es un problema MUY grave, sobretodo para proveedores de máquinas virtuales y demás servicios en la nube. No es de extrañar que los de Amazon, entre otros, se hayan puesto muy nerviosos. Para que os hagáis una idea, desde una máquina virtual cualquiera, sería posible volcar la memoria completa de un Host, incluida la correspondiente al resto de máquinas virtuales de otros clientes. Meltdown es relativamente fácil de explotar, pero sí que puede mitigarse con KPTI, y no me cabe duda que es la principal motivación de su apresurada introducción. Por el momento no se ha podido reproducir el ataque que el resto de CPUs evaluadas (AMD y ARM), aunque tampoco se puede descartar categóricamente. Intel, por su parte y hasta el momento, tan sólo ha publicado una breve nota de prensa alegando que es «incorrecto» que este problema sea exclusivo de sus CPUs, lo cual sería cierto para Spectre, pero falso (de momento) para Meltdown, como hemos visto».

«Con respecto a los ordenadores personales, queda por ver qué estrategia adoptan los vendors, especialmente Microsoft. Personalmente, si no se va a ejecutar software de fuentes inseguras, habilitar KPTI en PCs me parece un poco excesivo, teniendo en cuenta el impacto que tiene en el rendimiento. Al menos, creo que debería ser opcional. Fin del hilo». [/PS]



29 Comentarios

  1. Habría que hacer algunas puntualizaciones:

    1. La cifra del 30% ha salido en varios titulares por llamativa, pero todavía es muy especulativa. En realidad, la ralentización será muy dependiente del tipo de proceso, y habrá que esperar a evaluaciones más exhaustivas. El propio kernel no debería ralentizarse. Probablemente sufran más aquellos programas de espacio de usuario con un gran número de cambios de contexto con elevado I/O de RAM. En cualquier caso, yo no entraría en ese sensacionalismo de los medios.

    2. La cuña que has metido a Microsoft y Bill Gates ha sido muy gratuita, porque esto nada tiene que ver con ellos.

    3. Lo que permite el primer ataque, Meltdown, es la ejecución fuera de orden (out-of-order execution), que es una técnica bastante más vieja que la ejecución especulativa. Spectre sí se basa en ejecución especulativa («adivinar» qué branches se tomarán en la ejecución de un programa y cargar en el pipeline las instrucciones correspondientes por adelantado), pero es un ataque bastante más complejo y difícil de llevar a cabo.

    4. No es correcto que se pueda leer la memoria directamente de la caché como indicas. Esto simplemente no es posible. El tema es bastante más complejo.

    En la época pre-2000, el layout del sistema en RAM era perfectamente conocido y predecible, lo que hacía muy fácil para un proceso montar un desbordamiento de buffer e inyectar código ejecutable en posiciones conocidas en funciones del kernel, por ejemplo. Después apareció ASLR, que es una técnica implementada en los sistemas operativos que randomiza las posiciones en memoria y utiliza direcciones de memoria virtual que deben ser traducidas. Esto dificulta enormemente los ataques anteriores, pero desde hace muchos años han ido saliendo algunos ataques.

    Lo que hacen los ataques desarrollados ahora (principalmente hablo de Meltdown) es inferir las direcciones de memoria que han sido randomizadas gracias a peticiones de memoria perfectamente medidas en tiempo. Se basan en algo muy simple: si la ejecución tarda un poquito más de lo normal, significa que la memoria no estaba en caché. Si eres capaz de ejecutar tu instrucción después de un proceso privilegiado y la ejecución es muy rápida (memoria cacheada), entonces eres capaz de inferir la posición en memoria de ese proceso privilegiado. Pero, repito, la memoria NO se lee directamente de la caché.

    ¿Es esto un bug? La ejecución fuera de orden y las cachés son anteriores a ASLR. Ciertamente, es un diseño muy mejorable de cara a la seguridad dada la necesidad de proteger la memoria del kernel con métodos como ASLR, pero no sé si lo llamaría «fallo». Por ejemplo, se podría mejorar incorporando cachés solo para memoria de kernel y cachés solo para memoria de usuario.

    1. Lo importante para los usuarios es saber si se ha aprovechado esta vulnerabilidad ¿Se conoce algún caso?
      ¿Como se podria aprovechar (accesos directo al ordenador desde el exterior por la IP, o a través de algún tipo de virus)?

    2. Pero, si no he entendido mal la información de la wikipedia de Meltdown en inglés, si que se puede leer cualquier bit arbitrario que esté en el Address Space (que antes de KPTI incluia la del kernel, que se suponia protegida por el procesador).
      Esta es la información necesaria (Wikipedia):

      Suppose the attacker is in control of an unprivileged user-space process, which is normally prevented from reading the value at a protected memory address Ap by the CPU’s memory protection mechanism. To circumvent such memory protection and read bit 0 at Ap, the attacker executes the following sequence of instructions:

      Clears the cache at two unprotected (i.e., normally readable by the attacker) addresses A0u and A1u;
      Reads the value at protected address Ap to a register R;
      Computes an address Axu that is equal to either A0u or A1u depending on whether bit 0 of register R is 0 or 1 (this should be done with arithmetic instructions rather than branches to avoid the branch predictor complicating matters);
      Reads the memory at address Axu.
      The CPU’s memory protection mechanism will raise a memory protection fault when attempting to read from the protected address Ap at step 2. However, since waiting for the memory protection hardware to finish its checks can cause significant slowdowns, affected CPUs will actually perform the read at step 2 and continue with steps 3 and 4 speculatively, and only annul their effects when the memory protection fault gets detected some clock cycles later. Only the so-called «architectural» effects are annulled; the speculative execution of step 4 causes the memory at Axu to be loaded into the cache, affecting the speed (but not the results) of subsequent reads from Axu, and this is not undone. So after the memory protection fault (which can be handled by a signal handler, or allowed to crash the process if the attacker has previously forked another process sharing the address space, or suppressed altogether if the read attempt in step 2 is itself only speculative), the attacker simply reads from A0u and A1u, timing both accesses. This timing will determine which of the two locations is now in cache, and thus reveal the value of memory bit 0 at address Ap.

      The above steps can be repeated for the other bits of the value at Ap.

      Una cosa que no me queda claro es la diferencia entre Meltdown y Spectre. ¿Es Meltdown un caso especifico de Spectre? Parece que la wikipedia de Spectre quiere decir que es una vulnerabilidad basada en la ejecucion especulativa, justo lo que es Meltdown. Y otra pregunta, ¿por qué no le afecta a AMD Meltdown? ¿Por qué Spectre afecta solo a la memoria dd otros programas?
      Gracias

      1. Si mal no recuerdo, Meltdown no se basa en ejecución especulativa, si no en algo similar pero mucho más antiguo que ya no recuerdo el nombre. Por eso afectan a diferentes arquitecturas.

  2. » Todo el mundo sabe que Windows es inseguro; por eso Microsoft recomienda instalar parches de seguridad casi todas las semanas. Todos convivimos con ello porque así tiene que ser, como si no pudiera existir un mundo diferente. Gracias a Microsoft la vida de todos los informáticos es mucho más fácil. Gracias, Bill, todos honramos tu legado.»

    Francis, No puedes comparar Windows o OS con otros sistemas operativos, para nada…No solamente, y lo sabes de sobra, es imposible teóricamente, un sistema operativo seguro (no lo es ¡ninguno!), si no que además, estos en concreto precisan de un entorno de manejo para tontos totales en todas y cada una de sus infinitas posibilidades, la necesidad de sacar novedades constantemente sin perder las múltiples compatibilidades y chorros de código, un precio final que se pueda permitir un trabajador medio…y por supuesto, sus tropecioentos desarrolladores en continuo reciclaje…Muy en desacuerdo con la ironía.

    1. Gerardo, lo increíble es que «El CEO de Intel vendió la mitad de sus acciones un mes antes de que se conociera el fallo de seguridad de los procesadores» https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438 (algo punible e ilegal). Y, quizás no relacionado, que «François Piednoël se va de Intel, el ingeniero principal de sus CPUs desde hace 20 años» https://elchapuzasinformatico.com/2017/07/francois-piednoel-se-va-intel-ingeniero-principal-cpus-desde-20-anos/ (las malas lenguas lo asocian al problema).

  3. «El gran aporte a la humanidad de Bill Gates ha sido acostumbrarnos a todos a que los ordenadores fallan y son inseguros».

    Voy a hacer de abogado del diablo… o de Bill Gates en este caso: soy programador, tengo un poco más de una decada de experiencia y creo poder afirmar QUE ES HUMANAMENTE IMPOSIBLE QUITARLE TODOS LOS ERRORES A UN PROGRAMA RELATIVAMENTE GRANDE, cada if, cada while, cada for, cada excepcion, cada return, cada evento introduce un camino nuevo en el programa, y si tienes digamos un millon de lineas de codigo, se hace casi imposible recorrer todos los caminos buscando errores.

    Mi experiencia es que si tu programa es un programa «real» (usado en producción por usuarios reales), NUNCA dejaras de encontrarle errores, ya que los multiples usuarios siempre encontran maneras de usarlo que no planificastes, que no previstes y haran saltar errores.

    Si tienes un software como Windows, que además debe coexistir con codigo creado por terceros, me imagino que debe ser una locura la cantidad de posibilidades de error.

    Si, yo se que hay tecnicas para detectar errores, como Unit Test, pero estos test unitarios dependen o de la imaginación del programador (poner pruebas de errores que PREDICE el programador), o de que el error YA HAYA SIDO ENCONTRADO.

    1. Ahora… lo que si me entra en la cabeza es que un error EN HARDWARE pueda pasar desapercibido 15 años y nadie lo detecte…. me parece sospechoso

  4. Desde AMD estaban diciendo que sus ryzen están libres y que no todos son iguales ni han de pagar por igual con parches y avisaban a la comunidad kernel del GNU/Linux que no hay razón para ralentizar con un parche unos procesadores que no tienen el error a parchear

    Por otra parte Linus Torvals acaba de cargar muy duramente contra Intel

  5. Vaya racha, primero Volkswagen con sus centralitas con truco para que los coches sean rápidos pero limpios sólo en apariencia y ahora Intel con sus procesadores con truco para que los ordenadores sean rápidos pero seguros sólo en apariencia…

  6. Al leer los 2 primeros párrafos he parado de leer el artículo ya que el escritor demuestra sus nulos conocimientos de informatica al tachar a Windows de inseguro y despotricar contra Microsoft de manera gratuita. Si tuviera la mas leve idea sabría que Windows es el SO más seguro ya que al ser el más usado es el que más ataques recibe y el que más tiene que estar al día en seguridad.

    1. Cander, al leer tus 2 primeros párrafos has demostrado tus nulos conocimientos sobre el currículum del autor. Me parece que «sabe más informática» de lo que crees y deberías haber leído el resto.

      «Francis estudió informática, física, se doctoró en matemáticas, investiga en ciencias computacionales, le dió clases a ingenierios industriales y ahora imparte bioinformática a futuros bioquímicos en la Universidad de Málaga»

    2. Que sea el más utilizado no lo convierte en el más seguro, simplemente lo convierte en el principal objetivo de ataques. Lo demás no lo has argumentado y estoy del lado de Francis, precisamente porque es el más usado, el sistema de permisos de usuario daba pena para que lo pudiera usar la gente analfabeta digital. Incluso hoy en día siguen dejando que desear.

    3. Me temo que tiene bastantes más que tu. El windows ha ido evolucionando pero a tenido agujeros de seguridad como casas y conocidos por todos y sin tapar. Errores que no son admisibles ni la décima parte en otros S.O. El Windows durante mucho tiempo ha sido un coladero absoluto de seguridad. Como que desde una aplicación de oficina podía acceder a los archivos del sistema y editarlos sin problema en instalaciones normales (lo hice) en el Xp mejoraron con diferencia pero aún así mantenian dos puertas abiertas con acceso total al PC a nivel de administrador desde acceso remoto y por entrar en un enlace web..

      Últimamente y a tenor de ser el más utilzado y más atacado se ha ido mejorando. Pero tenía agujeros inmensos que acaban con la paciencia de un programador inaceptables y que un simple GNU/linux no tenía. Que sí que al haber más gente que ataque pueden influir pero no hay comparacioń. En Linux necesitas tener conocimientos muy profundos del sistema y con el Windows lo podía hacer un crio durante muchos años y simplemente cargaban legalmente contra quienes hacían los ataques pero no arreglaban las deficiencias en meses o incluso años. Así en Windows han habido errores conocidos durante años y graves y en GNU/Linux se han encontrado pero el parche ha salido a los pocos días prácticamente siempre (tardó más el gusano de la redhat 5.1 6.0 a través del canal al servidor de impresoras, pero bueno)

      Las diferencias siempre han sido notables. WIndows no se ha caracterizado por la seguridad habitualmente no es porque sea el más atacado al ser el más utilizado sino que realmente es que no tenía una calidad alta de seguridad ni por asomo.

      Cuando me pasé al GNU/linux te juro que mis nervios cambiaron muchísimo. No te lo puedes ni imaginar. NO es una seguridad total ni por somo. pero contra es que el Windows era una puta mierda en seguridad cuando lo abandoné. Era tan cutre que era inaceptable y solo daba problemas uno tras otro tras otro tras otro… una pesadilla…

      El Windows habrá mejorado mucho con los años pero decir que es el S.O. más seguro del mundo y que alguien como Francis no sabe de informática me suena a chiste

    4. Con todo respeto, este es un blog de ciencia, por favor, las pasiones quedan a un lado, si?
      Pero veamos si tu tienes la mas leve idea.
      A saber:
      El Sistema Operativo más utilizado es Android y no Windows, generalizando podriamos decir que hoy en día son los basados en Linux.
      Por otro lado decir tal o cual SO es más seguro es casi de magufo. Que versión de Windows (XP, 7, 8.1, 10… )? Que Distribución de LINUX (Ubuntu, RedHat, Kali…)? Para que usos, en que entornos, con que actualizaciones?
      Por otro lado, el Evaluation Assurance Level (EAL) del US CERT que es el Standar desde Fines de los 90′ utilizado por Gobiernos, por ejemplo, para establecer una calificación de Seguridad de 1 a 7, le da nivel 4 a la mayoría de SO hoy en uso.
      Asi que, Windows no es el SO más seguro, ojo, tampoco el menos. Están todos a la par, en general.
      Parece que tu idea es más leve de lo que pensabas.

  7. Hola chicos.
    En principio se pensó que todos los procesadores estaban afectados y los parches incluian a todos los vendors de procesadores, pero luego se determinó que los AMD estan libres del fallo, porque usan otra arquitectura y abordaron el caso que causa el problema de otra forma desde el inicio. Por eso la gente de linux removió a AMD de la lista negra.

    Ver este tweet que muestra una imagen de las lineas removidas y agregadas al kernel de linux para tratar el tema: https://twitter.com/BryanLunduke/status/948430797266042880

    Ver este video que lo explica de forma facil: https://www.youtube.com/watch?v=0_6FFDm_8nM&t=42s

  8. Mientras los microprocesadores y los programas sean creados por humanos contendrán errores, porque…, «errar es de humanos», cuando sean creados por inteligencias artificiales todos estos errores «y otros» se acabaran, para entonces quizás el ser humano esté aún aquí para verlo…, aunque no sé si para contarlo

  9. Gran artículo, independientemente de si existen matices, o visiones complementarias, que además incluyes para que la gente obtenga la mayor cantidad de información posible. Gracias, y enhorabuena por ello.
    Inmediatamente me surgió una pregunta, al enterarme de estos problemas. A pesar de que resulta una pregunta en cierto modo capciosa (lo admito), y que apuntaría en el sentido de la tecnología-ficción, ¿alguien sabe si los micros Motorola que usaban los Macs, en el momento de hacer el «gran movimiento de Apple» hacia Intel, sufrían de estos problemas o similares?

  10. Hola

    Olvidaos de Meltdown, Spectre y similares. El problema es que utilizando la caché es posible acceder al contenido de direcciones de memoria protegidas. El cómo se lance es un poco secundario (Meltdown usa una excepción, Spectre la ejecución especulativa pero seguro que surgen más) Tras analizar los papers y darle vueltas he visto qué mecanismo se usa y demuestra un profundísimo conocimiento de las CPUs. Lo podéis encontrar aquí en Español (es el mecanismo para acceder a los datos, cómo lo desencadenes puede tener variaciones)

    http://www.calderodemurias.com/2018/01/spectre-recuperacion-del-dato-entre-lo.html

    La cuestión es que con las CPUs actuales (Intel, ARM, AMD, POWER ) no parece tener solución (el parche TKPI sólo quita el target del ataque de Meltdown, se podría modificar para atacar al nueva tabla de memoria del kernel)

    A mi entender, harían falta módulos criptográficos por HW para encriptar la memoria, como tienen los últimos SPARC M-7 que ha sacado Oracle hace un par de años. De esta manera, aunque accedas a contenido protegido, no te serviría de nada.

Deja un comentario