Intelbug/Meltdown: Mis pruebas del parche FUCKWIT de Linux en el rendimiento de un sistema doméstico

mceds 6 enero 2018 11:16 ✎ ◉

⋮

Actualización 12/enero/2018: Me habría gustado repetir los tests habiendo aplicado los parches de microcódigo oficiales de Intel para Spectre. Sin embargo, éstos sólo se aplican en micros de Haswell en adelante (ver tabla en gris oscuro), así que mi Core 2 Duo se queda, por el momento, sin ellos 😩. Si alguien con Linux tiene alguno de estos micros, sería de agradecer que realizara los tests con y sin parche (añadiendo el parámetro dis_ucode_ldr en el arranque del kernel, se bloquea el parche; ojo, esto no funciona si se ha actualizado vía BIOS).

Ya tengo un PC "venerable" (2008/2009 revitalizado con un SSD) que, aunque sigue al pie del cañón, sufre cualquier putadita que le hagan los desarrolladores de software en cuanto a mayores demandas de recursos. Si encima resulta que es un Intel y que el imprescindible parche KPTI/KAISER (yo prefiero lo de "FUCKWIT") acarrea una cierta pérdida de rendimiento, uno contempla la posibilidad de actualizar el equipo, preferentemente volviendo a AMD (a la que abandoné por los Core).

Como, antes de gastarme dos o trescientos euros, prefiero estar seguro (la Cofrafía del Puño Cerrado vigila mis movimientos), me he lanzado a hacer un par de tests sencillitos, aprovechando que el parche puede ser "fácilmente" desactivado en Linux, añadiendo una opción en el arranque del kernel.

Antes de nada, les presento al abuelo:

Intel Core 2 Duo E8400 (por supuesto, sin PCID, que empezó a incorporarse en Sandy Bridge).
Placa Asus P5P43TD (chipsets P43/ICH10) con SATA2 (SATA 300).
RAM 4x2048 MB DDR3-1066.
Disco duro SSD Crucial M500 120GB SATA3.

Y el software que voy a usar:

Debian GNU/Linux 9.3
fio 2.16 (test: ssd-test.fio)
Hardinfo 0.5.1

FIO es una herramienta que permite realizar tests personalizados de rendimiento de I/O; por su parte, Hardinfo contiene varios benchmarks que "castigan" la CPU. Sé que se ha dicho por activa y por pasiva que el proceso de computación "en bruto" no sufre apenas los efectos ralentizadores del parche, pero quería comprobarlo por mí mismo.

El test de FIO que voy a ejecutar es el "ssd-test.fio" que figura entre sus ejemplos (descargable desde la página oficial en Github). Consta de cuatro pruebas: una de lectura en acceso secuencial (0), otra de lectura en acceso aleatorio (1), escritura secuencial (2) y escritura aleatoria (3), todas con archivos de 4 kBytes durante un minuto.

He aquí el resumen de los resultados con el parche sin aplicar (si alguien lo quiere, puedo subir los resultados completos a Pastebin):

Run status group 0 (all jobs):
   READ: io=6717.6MB, aggrb=114643KB/s, minb=114643KB/s, maxb=114643KB/s, mint=60001msec, maxt=60001msec

Run status group 1 (all jobs):
   READ: io=5018.8MB, aggrb=85651KB/s, minb=85651KB/s, maxb=85651KB/s, mint=60001msec, maxt=60001msec

Run status group 2 (all jobs):
  WRITE: io=7866.8MB, aggrb=134257KB/s, minb=134257KB/s, maxb=134257KB/s, mint=60001msec, maxt=60001msec

Run status group 3 (all jobs):
  WRITE: io=7292.5MB, aggrb=124455KB/s, minb=124455KB/s, maxb=124455KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  sdb: ios=3004474/3875269, merge=60/473, ticks=431536/435536, in_queue=865008, util=99.42%

Y con el temido parche ralentizador FUCKWIT:

Run status group 0 (all jobs):
   READ: io=6628.5MB, aggrb=113123KB/s, minb=113123KB/s, maxb=113123KB/s, mint=60001msec, maxt=60001msec

Run status group 1 (all jobs):
   READ: io=4957.3MB, aggrb=84602KB/s, minb=84602KB/s, maxb=84602KB/s, mint=60001msec, maxt=60001msec

Run status group 2 (all jobs):
  WRITE: io=7639.7MB, aggrb=130380KB/s, minb=130380KB/s, maxb=130380KB/s, mint=60001msec, maxt=60001msec

Run status group 3 (all jobs):
  WRITE: io=7107.6MB, aggrb=121300KB/s, minb=121300KB/s, maxb=121300KB/s, mint=60001msec, maxt=60001msec

Disk stats (read/write):
  sdb: ios=2966662/3773917, merge=41/522, ticks=426072/429820, in_queue=853836, util=98.96%

Si mis tests son correctos, parece que los "no-alarmistas" tenían razón: el impacto afecta severamente a los grandes servidores y data centers, pero los equipos domésticos apenas lo notan. Y eso que mi equipo, con sus limitaciones debidas a su antigüedad y a que el procesador carece de PCID, debería ser de los más perjudicados. Pero la pérdida de rendimiento es apenas de un 1,3% en lectura tanto secuencial como aleatoria, 2,9% en escritura secuencial y 2,5% en escritura aleatoria.

En cuanto a los tests de la CPU, aquí sin parche:

CPU Blowfish
This Machine 3003 MHz 5.846 seg.
CPU CryptoHash
This Machine 3003 MHz 362.693
CPU Fibonacci
This Machine 3003 MHz 2.380 seg.
CPU N-Queens
This Machine 3003 MHz 7.541 seg.
FPU FFT
This Machine 3003 MHz 2.707 seg.
FPU Raytracing
This Machine 3003 MHz 5.090 seg.

Con parche:

CPU Blowfish
This Machine 3003 MHz 6.066 seg. (-3,7%)
CPU CryptoHash
This Machine 3003 MHz 357.900 (-1,7%)
CPU Fibonacci
This Machine 3003 MHz 2.384 seg. (-0,2%)
CPU N-Queens
This Machine 3003 MHz 7.647 seg. (-1,4%)
FPU FFT
This Machine 3003 MHz 2.639 seg. (-2,5%)
FPU Raytracing
This Machine 3003 MHz 5.274 seg. (-3,5%)

Curiosamente, algunos tests de CPU como el Blowfish o el de coma flotante "retardan" más la máquina que las más exigentes pruebas de I/O. Eso también me hace considerar la posibilidad de que esté pasando algo por alto en estas últimas.

En cualquier caso, conclusión: no actualizo el equipo, por ahora.

sierpinski 6 enero 2018 11:23

⋮

Yo en la vida sigo la filosofía "lo contrario de lo que digan los periodistas".

Si los periodistas dicen "ha pasado esto y se va a perder un 30-50% de rendimiento" ya sé que ni lo voy a notar.

Esto se puede aplicar a absolutamente todo, no sólo la tecnología.

✖

mceds 6 enero 2018 11:28

⋮

El problema de los periodistas cuando hablan de tecnología es que su algoritmo de escritura es, básicamente, un cat /dev/urandom | base64 . O sea, que apostar a que siempre se equivocan es bastante arriesgado, ya que pueden acertar por pura chiripa.

✖

sierpinski 6 enero 2018 11:29

⋮

en.wikipedia.org/wiki/Infinite_monkey_theorem

✖

mceds 6 enero 2018 11:35

⋮

La lectura de ese artículo siempre me despierta ganas de cargar una furgoneta con monos y máquinas de escribir, para ir reventando WPAs por allende los vecindarios.

Alguna contraseña "qwertyuiop" caería, fijo.

✖

sierpinski 6 enero 2018 11:44

⋮

✖

mceds 6 enero 2018 11:59

⋮

✖

sierpinski 6 enero 2018 12:04

⋮

BocaDePez 6 enero 2018 12:18

⋮

Es complicado, cuando no sabes como funcionan por dentro los programas, y cuando no sabes si tiran de disco, si consumen demasiada memoria (swap) o que...

Yo no me complicaria la vida con benchmarks sinteticos, a no ser que sea eso a lo que te dediques con tu maquina. Pon el parche, usa tu maquina de forma normal, y mira a ver si lo notas. Si no lo notas, adelante. Si lo notas, pues o bien arrancas con esa opcion desactivada (creo que en linux se controla por parametro de boot si asi lo deseas) y vas con cuidado con lo que ejecutas, o bien upgradeas.

Comentar tambien que no creo que sea solo "un parche". Como hablamos de mas de una vulnerabilidad y sobretodo un vector nuevo de ataque, habra cambios desde microcodigo de cpu's hasta navegadores (timers) o compiladores (retnpolin), asi que son cambios en todo el ecosistema para protegerse contra lo que pudiese venir.

Comentar tambien que a diferencia de otros exploits, y segun tengo entendido, estos son para poder leer la memoria... ya se que es menos que nada, pero si no haces banking o cosas asi privadas y por decir algo solo usas el pc para hacer renders, pues igual no te importa demasiado lo que pudieran o pudiesen tener acceso.

Y ya ni te cuento si desconectas la maquina de internet :)

✖

sierpinski 6 enero 2018 12:21

⋮

Me parece interesante que menciones el home banking. Yo personalmente sólo conecto desde el teléfono móvil porque un ordenador tiene demasiados vectores de ataque.

✖

mceds 6 enero 2018 16:52

⋮

La única manera razonablemente segura de hacer home banking es con una Live CD y prescindiendo de los DNS. Me temo que los móviles no se llevan muy bien con las Live CD.

Yo me conecto a mi banco tanto desde el PC como desde el móvil, pero porque ambos tienen sistemas operativos raros y eso reduce su atractivo para el phishing. Aunque si tuviera que escoger, preferiría el PC. Acabo de buscar "apple store malware" esperando no encontrar nada, ¡y lo hay! Con Google Play ya ni me molesto...

mceds 6 enero 2018 12:35

⋮

Hombre, es que "notar" es bastante subjetivo e incluso proclive a factores psicosomáticos. Es como cuando ves un documental sobre pulgas o garrapatas, que te comienza a picar todo el cuerpo. Si estás preocupado por lo del "30%", vas a achacar al parche lo que perfectamente pueden ser hijoputadas de Google con sus servicios, por ejemplo.

Con "el parche" me estoy refiriendo exclusivamente al de Meltdown, que afecta a Intel y a alguna arquitectura ARM puntual y minoritaria. Ya sé que luego están los Spectra que, aunque remotamente relacionados, son cuestiones aparte.

Por último, yo tengo entendido que se puede hacer algo más que "sólo leer". Ya de entrada, si puedes leer la contraseña de root, el Pwned es bastante serio. Imagina que viene el hijo de puta de turno y te cifra todos tus renderings, pidiendo rescate a cambio.

mceds 6 enero 2018 12:27

⋮

Más datos, no con pruebas sino "a ojímetro": también he parcheado mi equipo multifunción (un Celeron J1900), que es a la vez router neutro y servidor P2P. Le he arrancado aMule por un lado y Transmission por otro, bajando una distro con muchas fuentes: I/O a saco, tanto de red como de acceso a disco.

Con el rabillo del ojo he podido ver la actividad de sus cuatro núcleos en una pantallita LCD. Dos de ellos estaban absolutamente dormidos y los otros dos mostraban una actividad de 10-20%; pero, mirando a la gráfica de I/O Wait, el motivo estaba claro: el cuello de botella era el disco duro mecánico (un Seagate a 7200).

Vamos, que a un equipillo de consumo ultrabajo y prestaciones en consonancia tampoco le afecta. También es verdad que lo tengo con una tarjeta de red dual Intel, que no tiene nada que ver con las Realtek baratuchas que vienen integradas en las placas base.

pepejil 6 enero 2018 14:33

⋮

Habria que ver con una CPU de las nuevas, a ver el impacto de rendimiento.

Creo yo que los que más van a notar esta "pérdida de rendimiento" son los que tienen CPUs más modernas y más exigentes.

OFFTOPIC: Cuidado con los que instaleis el KB4056892 que supuestamente parchea Meltdown y teneis un AMD de los antiguos. Teneis un bonito boot-freeze del copón.

✖

mceds 6 enero 2018 16:54

⋮

Al contrario. Según Intel, PCID minimiza bastante esa pérdida de rendimiento.

Pero claro, Intel ha dicho muchas cosas en los últimos días. ¿Alguien que tenga algo más o menos moderno, de Sandy Bridge en adelante, y que pueda hacer alguna prueba similar?

✖

pepejil 6 enero 2018 16:56

⋮

Después de ver como Intel en un primer momento echaba balones fuera diciendo "que no solo le afecta a ellos", no me creo absolutamente nada.

Mi teoría es porque al ser más modernos y tener más mierda implementada, parchearlos requiere de más sufrimiento. Pero vamos, que igualmente, sea un 3% que un 30%, me parece una cagada de las gordas.

BocaDePez 6 enero 2018 14:45

⋮

estoy en la misma situación, un post muy util, gracias!

BocaDePez 6 enero 2018 15:47

⋮

Perder hasta un 3% en tests sintéticos de I/O que no muestran un comportamiento con muchos fallos de página y cambios de contexto indica una gran pérdida de rendimiento. En dichos tests la disminución de rendimiento debería de ser del 0%.

La ganancia de Intel entre generaciones de procesadores se ha reducido a un mísero 5%. Así que si ya con tests sintéticos se puede perder hasta un 3% significa que anulas la mejora de las nuevas generaciones.

Mejor AMD para no perder el rendimiento por KPTI.

✖

sierpinski 6 enero 2018 15:58

⋮

Un 5% para cálculos generales, pero ignoras que entre generaciones se introducen mejoras como la decodificación de h264/h265/vpx por hardware, cálculos de hashes, y mil cosas más que no aparecen en benchmarks sintéticos.

✖

BocaDePez 6 enero 2018 15:59

⋮

Los códecs en ASIC son malos para codificar.

✖

sierpinski 6 enero 2018 16:01

⋮

El 99,9% de usuarios decodifica, que es lo que importa. Si vas a ver una peli h265 prefieres que tu CPU gaste un 5%, no un 100%. Especialmente si estás en un ordenador portátil.

✖

BocaDePez 6 enero 2018 17:15

⋮

✖

sierpinski 6 enero 2018 17:18

⋮

✖

BocaDePez 6 enero 2018 18:46

⋮

✖

sierpinski 6 enero 2018 19:16

⋮

mceds 6 enero 2018 16:58

⋮

Yo no he dicho que la pérdida sea cero, pero desde luego está bastante lejos del apocalipsis del 10-30% que estaban diciendo por ahí.

En la situación de tener que comprar nuevo, desde luego que ahora me decantaría por AMD. Pero ¿sustituir? Con esos números, tengo claro que no.

✖

pepejil 6 enero 2018 17:03

⋮

Es pronto para saberlo. De momento ya tenemos datos objetivos con un Core2Duo. A ver en todas las generaciones i.

BocaDePez 6 enero 2018 17:16

⋮

Con los tests que has puesto no puedes predecir el comportamiento con cargas de trabajo más diversas.

✖

mceds 6 enero 2018 17:22

⋮

Esos tests son muy duros. Me estaba subiendo el I/O Wait al 70-80%. Desde luego que no se puede predecir nada, pero no logro imaginar qué cargas de trabajo, en mi vida diaria, pueden forzar I/O de ese modo. No manejo bases de datos ni edito vídeo en plan profesional. Los backups me da igual que tarden 10 que 20 minutos.

✖

BocaDePez 6 enero 2018 18:41

⋮

✖

mceds 6 enero 2018 19:11

⋮

Bilbokoa 6 enero 2018 16:28

⋮

Cada cual que haga lo que quiera. Yo paso totalmente de todas estas mierdas. Ni sé lo qué es, ni en qué consiste el bug. Llevo días aguantando el 'apocalípsis' de los medios de prensa ("tu PC se volverá muy lento", "puedes perder hasta un 50% del rendimiento") y paso, pero bien.

Sigo usando mi ordenador, comprado en junio (un Asus GL-702VS), como todos los días, siempre actualizado en todo, parches, Windows Update, drivers, etc, y a correr.

La prensa, las páginas web o quien sea, puede seguir vendiendo el fin del mundo. Y el que lo desee, puede perder su tiempo en hacer mil análisis y tests pre y post parches y perderse en un debate sin fin acerca de si la pérdida de rendimiento es mucha, poca o ninguna.

Buenas tardes, y que paséis todos un feliz día de Reyes. 😊

✖

pepejil 6 enero 2018 16:58

⋮

Que te compres un procesador que diga que te rinde X pero que después de encontrar un agujero de seguridad, para parchearlo es Y, no es el fin del mundo, es directamente una ESTAFA.

Pero cada uno con sus percepciones y sus historias. A mi personalmente, el ver como una empresa que acapara un porcentaje significativo de procesadores vendidos hace ocultismo de un problema de seguridad gordo, deberia darnos miedo a todos.

✖

sierpinski 6 enero 2018 17:14

⋮

Es tu opinión. Yo no le doy mayor importancia, dadas las circunstancias. Un problema de fábrica como muchos otros. Una pequeña cagada, sí, pero una estafa no.

✖

pepejil 6 enero 2018 17:17

⋮

Nah, un problema de fábrica que solo provoca que un hipotético código pueda saber las acciones de todos los procesos al no haber separación entre kernel y usuario. Nada, poca cosita oye. Como robar un chicle en un kiosko.

Y que encima Intel ya sabía desde hace tiempo y no tuvo los cojones de ponerse manos a la obra hasta que saltó la noticia hace unos días. Me da una seguridad que flipas.

✖

sierpinski 6 enero 2018 17:19

⋮

✖

pepejil 6 enero 2018 17:22

⋮

✖

sierpinski 6 enero 2018 17:29

⋮

Bilbokoa 6 enero 2018 17:32

⋮

Que sí, pepejil, que sí, estoy super afectado por todo esto, sí.. Voy a pegarme un tiro, ¡no quiero vivir más en este mundo de mentiras y estafas!

Hasta siempre.

✖

pepejil 6 enero 2018 17:32

⋮

Buen argumento. Para aportar normalidad, mejor no aportes nada.

✖

Bilbokoa 6 enero 2018 17:34

⋮

✖

pepejil 6 enero 2018 17:34

⋮

BocaDePez 7 enero 2018 19:03

⋮

¡no quiero vivir más en este mundo de mentiras y estafas!

Hombre, mucho gusto. Bienvenido al planeta Tierra. ¿Ha retuiteado ya el mensaje?

La verdad es que la claúsula "un juanquer ruso lo hizo" ya estaba muy trillada. El negocio de la privacidad y seguridad de los datos personales en la nube ya no tiene gracia desde que publicaron Windows 10 como el minero de datos por excelencia, o el superanonimato con la verificación en dos pasos del móvil. Hasta el recaptcha de Google te lo ponen para publicar un mensaje en cualquier foro.

Venga, les damos un 5 por originalidad y un 9 sobre 10 en la escala de alarma nuclear a los medios. Hay que vender micros, como seaaaa.

BocaDePez 7 enero 2018 13:21

⋮

No es una estafa, no habido intención de estafar. Ellos te han vendido un procesador que cumple las especificaciones en su momento, que luego se ha descubierto una vulnerabilidad, pues mala suerte, pero eso no es una estafa. Otra cosa hubiese sido que te vendan un micro de 3.2GHz pero que en realidad sea de 2.6GHz, por ejemplo. A eso sí se le llama estafa.

Estafa es por ejemplo lo que hizo Xiaomi. Vender un modelo de móvil anunciándolo con un sensor de cámara Sony, que sólo lo pusieron en las primeras unidades, luego al resto le pusieron un sensores Samsung (cuando se descubrió la mentira dijeron que era por falta de suministro), pero seguían anunciándolo como de Sony.

Estafa es un fabricante chino de tarjetas microSD que te anuncia tarjetas de 64GB y luego realmente tienen 16GB, falseado a nivel de hardware de modo que ni el ordenador se entere de la capacidad real, pero que cuando llega al límite la tarjeta empieza a sobreescribir sobre zonas ya escritas.

✖

mceds 7 enero 2018 13:33

⋮

Yo diría que un bufete medio competente podría rascar bastante por aquí:

Intel lanzó su generación Coffee Lake sabiendo que los procesadores eran vulnerables a Meltdown y Spectre

✖

BocaDePez 7 enero 2018 13:56

⋮

✖

mceds 7 enero 2018 15:00

⋮

✖

BocaDePez 7 enero 2018 16:07

⋮

✖

mceds 7 enero 2018 16:21

⋮

✖

BocaDePez 7 enero 2018 20:04

⋮

✖

mceds 7 enero 2018 21:35

⋮

✖

BocaDePez 7 enero 2018 23:21

⋮

✖

mceds 8 enero 2018 07:03

⋮

rbetancor 7 enero 2018 13:58

⋮

El punto 'crítico', es que si 'la solución' que aplican para solventar la vulnerabilidad del producto, reduce las prestaciones del mismo y el usuario no recibe una correcta compensación, entonces es cuando podemos hablar de ESTAFA. No estamos hablando que te vendan un 2.6Ghz remarcado como 3.2Ghz ..., sino que tu flamante 3.2Ghz va a ir como un 2.6Ghz en cuando le apliques la solución del fabricante a la vulnerabilidad ... y TU no pagaste por un 2.6Ghz, así que te han de compensar por la perdida de rendimiento.

✖

BocaDePez 7 enero 2018 14:13

⋮

✖

rbetancor 7 enero 2018 16:58

⋮

✖

sierpinski 7 enero 2018 19:25

⋮

✖

rbetancor 7 enero 2018 19:31

⋮

BocaDePez 7 enero 2018 20:16

⋮

✖

sierpinski 7 enero 2018 20:23

⋮

✖

BocaDePez 7 enero 2018 21:01

⋮

BocaDePez 7 enero 2018 20:24

⋮

✖

sierpinski 7 enero 2018 20:27

⋮

✖

BocaDePez 7 enero 2018 20:39

⋮

✖

sierpinski 7 enero 2018 20:57

⋮

✖

BocaDePez 7 enero 2018 21:08

⋮

✖

sierpinski 7 enero 2018 21:30

⋮

✖

BocaDePez 7 enero 2018 23:09

⋮

rbetancor 7 enero 2018 20:49

⋮

✖

BocaDePez 7 enero 2018 21:05

⋮

✖

mceds 7 enero 2018 21:39

⋮

rbetancor 7 enero 2018 21:57

⋮

✖

BocaDePez 7 enero 2018 23:07

⋮

✖

rbetancor 8 enero 2018 00:29

⋮

✖

BocaDePez 8 enero 2018 01:49

⋮

✖

BocaDePez 8 enero 2018 07:23

⋮

rbetancor 8 enero 2018 08:32

⋮

✖

BocaDePez 8 enero 2018 14:31

⋮

✖

rbetancor 8 enero 2018 14:53

⋮

✖

BocaDePez 8 enero 2018 16:15

⋮

Emad 10 enero 2018 17:23

⋮

pepejil 7 enero 2018 16:56

⋮

que luego se ha descubierto una vulnerabilidad, pues mala suerte, pero eso no es una estafa.

Estafa es que la imagen pública de Intel es de "echar balones fuera" y con esa actitud, deja más que clara que la solución es que los consumidores "nos jodamos".

Maravilloso servicio post-venta por parte de Intel.

BocaDePez 6 enero 2018 17:11

⋮

De acuerdo, Meltdown solucionado. El problema es Spectre, que afecta a más procesadores (no solo los de Intel) y no es tan fácil de parchear. También es verdad que Spectre es más difícil de explotar.

✖

mceds 6 enero 2018 17:17

⋮

Lo preocupante de Spectre es que afecta también a ARM, es decir, a la arquitectura favorita de los móviles. Y ya sabemos todos que ciertos sistemas operativos móviles, combinados con ciertas marcas y ciertos proveedores de telefonía, no se llevan muy bien con eso de "actualizaciones de seguridad" y peor aún con lo de "actualizaciones de seguridad durante un plazo razonable".

Si yo fuera un cracker delincuente informático, iría probablemente a intentar explotar Spectre en Android.

✖

pepejil 6 enero 2018 17:26

⋮

Lo bueno de Spectre es que solo se puede explotar localmente. Vamos, que si quieres explotarlo remotamente, necesitas autorización del usuario local si o si.

Si la peña no estuviera tan jodidamente loca instalando apps de mierda, el problema estaría controlado, al menos hasta que llegue el parche a todos los dispositivos, pero ya me puedo imaginar que puede pasar.

Aunque ahora, afortunadamente, con Google Play Protect, la cosa ha ido a mejor.

✖

mceds 6 enero 2018 17:32

⋮

Aunque ahora, afortunadamente, con Google Play Protect, la cosa ha ido a mejor.

Humm...

theregister.co.uk/2017/10/26/google_play…malware_bad/

✖

pepejil 6 enero 2018 17:35

⋮

pepejil 6 enero 2018 17:18

⋮

Meltdown solucionado, pero con consecuencias.

BocaDePez 7 enero 2018 20:20

⋮

El problema que estáis señalando y debatiendo, no es el principal problema. El problema de rendimiento de los procesadores, el gasto por un procesador que ahora está capado, es / son un segundo problema. El problema principal es el "fallo" intencionado, el agujero de seguridad desde hardware. Habría que preguntarse y exigir respuestas bien demostradas y argumentadas, sobre quién se ha estado beneficiando de nuestra información, de nuestro acceso a nuestra privacidad, contraseñas, datos personales, profesionales, bancarios. Desde agencias de protección de datos, fiscalías, derechos del consumidor, demandas civiles y penales. Esto es un escándalo mayúsculo del que cada uno podríamos perfectamente pedir indemnizaciones millonarias por cada procesador y nuestra privacidad.
Esto es enormemente más preocupante que el ransomware pero los mass media no le dan la importancia real, y como mucho, se limitan a informar sobre la merma de capacidad del procesador.

✖

mceds 7 enero 2018 21:40

⋮

Si ha sido intencionado, no te preocupes que los papeles se desclasificarán en el año 3100 más o menos.

BocaDePez 8 enero 2018 06:02

⋮

Al OP, estate atento a cuando actualicen el microcódigo porque parece ser que en otros SO existe una mayor pérdida de rendimiento cuando se actualizan a la vez los parches para el núcleo del SO y las bios más recientes (y en éstas se actualiza el microcódigo de determinados procesadores). A día de hoy el más actual que veo accesible en la página de intel es la versión: 20171117 ( Que viene siendo la fecha :P y SUPONGO que no soluciona o palía el problema. ).

✖

mceds 8 enero 2018 07:16

⋮

Bueno, en Linux se actualiza desde el sistema operativo y no desde la BIOS*. Además, es un paquete optativo de la rama "Non-free". Pero sí, estaré atento a los parches de Spectre a ver qué ocurre.

* Andaría yo listo si tuviera que confiar en que Asus actualizara la BIOS de una placa del año 2009. De hecho, aún estoy esperando a que su ex-familiar, Asrock, me actualice el de una Q1900M (bastante más reciente, 2014) por el tema de la vulnerabilidad del IME, valga la redundancia.

✖

BocaDePez 8 enero 2018 07:51

⋮

"...en Linux se actualiza desde el sistema operativo y no desde la BIOS..."

Eso depende del sistema. Yo por ejemplo hago la actualización manualmente, con herramientas además "cogidas/adaptadas" de debian. Tengo slackware. Y respecto a la bios según la wiki de arch, el microcódigo sí se puede actualizar desde bios automáticamente en cada inicio: "...While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot..." "...The microcode might already be in your vendor bios and not show up loading in dmesg. Compare to the current microcode running grep microcode /proc/cpuinfo ..."

El link al último firmware de intel por si alguien lo quiere probar manualmente (google: linux microcode data file)

En cualquier caso te lo comentaba para que estuvieses atento por confirmar o no cosas como esta:

✖

mceds 8 enero 2018 07:56

⋮

¿De qué página es ese gráfico? Tengo que verificar si se trata de Meltdown+Spectre, porque se supone que lo de Meltdown no se puede solucionar con microcódigo.

No conocía esa característica de las BIOS modernas. Es lo que tiene manejar cacharros viejunos.

✖

BocaDePez 8 enero 2018 08:17

⋮

✖

mceds 8 enero 2018 08:53

⋮

BocaDePez 8 enero 2018 08:01

⋮

Una última cosa: Que Intel actualice ese archivo o tu distro el paquete correspondiente no quiere decir que en el mismo exista una actualización del microcódigo para un determinado procesador. Por ejemplo un intel como el que comentas de 2008 probablemente el microcódigo más actual date de 2010 o similar; y cada año intel saca actualizaciónes de ese archivo para nuevos procesadores. Osea que para comprobarlo realmente tienes que ver el contenido de /proc/cpuinfo y ver si el microcódigo cambia realmente.

✖

mceds 8 enero 2018 08:07

⋮

✖

BocaDePez 8 enero 2018 08:58

⋮

✖

mceds 8 enero 2018 09:06

⋮

ToooWuu 8 enero 2018 12:19

⋮

> Yo por ejemplo hago la actualización manualmente, con herramientas además "cogidas/adaptadas" de debian. Tengo slackware.

¿Y cual es el motivo de usar esas herramientas de debian?
Tienes iucode_tool en slackbuilds.

✖

BocaDePez 8 enero 2018 13:23

⋮

✖

BocaDePez 8 enero 2018 13:40

⋮

Bilbokoa 9 enero 2018 21:08

⋮

Mientras parte de la industria tecnológica se preocupa por afirmar que las actualizaciones para mitigar las vulnerabilidades Spectre y Meltdown tienen un insignificante impacto en el rendimiento, Microsoft sorprende con un informe donde se detalla que no siempre será así. Los de Redmond afirman que los usuarios con ordenadores modernos y Windows 10 no notarán cambios significativos, pero los propietarios de un equipo no tan reciente con Windows 7 y Windows 8 sí apreciarán un descenso del rendimiento.

En una entrada publicada en el blog oficial de Microsoft, Terry Myerson, vicepresidente ejecutivo del grupo Windows y Dispositivos, explica que los equipos con Windows 10 que se sirvan de un procesador Haswell de Intel o anterior experimentarán una ralentización del sistema que notarán algunos usuarios. En caso de que ese mismo ordenador corra sobre Windows 7 o Windows 8 existirá una disminución del rendimiento que notarán la mayoría de usuarios.

Los equipos menos afectados por los parches que buscan mitigar los efectos de Spectre y Meltdown serán los que usen Skylake, Kaby Lake de Intel o una microarquitectura más moderna. Según Microsoft estos ordenadores muestran ralentizaciones de un dígito, y la compañía pronostica que la mayoría de usuarios no notará ninguna diferencia ya que hablamos de un porcentaje que se refleja en milisegundos.

Con Windows 10 ejecutándose en Skylake, Kaby Lake o un procesador más moderno existe una “ralentización de un solo dígito”, pero la mayoría de usuarios no debería notarlo.
Con Windows 10 ejecutándose en Haswell o un procesador más viejo se observa una “ralentización más significativa” y “algunos usuarios notarán una disminución en el rendimiento del sistema".
Con Windows 7 o Windows 8 ejecutándose en Haswell o un procesador más viejo “la mayoría de usuarios notarán una ralentización en el rendimiento del sistema”.

Microsoft también aborda cómo afecta la solución a Spectre y Meltdown en Windows Server, afirmando se aprecia un impacto significativo en el rendimiento en función de la intensidad de las cargas de trabajo. Por ese motivo y sin que sirva de precedente, Microsoft invita a los administradores de sistemas a evaluar si deben o no aplicar los parches. Si un servidor solo ejecuta código administrado y no está abierto a un ataque vía navegador u otro código se podría esquivar la actualización de firmware. Sin embargo, esto implica riesgos y no evita que en un futuro sí se deban aplicar los parches.

Microsoft informa que ya ha ofrecido actualizaciones para mitigar los efectos de Spectre y Meltdown en 41 de las 45 ediciones de Windows existentes. El resto recibirán su parche pronto. Se trata de un proceso que están completando otras compañías responsables de sistemas operativos y navegadores como Google y Apple, pero que en el caso de Microsoft ha sufrido un problema con algunos chipsets AMD. Actualmente ambas compañías están trabajando para solucionarlo.

✖

sierpinski 10 enero 2018 11:53

⋮

Lo he visto. Tengo Haswell. Pues lo menos un año o dos más voy a aguantar con mi procesador, de momento no pienso comprar otro.

BocaDePez 10 enero 2018 14:39

⋮

Por suerte tengo una torre con AMD Phenom II, lo malo que mi portátil es Ivy Bridge y, a fecha de hoy, no pienso cambiarlo hasta que se averíe.

Es más, si hoy tuviera que comprar un nuevo equipo portátil esperaría a que salgan equipos con APU Ryzen de bajo consumo. Lo último que haría es premiar a Intel comprando de nuevo otro procesador con bug.

✖

AsmGuy 10 enero 2018 15:01

⋮

En realidad es una advertencia.

mceds 10 enero 2018 16:28

⋮

Yo me he comprado un micro más potente de segunda mano (por fortuna, mi portátil tiene Socket P y puedo cambiarlo). Así no premio a Intel pero puedo compensar la posible bajada de rendimiento.

Solospam 15 enero 2018 17:32

⋮

Buenas, hoy he recibido dos actualizacizaciones de la bios e Intel vía windows update:

Se pupone que esto son el parche para evitar esas vulnerabilidades? Cuando cliclo para ver info en la web me sale una página de microsift con un mensaje "coming son"

Y cuando me descargo el último firmware de la bios de la página oficial me aparece

Se pupone que al haber realizado la entrega a través de windows update ya quedo "fuera de riesgo"?

Gracias!

✖

mceds 15 enero 2018 18:54

⋮

Mmmm... noviembre y diciembre, yo diría que no.

¿No hay más información que ésa de la BIOS?

✖

Solospam 15 enero 2018 19:33

⋮

Pues no... pero bueno, es una toshiba... y después de que la empresa se decarara en quiebra, es sorpredente recibir una actualización de bios por windows update y no por su soporte, por lo menos raro es... de ahí mi cuestión; por si podría estar solucionando el problema ese

Lo que si aprecio, son los picos de procesador y exceso de RAM en reposo (antes 3 GB a lo sumo y desde la actualización no baja de 4); y el micro en reposo estaba entre 5 y 10%, y en "encefalograma plano".

Ahora mismo lo único que tengo activo es el youtube. Este es mi portatil

✖

mceds 15 enero 2018 19:50

⋮

¿Modelo concreto? Ya por curiosidad.

✖

Solospam 15 enero 2018 20:17

⋮

✖

mceds 16 enero 2018 17:51

⋮

✖

Solospam 16 enero 2018 20:08

⋮

✖

mceds 17 enero 2018 01:22

⋮

✖

Solospam 17 enero 2018 15:06

⋮

✖

mceds 17 enero 2018 17:46

⋮

sjlopezb 21 enero 2018 13:47

⋮

Pufffff... Viendo esto, da repelús...

Yo, ya dije en mi blog, pero algo dice cuando hago esto con otra nueva versión de spectre-meltdown-checker...:

:/home# spectre-meltdown-checker -v
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 4.14.13 #1 SMP Sat Jan 13 14:32:35 CET 2018 x86_64
CPU is Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz
Will use vmlinux image /boot/vmlinuz-4.14.13
Will use kconfig /boot/config-4.14.13
Will use System.map file /proc/kallsyms

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: NO
* The SPEC_CTRL CPUID feature bit is set: NO
* The kernel has set the spec_ctrl flag in cpuinfo: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Performance impact if PTI is enabled
* CPU supports PCID: NO (no security impact but performance will be degraded with PTI)
* CPU supports INVPCID: NO (no security impact but performance will be degraded with PTI)
* Checking if we're running under Xen PV (64 bits): NO
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)

Como se puede demostrar, el Spectre, eso sí, ahí, con la vulnerabilidad, pero no en el Meltdown.

Debemos ir cuidadosos con todo esto...a ver qué es lo que nos hacen hoy... 😕

✖

mceds 21 enero 2018 14:00

⋮

Respecto a Spectre, comienzo a olerme y temerme que Intel no va a sacar parches de microcódigo para nuestros Core 2 Duo. De momento y según el test de XLabs de Tencent (¿alguien conoce otro?), todos los navegadores que tengo instalados son invulnerables. Habrá que confiar en esa primera barrera.

✖

sjlopezb 21 enero 2018 14:12

⋮

Pues apañados vamos. Si se sigue con esta cosa...tremendo... Esto es inaudito. Si no ponen parches para nuestros Core2Duo, vamos de mal a peor.

Na. En meses, si éste casca, en el otro no habrá problema, y haga el parche (si es que no lo tenga el mismo hecho ya o instalado). Sino, me conformo con lo que haga, porque tengo la certeza de que no va a haber problema.

Y sí, en el Firefox, me dice que no es vulnerable, así que, de momento...tranquilo. ¡Qué raro!

BocaDePez 21 enero 2018 19:59

⋮

Respecto a:

"CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 23 opcodes found, should be >= 70, heuristic to be improved when official patches become available)"

prueba con un kerner >= 4.14.14 . Con respecto a: "CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation" Estamos jodios/vendidos... :/

Checking for vulnerabilities against running kernel Linux 4.14.14 #2 SMP Wed Jan 17 12:56:07 CST 2018 x86_64
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (79 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

✖

sjlopezb 21 enero 2018 20:11

⋮

No me atormenta, porque debo esperar por el 4.14.15, o como poco, 4.15.0. 😊

Por tanto, no me corre prisa. Ya que, es una máquina vieja y no interesa que haga semejantes disparates. En cuanto llegue la versión que digo, hago el resto y no tendré ni problemas en compilar como si no fuera nada.

Es más, me prometo mismo, que lo hago por cada 5 versiones que existan. Sólo lo hice a nivel técnico, para ver lo que hacía, pero ya vi que, mucho bla, bla, bla...pero ni el parche.

En el 4.14.14, sí, tienen eso arreglado. No hay prisa en hacer este trabajo en cuestión de 3 horas de compilado, que es lo que me cuesta a la hora de hacer ese trabajo.

A mí no me molesta compilar la versión que se precise en cada momento. ;-)

sjlopezb 21 enero 2018 20:40

⋮

Acabé de bajar el 4.14.14, y puedo decir, que a mí me ha dado 2 líneas más con 'make prepare':

CONFIG_RETPOLINE=y
(...)
CONFIG_GENERIC_CPU_VULNERABILITIES=y

Estos son los que faltan para hacerlos funcionar. Ya que, el primero ya dice:

CONFIG_RETPOLINE:

Compile kernel with the retpoline compiler options to guard against
kernel-to-user data leaks by avoiding speculative indirect
branches. Requires a compiler with -mindirect-branch=thunk-extern
support for full protection. The kernel may run slower.

Without compiler support, at least indirect branches in assembler
code are eliminated. Since this includes the syscall entry path,
it is not entirely pointless.

Symbol: RETPOLINE [=y]
Type : boolean
Prompt: Avoid speculative indirect branches in kernel
Location:
-> Processor type and features
Defined at arch/x86/Kconfig:432

Por el momento, no lo haré, en cuanto me llegue la 4.14.15, lo hago. O 4.15.0.

mceds 22 enero 2018 14:52

⋮

¿Sería mucha molestia para ti hacer una prueba de rendimiento I/O con ese 4.14.14 y con uno anterior?

✖

BocaDePez 27 enero 2018 20:35

⋮

Con la rama 4.14* paso pk me llevaría mucho tiempo pk no tengo los kernels anteriores al estar usando por un lado los oficiales y por otro la rama "current". Tendría que bajarme uno anterior y compilarlo en igualdad de condiciones con los oficiales para que fuese una comparación justa.

Por otro lado tengo unos custom (con parches ck, bfq y demás) más antiguos:

ls /boot/vmlinuz-4.4.*
/boot/vmlinuz-4.4.15 /boot/vmlinuz-4.4.27 /boot/vmlinuz-4.4.38
/boot/vmlinuz-4.4.16 /boot/vmlinuz-4.4.30 /boot/vmlinuz-4.4.63
/boot/vmlinuz-4.4.20 /boot/vmlinuz-4.4.31 /boot/vmlinuz-4.4.74
/boot/vmlinuz-4.4.24 /boot/vmlinuz-4.4.35 /boot/vmlinuz-4.4.94

y éstes sí que los podría comparar con un 4.4.113 que supongo ya incluirá los parches.

stable:

4.14.15

2018-01-23

longterm:

4.4.113

2018-01-23

Checking for vulnerabilities against running kernel Linux 4.14.15 #2 SMP Thu Jan 25 14:56:52 CST 2018 x86_64

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES
> STATUS: NOT VULNERABLE (103 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

BocaDePez 10 febrero 2019 15:29

⋮

Tengo un Core 2 Duo 8400, con placa intel DG31PR(B) con trisquel gnu/linux. Debo preocuparme de la privacidad también en este procesador? Porque igual tengo otro com un motherboard gigabyte con procesador phenom ii x4 del 2008 con una placa Gigabyte GA-M68MT-S2P, al que me puedo cambiar para mejorar mi privacidad. Aunque he leído que los mainboard Gigabyte también tienen algün problema de privacidad, pero no sé si este que ya es un poco antiguo. Qué me recomiendan los que saben a fondo del asunto. Por favor nada de principiantes y que toman el tema a la ligera.

✖

mceds 10 febrero 2019 16:14

⋮

Pásale el test SM Checker ( github.com/speed47/spectre-meltdown-checker ) en uno y en otro, a ver qué te cuenta.

Pero vamos, yo creo que con mantener el sistema operativo actualizado, no descargarse ni ejecutar nada que se salga de los repos oficiales y también tener los navegadores al día, debería bastar.

Las sandboxes de los navegadores deberían mantener el resto del sistema a salvo; no obstante, si quieres mayor seguridad y ya en modo casi paraonico, echa un vistazo a AppArmor, SELinux o incluso Qubes. Pero un vistazo lento y con tiempo. Configurarlos puede ser una pesadilla.

✖

BocaDePez 10 febrero 2019 17:13

⋮

Muchas gracias por tus recomendaciones y por contestar tan rápido. Voy a hacer los test a ver que me encuentro. De lo que he leído los procesadores AMD un poco antiguos tienen mejores posibilidades de no tener problemas de seguridad. También he leído que ciertos Bios dan problemas. Por mi experiencia con una laptop core i5 hp de tercera generación, son practicamente sistemas restrictivos, no te dejan instalar sistemas operativos libres a menos que modifiques el Bios, y una vez que lo haces e instalas un sistema libre no te va bien, notas algunas cosas raras, como que no reconoce dispositivos externos conectados a usb, la.navegación tiene fallas que molestan mucho, se nota el sabotaje. Le instalé trisquel en la core2 duo 8400 y va perfecto, me detecta los dispositivos, se navega perfectamente, pero ahora me toca confirmar que tab afectado está este procesador y compararlo con el Phenom. Gracias por su tiempo

✖

mceds 10 febrero 2019 17:33

⋮

No he leído nada referente a que los AMD antiguos sean menos vulnerables que los nuevos, aunque reconozco que este tema lo abandoné hace tiempo. Por ejemplo, acabo de hacer el test con un Ryzen+Vega con kernel 4.19 y me sale "limpio".

Comprar una laptop siempre hay que hacerlo contrastando compatibilidad.

BocaDePez 10 febrero 2019 16:33

⋮

Quieres respuestas serias pero dices que las placas Gigabyte tienen "problemas de privacidad". No sé Rick...

BocaDePez 15 febrero 2019 04:17

⋮

Checking for vulnerabilities on current system

Kernel is Linux 4.19.20-1-MANJARO #1 SMP PREEMPT Wed Feb 6 21:33:34 UTC 2019 x86_64
CPU is Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'

> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'

> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
> STATUS: NOT VULNERABLE (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'

> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'

> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'

> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'

> STATUS: NOT VULNERABLE (this system is not running a hypervisor)

Total que nada de nada.

En cuanto a rendimiento, sin problemas.