Cpus via nano, ¿afectadas o no?.

23 envíos / 0 nuevos
Último envío
#1 Mar, 06/02/2018 - 15:50
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

Cpus via nano, ¿afectadas o no?.

 Vale. Pues después de considerar lo de https://exdebian.org/comment/4774#comment-4774 sigo en la tarea de contabilizar las bajas.

 " Es el año 2018 dc. Todos mis ordenadores activos están ocupados por meltdown y spectre... ¿todos?,
 tal vez no!. Un pequeño ordenador en un rincón resiste aùn y ahora valientemente a los conquistadores ... ".

 Pues tal como dice la voz en off, casi todos mis ordenadores han acabado llevando alguna cpu de intel.
 Tuve también una minitorre con una de amd. Pero cedió la placa base, y su sucesor también de fue intel. :(
 ¿Ni uno distinto?. Vale, tengo uno que no es ni de intel, ni de amd, ni es arm, ni android, ni ...
 ¿Entonces?.
 Es un pequeño samsung, un np-nc20, que calza una cpu via nano (una U2250) si hacemos caso del reporte de linux.
 La pregunta es inevitable. ¿Está via también pringada por el affaire?.
 Porque además se da la casualidad de que este es precisamente el único, que en caso de disponer de una
 conexión en red, tiene permiso para conectarse, al no contener ficheros privados, ni textos mios, ni claves,
 ni cuentas bancarias, ni prácticamente nada que le sirva a nadie, solo lo que estoy descargando.
 Un ordenador limpio para descargar lo que necesitas sin que te roben nada. Y luego, offline, pasárselo al
 ordenador que lo está esperando.

 Si miramos wikipedia, como en el caso de los intel, nos dice que:

 Via apareció en la informática en 1996 de algo llamado symphony.
 En 1999 compró Cyrix, considerado "el tercer fabricante" en la época del 486, y a centaur technologies.
 Después ayudó a definir estándares y fue haciendo sus procesadores, incluido el C7, antecesor del que nos ocupa aquí.
 (Pero sobre los que me interesa preguntar es sobre los de la serie nano. En particular sobre el U2250).

 En 2007 via anunció que estaba trabajando en cpus de nuevo cuño, diseñadas desde cero y con arquitectura nueva.
wikipedia: "El 28 de mayo de 2008, VIA anunció la disposición final de procesadores Isaiah tanto de voltaje estándar como variantes de baja tensión, mientras que también presenta el procesador de marca Nano"

Nano incluye instrucciones x86 para 64 bits, asi como tecnología de virtualización, no disponible en el c7 y anteriores.
 Tiene capacidad de procesado out-of-order, (aunque no he leído en ningún sitio que sea especulativa),
 y otras mejoras que incluyo en el quote del final.

 Prefetch de datos: La incorporación de nuevos mecanismos de prefetch de datos, incluye tanto la carga de
 una caché de 64 líneas antes de cargar la caché L2 como una carga directa para la caché L1.
 Obtiene 4 instrucciones x86 por ciclo frente a las 3-5 de Intel.
 Enví­a 3 unidades / reloj a las unidades de ejecución.

 Y también Permite combinar algunas instrucciones como una sola instrucción, para mayor rendimiento.

 Y un predictor de saltos mejorado, (8 predictores en dos etapas pipeline).

 Y bla bla ...   Pero la diferencia que me hace dudar es esta:

 El pentium original usaba un proceso de instrucciones in-order.
 Hasta que no has terminado de procesar una orden no se empieza con la siguiente, y si algún operando aún
 no llega, pues habrá que esperar a que esté disponible.

 El pentium pro, la lió porque mientras está esperando les diò por intentar resolver todas las situaciones
 posibles en ese punto, y alguna será la afortunada. Las demás se tiran.
 Es como si el vendedor de una tienda de móviles, mientras el cliente está considerando las ofertas y mirando
 el catálogo, ya empezase a rellenar los papeles de alta del móvil.
 Si lo compra, solo queda poner el modelo e identificación del aparato, llenar el nombre y firmar. lo demás
 ya está hecho.
 Si no lo compra, se rompe la hoja y listo.
 Lo malo de este tipo de especulación, siguiendo con el paralelismo, es que en cada hoja aparecen los códigos
 de identificación del vendedor, del punto de venta y otros datos que no suelen darse al cliente.
 Si alguien pilla esas hojas y las recompone ...

 En el punto medio en cambio, (que es donde dicen que está la virtud), tenemos a la ejecución out-of-order.
 sin especulación. Si un operando de una instrucción tarda en llegar, mira si alguna otra de las instrucciones
 que está esperando ser ejecutada tiene ya a punto sus operandos. Entonces la ejecuta y guarda el resultado
 para cuando lo necesite. (Lo que nosotros llamaríamos "ir adelantando trabajo").
 Es como esos vendedores que mientras su cliente rellena un impreso o llama fuera para preguntar algo, el
 vendedor averigua si entre los siguientes clientes hay alguno que solo necesita algo que se hace rápido,
 o solo quiere preguntarle algo. Luego sigue con el que estaba atendiendo antes.

 La cpu mencionada pertenece a esta última categoría.

 La pregunta del millón, (de maldiciones), es si esta cpu en concreto puede ser vulnerable a alguno de lo dos bug,
 o si por el contrario se salva, aunque sea "por los pelos".

 Espero vuestro juicio y vuestra sabiduría.

 

 

 https://es.wikipedia.org/wiki/VIA_Technologies
 https://es.wikipedia.org/wiki/Centaur_Technology
 
 https://www.viatech.com/en/silicon/processors/nano-e-series/

 https://www.notebookcheck.org/VIA-Nano-U2250-Notebook-Processor.52727.0.html
 https://www.notebookcheck.org/Samsung-NC20.16007.0.html

 https://web.archive.org/web/20080730051041/http://es.viatech.com/es/products/processors/nano/
 https://web.archive.org/web/20080730051041/http://es.viatech.com/es/downloads/whitepapers/processors/WP080124Isaiah-architecture-brief.pdf
 https://web.archive.org/web/20080730051041/http://es.viatech.com/es/downloads/whitepapers/processors/WP080529VIA_Nano.pdf

 

Wikipedia:

 Mejoras en la arquitectura[editar]

    Diseño out-of-order y superescalar: Proporciona mucho mejor rendimiento que su predecesor, el procesador VIA C7, que era in-order. Esto sitúa a la arquitectura de Isaí­as en lí­nea con las actuales ofertas de AMD e Intel, con excepción de Intel Atom, que tiene un diseño in-order.

    Fusión de instrucciones : Permite combinar algunas instrucciones como una sola instrucción con el fin de reducir los requisitos de energí­a y dar un mayor rendimiento.

    Predictor de saltos mejorado: Usa ocho predictores en dos etapas de pipeline.

    Diseño de caché: Un diseño de caché exclusivo significa que los contenidos de la caché L1, no están duplicados en la caché L2, proporcionando una caché total más grande.

    Prefetch de datos: La incorporación de nuevos mecanismos de prefetch de datos, incluyendo tanto la carga de una caché de 64 líneas antes de cargar la caché L2 como una carga directa para la caché L1.
        Obtiene 4 instrucciones x86 por ciclo frente a las 3-5 de Intel.
        Envía 3 unidades / reloj a las unidades de ejecución.

    Acceso a la memoria: Fusión de los almacenes más pequeños en mayor carga de datos.

    unidades de ejecución: Están disponibles siete unidades de ejecución, lo que permite hasta siete micro-ops para ser ejecutadas por el reloj.
        2 unidades de enteros: Una unidad (ALU1) es característica completa, mientras que el otro (ALU2) carece de algunas bajo las instrucciones de uso y, por tanto, se puede utilizar con más frecuencia para tareas como la dirección cálculos.
        2 unidades de almacenamiento (VIA se refieren a estas como almacén de direcciones y otro para almacén de datos)
        1 unidad de carga
        Medios de comunicación o 2 unidades de 128-bit de ancho datapath, 4 de apoyo único precisión o 2 de doble precisión.
        Una unidad (MEDIA-A) se corresponde con el soporte de punto flotante, 2-reloj de la latencia para instrucciones add de simple precisión y doble precisión, integer SIMD, cifrado, división y raíz cuadrada.
        La otra unidad (MEDIA-B) realiza multiplicación en precisión simple, con 3-reloj de la latencia para multiplicación de doble precisión.

    Cálculo de medios: Se refiere al uso de unidades de ejecución de coma flotante .
        Utiliza una unidad de ejecución para cálculo de coma flotante y otra para multiplicación, que permite la ejecución de hasta cuatro coma flotante y multiplica cuatro por reloj.
        a nueva aplicación de adición-FP Además con los más bajos de latencia (en relojes) visto en procesadores x86 hasta la fecha.
        Casi todas las instrucciones SIMD entero se ejecutan en un ciclo reloj.
        Implementa conjunto de instrucciones multimedia MMX, SSE, SSE2, SSE3, SSSE3
    Administración de Energía: Además de que requiere de muy baja potencia, se incluyen muchas características nuevas .
        Incluye un nuevo estado de energí­a C6 (cachés son lavadas con estado interno guardado, y voltaje principal está apagada).
        Control de Estado P-Adaptive: La transición entre el rendimiento y la tensión de los estados sin parar la ejecución.
        Overclocking adaptable: overclocking automático si hay baja temperatura en el procesador de núcleo.
        Limitador térmico adaptable: Ajuste del procesador para mantener una temperatura de usuario predefinidas.

    Cifrado: Incluye el motor VIA PadLock
        Soporte por hardware de cifrado Advanced Encryption Standard, y hashing SHA-1 y SHA-256

 

 

Mar, 06/02/2018 - 16:50
nasciiboy
Imagen de nasciiboy
Desconectado/a
se unió: 20/10/17

interesante investigacion, como aun no se ha propagado ninguna amenasa "real" y actualizo reguralmente (mas alguna que otra precaucion), sin cuidado me tienen siempre las vulnerabilidades.

por algun post del internet creo que puedes comprobar con cuales afecciones cuenta tu cpu con

grep "" /sys/devices/system/cpu/vulnerabilities/*

Mié, 07/02/2018 - 22:05
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

Los Nano, que usan out-of-order, si es probable que estén afectados, aunque es tan poco su uso que no encuentro nada en concreto. Los viejos Via C3/C7 son "in-order", por lo que no se vería afectados, pero los nano si podrían serlo, la verdad, como mínimo a las variantes spectre. Habrá que buscar más detenidamente... (por cierto, yo tengo una laptop vieja que aun funciona con un ViaC3 xD).

Como dije, no he encontrado mucho, lo único en realidad, una pregunta y en un sitio en inglés. Aunque no sea acorde a las normas, te lo dejo, por si te vale para tomar algo  de referecia al respecto

  No hay bar que por bien no venga....
Mié, 07/02/2018 - 22:06 (Responder a #3)
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

nasciiboy wrote:
interesante investigacion, como aun no se ha propagado ninguna amenasa "real" y actualizo reguralmente (mas alguna que otra precaucion), sin cuidado me tienen siempre las vulnerabilidades. por algun post del internet creo que puedes comprobar con cuales afecciones cuenta tu cpu con grep "" /sys/devices/system/cpu/vulnerabilities/*

Si y no, el kernel 4.14 no incluye todavía esa funcionalidad, con lo que si no es uno parcheado o usas un kernel 4.15 esa ruta/dato no existirá en tu sistema.

  No hay bar que por bien no venga....
Jue, 08/02/2018 - 15:18
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

interesante investigacion, como aun no se ha propagado ninguna amenasa "real" y actualizo reguralmente (mas alguna que otra precaucion), sin cuidado me tienen siempre las vulnerabilidades.

No se tiene noticia de que haya habido ningún ataque basado en esto.

De todos modos, como dicen los textos, es un ataque que no deja evidencias después de haber sucedido.

Podrían estar atacando un ordenador, y lo único que notarían es un leve retardo en los resultados, cortesía de la manipulación

de la predicción de saltos.  Después, nada más.

¿El crimen perfecto?.

Y recuerda, que aún con todos los parches aplicados, los propios programadores indican que es una manera de

obstaculizar, -que no cerrar el acceso-, a un atacante.  Todos coinciden en que no parece posible alcanzar la seguridad

 que teníamos, teóricamente, antes de descubrirse eso.

 Es como la puerta de casa. Obstaculiza, impide. Pero si tienen los conocimientos, la habilidad y el interés de entrar, entrarán.

 

por algun post del internet creo que puedes comprobar con cuales afecciones cuenta tu cpu con

 Si si, ya lo he estado haciendo. tengo montones de descripciones de las cpus, páginas de 8 ó 10 sitios que tratan del tema,

 varias listas, incluso detalladas por la serie y uso de cpus que señalan cuales están afectadas,

 Varias páginas de foros que parecían decir algo sobre el tema,  etc

 Pero como dice Panko, no hay mucho acerca de si mi cpu puede o no estar afectada.

 

@Panko: A lo mejor me lio con alguna que se parece, pero creo que esta la tengo ya.

 pero de cualquier forma, gracias.

(por cierto, yo tengo una laptop vieja que aun funciona con un ViaC3 xD).

 Te la cambio !.  laugh

 

 Pues nada, que mientras se demuestra -o no- su implicación en el caso, ya estoy reservándole plaza para una

 nueva instalación este verano.

 Este último le puse un 9.? nuevecito, y sin apenas haberlo usado ya va a recibir uno nuevo.

 (Voy a tener que pedir daños a intel, por haberme hecho tirar una instalación nueva. Kilómetro 0 ).

 

 

 Y mira,  una pregunta adicional:

 Si este verano, que supongo que la versión estable ya será la corregida, me descargo un núcleo,

 y se lo instalo al 9.1 ó 9.2 que tengo, ¿bastaría eso para considerarlo parcheado?,  ¿o hay más cosas

 a tocar y sería mejor volver a instalar desde 0 ?

 

 

Mar, 13/02/2018 - 16:35
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 Siento insistir, pero, ¿nadie tiene una, ni nadie sabe nada?.

 

 Y ...

 

Y mira,  una pregunta adicional:

 Si este verano, que supongo que la versión estable ya será la corregida, me descargo un núcleo,

 y se lo instalo al 9.1 ó 9.2 que tengo, ¿bastaría eso para considerarlo parcheado?,  ¿o hay más cosas

 a tocar y sería mejor volver a instalar desde 0 ?

 

 

Mar, 13/02/2018 - 22:14
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

Hola, No poseo un equipo con Debian en casa.
En Void Linux y ArchLinux32, Spectre v1 y v2, se han suprimido con el kernel 4.15.x (pentium 4 y pentium 3). En los sistemas x86-32, aún no se ha mitigado Meltdown con el Kernel 4.15.x. No es necesario una reinstalación.

Obviamente el fabricante de mis equipos de por*****, no van a lanzar una actualización desde BIOS para parchear los CPU. Si tienes un equipo moderno como mi HP + 10, informate sobre una posible actualización del BIOS.

Intel ha lanzado una nueva revisón del microcodigo, MICROCODE REVISION GUIDANCE, FEBRERO 12 2018.

PD: Hay una lista blanca de procesadores que no se ven afectados por Spectre/Meltdown.
PD2: Por lo que leo en linuxquestion, no es suficiente tener el paquete intel-ucode.

Hasta la vista !

Jue, 15/02/2018 - 04:16
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

El paquete intel-microcode no incluye siempre una actualización para todas las cpu. De momento, la última vez que se actualizó dicho paquete, no tenía microcode parcheado para mi i7 de 3ª generación. Además, luego se volvió a desactualizar debido a la cagada de parcheo que había hecho intel, que provocaba reinicios aleatorios del sistema.

Por otro lado, en sistemas x86_64, el kernel 4.14.0-3 (4.14.13-1) que es el que usa ahora mismo Debian Unstable, si tiene parcheado Meltdown (variante 3) pero no Spectre (variantes 1 y 2). Se puede comprobar mirando la salida del comando

cat /proc/cpuinfo

si en las "flags" aparece pti es que ya tiene la protección contra meltdown del kernel. Además, aparecerá la línea bugs :cpu_meltdown.

Los parcheos para las variantes 1 y 2 se esperan para el kernel 4.15.

  No hay bar que por bien no venga....
Dom, 18/02/2018 - 16:57
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 Para mi sorpresa, este pequeñajo resultó ser un 64bits.

 Siendo de samsung, por el tamaño y por el segmento de uso al que pertenece, siempre lo

 había tomado por un 32 bits.

 Asi que me estoy planteando si ponerle el núcleo 4.15.xx a la instalación 386-32 que tengo,

 o probar que tal corre a 64.

 ... O tal vez durante un tiempo tenga una instalación de cada.  No se ...

 Bueno, tengo hasta el verano para decidirme.  :)

 Pero así las imágenes buenas, cuando lleguen a estable, serán a partir de la 4.15 en adelante

 ¿verdad?.

 

Dom, 18/02/2018 - 18:06
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

meterle x86_64 solo te "rendirá" más según la cantidad de ram que tengas... En muchos casos puede pasar que incluso rinda menos por ese motivo.

Por otro lado... el lanzamiento de Stretch se puede decir que es reciente... y teniendo en cuenta que ahora se realizarán releases cada 2 años, y que la versión del kernel en sid ya incluye un par de mitigaciones (pti para meltdown (Spectre v3) y retpoline (Spectre v2)), que es la 14.4.17-1, tanto si se llega a stable con el kernel 4.14 o el 4.15, imagino llegará con las 3 migaciones ya para ese entonces.

  No hay bar que por bien no venga....
Mar, 20/02/2018 - 16:43 (Responder a #10)
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 De origen, 1 Gb ram si no recuerdo mal.

 

 

Mar, 20/02/2018 - 20:14
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

sigue con x86, no pases a x86_64

  No hay bar que por bien no venga....
Mié, 21/02/2018 - 09:48 (Responder a #12)
tigreci
Imagen de tigreci
Desconectado/a
colaborador
se unió: 31/07/17

Panko wrote:

Los Nano, que usan out-of-order, si es probable que estén afectados, aunque es tan poco su uso que no encuentro nada en concreto. Los viejos Via C3/C7 son "in-order", por lo que no se vería afectados, pero los nano si podrían serlo, la verdad, como mínimo a las variantes spectre. Habrá que buscar más detenidamente... (por cierto, yo tengo una laptop vieja que aun funciona con un ViaC3 xD).

Como dije, no he encontrado mucho, lo único en realidad, una pregunta y en un sitio en inglés. Aunque no sea acorde a las normas, te lo dejo, por si te vale para tomar algo  de referecia al respecto

He de suponer que igualmente podría estar afectado por los dos, también tiene ejecución especulativa(creo que se llamaba asi)

 

Autodidacta sin remedio.

Mié, 21/02/2018 - 16:36 (Responder a #13)
tigreci
Imagen de tigreci
Desconectado/a
colaborador
se unió: 31/07/17

A comprarse una raspberry que no tiene estos problemas ya que no tiene prediccion ni ejecucion fuera de orden y podemos instalar raspbian, ale para salir del paso y navegar y ver pelis no esta mal XD eso si 1 giga de ram es poquito

Autodidacta sin remedio.

Jue, 22/02/2018 - 15:28
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 @ Tigreci:  Ah, si, es la única página que se puede encontrar, aparentemente, que trate directamente del tema.

  La duda está en que al menos uno de los bug se consigue manipulando los indices de probabilidades usados

 para la especulación.

 Pero en lo que he leído de la cpu pone que ejecuta en out of order, pero no dice nada de que especule con

 los posibles saltos o bifurcaciones a tomar.

 

 Y es que no es necesariamente lo mismo.

 https://es.wikipedia.org/wiki/Ejecuci%C3%B3n_fuera_de_orden

 https://wiki2.org/es/Ejecuci%C3%B3n_fuera_de_orden

 

 https://es.wikipedia.org/wiki/Ejecuci%C3%B3n_especulativa

 Especular o no especular, he ahí el dilema. ...

 Que si especulas mucho, se van formando las burbujas, y luego viene el "crack" y se hunde todo. wink

 

 A comprarse una raspberry que no tiene estos problemas ya que no tiene prediccion ni ejecucion fuera de orden y podemos instalar raspbian, ale para salir del paso y navegar y ver pelis no esta mal XD eso si 1 giga de ram es poquito

 Ah!, cierto.  Se me olvidó poner el enlace, que despiste!.

 http://wadalbertia.org/foro/viewtopic.php?f=17&t=7094

 Hay alguno que se salva.

 

Jue, 22/02/2018 - 18:40
tigreci
Imagen de tigreci
Desconectado/a
colaborador
se unió: 31/07/17

SI yo hace tiempo que tengo una raspberry pi 3 y menos mal que se salva sino me veía navegando con una arduino (sarcasmo XD) y ahora viene la pregunta del millon, un sistema operativo virtualizado tendria el mismo problema? es decir al estar virtualizado se supone que no puede salir de suuuu, vamos a llamarlo sandbox y la vulnerabilidad en principio quedaria reducida a la maquina virtual, es esto correcto? o  en realidad daria igual y podria leer memoria fuera del espacio de proceso de la maquina virtual?

Autodidacta sin remedio.

Sáb, 24/02/2018 - 06:40
Panko
Imagen de Panko
Desconectado/a
moderador
se unió: 18/02/16

El problema más grave que trae consigo esta vulnerabilidad, está precisamente en el uso de máquinas virtuales. Imagina una granja de servidores de un hosting que te ofrece vps en lugar de un servidor dedicado. Todos los vps que corren en su propia máquina virtual, comparten el mismo hardware real, con lo que esa vulnerabilidad permitiría acceder a la información de cada vps que corra en ese hardware. Vamos, una máquina real y cinco maquinas virtuales = acceso a las cinco máquinas virtuales.

  No hay bar que por bien no venga....
Dom, 25/02/2018 - 14:36
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 Efectivamente. Si he entendido del derecho lo leído, el mecanismo es que a través de los espacios de la propia cpu,

 -común a todos los sistemas virtualizados-, consigue acceder a datos de zonas "prohibidas a los usuarios humanos",

 e incluso a zonas del propio kernel, con lo cual se están leyendo datos de zonas reservadas al sistema y por

 debajo del nivel en que operan los propios vps residentes.

 

 Por tanto, si puede escabullirse por debajo de los sandbox ,  "jaque mate".  Se escapó.

 

Mié, 07/03/2018 - 21:53 (Responder a #18)
tigreci
Imagen de tigreci
Desconectado/a
colaborador
se unió: 31/07/17

Voy a plantearlo de otro modo si yo parcheo el host/hypervisor pero no las maquinas virtuales seguiria siendo vulnerable en cuanto a nivel de maquina virtual se refiere?

 

Ese es el quid de la cuestion que se me plantea, es decir depende del hypervisor o virtualizador, el como expone el procesador entiendo y supongo que tambien dependera de si realmente lo expone o lo simula correcto?

Autodidacta sin remedio.

Jue, 08/03/2018 - 14:05
Percontator
Imagen de Percontator
Conectado
colaborador
se unió: 20/03/16

 

 A ver que dicen los que saben de esto, pero yo lo entiendo asi.

 

 Digamos que tu tienes un sistema de tracción mecánica distribuida, (como en la época de los telares a vapor, con sus

 poleas i ejes que llevaban la fuerza a cada telar ).

 

 Parece que te están robando vapor por algún sitio, o eso crees.

 "¿Servirá si cambio el tipo o la distribución de las poleas?. "

" ¿ No será que alguien me ha manipulado algún telar? "

 

 La medida sensata sería revisar todos lo "pipes" (tubos) que salen de la caldera, asi como las válvulas de purga o

las de seguridad, A ver si algún punto parece haber sido manipulado.

Es inútil revisar cada telar ya que usa la fuerza, no el vapor directamente.  El punto común es la máquina de vapor.

 

 En la cpu es difícil controlar nada, demasiado compacto y pequeño, pero es lo mismo.

 Si la fuga está en el propio motor no se si va a servir mucho revisar cada uno de los procesos que usan la fuerza

 de la cpu.

 

 Cuando tu bloque de motor gotea aceite no es práctico buscar el problema en la transmisión o en las ruedas.

 

 Al menos yo lo veo así. A ver si me equivoco o estoy en lo cierto.

 

Jue, 08/03/2018 - 17:24 (Responder a #20)
Berbellon
Imagen de Berbellon
Desconectado/a
colaborador
se unió: 04/05/16

tigreci wrote:

Voy a plantearlo de otro modo si yo parcheo el host/hypervisor pero no las maquinas virtuales seguiria siendo vulnerable en cuanto a nivel de maquina virtual se refiere?

 

Ese es el quid de la cuestion que se me plantea, es decir depende del hypervisor o virtualizador, el como expone el procesador entiendo y supongo que tambien dependera de si realmente lo expone o lo simula correcto?

De forma general, para mitigar Spectre/Meltdown se necesita actualizar: firmware/microcode (BIOS/UEFI), núcleo del S.O. y el software (firefox, qemu).

Usamos Qemu:
QEMU and the Spectre and Meltdown attacks.
QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM guests.