AMD busca excluirse del parche de Kernel Intel VT, sus CPUs son seguras y el parche merma su rendimiento

La inspección minuciosa de los parches del kernel revela un código que obliga a las máquinas que ejecutan cualquier procesador x86, sea Intel o AMD, a parchearse, independientemente del hecho de que los procesadores AMD sean inmunes. AMD busca que al menos el kernel de Linux incluya una línea de código como “(c-> x86_vendor! = X86_VENDOR_AMD)“, mientras que si el procesador usado no es AMD se marque como “X86_BUG_CPU_INSECURE“

[#2 Ze7eN]

Movimiento lógico por parte de AMD.

[#3 --430178--]

Normal, e Intel querra que se aplique a todas las CPUs, para no dejarles por debajo de la versiones de AMD a mitad de precio

[#4 --516568--]

#2 Hombre, es que la cagada de Intel es tan grande, que si realmente ellos no están afectados es de justicia que se reconozca.

[#5 Ze7eN]

#4 Totalmente de acuerdo, y mira que yo llevo usando Intel casi toda mi vida.

[#6 --516568--]

#5 Yo también. Ahora mismo desde un i5. Y dejé AMD hace mucho por los calentones. Pero es que esto va a resultar una estafa de campeonato.
Van decelerar la enorme mayoría de sistemas del planeta, por una cagada que para colmo parece que conocían.
Ya me había planteado volver a AMD por los Ryzen, pero después de esto es que no me planteo otra opción.

[#8 elece]

#7 ye están en ello:
www.amd.com/es/products/epyc

[#9 Frankss]

#6 Conocían? De dónde sacas eso? A que lleven 1 mes trabajando en un parche no lo llamaría "conocer"

[#10 Frankss]

#3 Pero Intel no decide nada.

[#11 --430178--]

#10 Ya, no digo que decida, al igual que AMD no decide mucho, pero cada uno intentara presionar donde pueda.

[#12 Frankss]

#11 Presionar? Intel ha enviado su parche y AMD ha visto que afecta a sus CPUs y pide cambiarlo (tendrá que enviar un parche para parchear el parche )

[#14 --430178--]

#12 Pero lo mismo te digo, aunque Intel enviara el parche, no es Intel quien decide implementarlo o no, puede presionar para que salga adelante mas rapido y de paso jodiendo a AMD, pero mucho mas no. Y obviamente AMD no lo va a ver justo porque les afecta dicho parche. Es como si yo saco un parche de mi driver de la tarjeta grafica, pero de paso te baja el rendimiento de tu CPU, la tarjeta grafica va bien y me da igual tu CPU.

[#15 Frankss]

#13 Qué? Intel no sabía nada, sabes el daño económico que tendrá este bug? Crees que Intel lo ha hecho a sabiendas?
Las cosas tienen bugs, y algunas son sencillas de arreglar y se pueden parchear sin que se noten, y otras cuestan millones. Pero bueno, que no sea yo quien te quite la teoría de la conspiración

[#17 --562282--]

Acaban de ponerlos a mitad de precio en Amazon
www.amazon.es/gp/aw/s/ref=nb_sb_noss?k=intel

[#18 mcfgdbbn3]

Sponsors of CPUgate. PAMMMMmmmmm… papam PAPAM.

[#19 dreierfahrer]

#9 se comenta en reddit q se sabe desde antes de la blackhat de 2016... q intel lo sabe desde entonces al menos....

Y han sacado despues la octava generacion sin ningun complejo....

Q es la q mas ostia se pega en los benchmarks, por cierto...

[#21 --375108--]

#17 ¿Tendrá relación con este tema, o será mas bien que amazon se quiere quitar de encima los micros 1151 "antiguos"?

[#23 --562282--]

#21 ni idea, sólo nuestro un hecho.

[#24 Frankss]

#16 Si el fallo es cuando se virtualiza. Es decir, no sé sabe aún cuál es el fallo, pero ya lo sabéis todo vosotros.

#19 Me dices que hay un bug así de grave desde 2016? Alguna fuente?

#20 Yo digo que no tiene sentido, quien asegura que lo saben no era yo.

[#26 jackal]

#20 Pues creo que lo sabían sobradamente porque el CEO de Intel vendió el máximo que podía de acciones (pasó de 495.743 a 250.000) hace un mes:
es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-

Llámalo casualidad si quieres

[#27 kahun]

Ya han metido X86_BUG_CPU_INSECURE directamente en el parche del kernel: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/x

[#28 dreierfahrer]

#24 Lo de 2016 se dice en reddit....

Y me extrañaria 0. Porque justo AMD saco Ryzen, q son bastante buenos.

No era el momento de no sacar algo mas rapido...

Intel ha estafado a millones de personas.... y lo peor es q en europa se va a ir de rositas.

[#29 Dovlado]

Las demandas que le van a caer a Intel van a ser legen...darias!

Y veremos si el CEO que vendió sus acciones no acaba entre rejas:

es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-

[#32 Frankss]

#28 Ryzen son así porque es arquitectura nueva, Intel lleva usando la misma arquitectura años.
Y no puede cambiarla del día a la mañana, que no sacaran cosas nuevas no tiene nada que ver con el bug.

[#34 --563745--]

¿Los procesadores de 64 bits están afectados?

[#35 --499944--]

Primero los motores de explosión, ahora los procesadores de silicio. ¿Qué será lo siguiente?

[#36 Frankss]

#30 Lo saco de la noticia que estamos comentando.
" The hardware-level vulnerability allows unauthorized memory access between two virtual machines (VMs) running on a physical machine"
Pero tu en cambio me pones un resumen de una persona random en un subreddit que no es ni profesional, si no aficionados a juegos de ordenador.
Y si, ya sé que hace 1 mes lo sabían. Pero el parche hay que hacerlo sabes?

En fin, que la teoría de la conspiración te la dejo a ti

[#37 frutosm]

#34 Sí todos los de Intel desde hace 10 años.

[#38 --563745--]

#37

[#39 protogenes]

#34 En principio, que yo sepa, sí, los de 2007 hasta ahora.

[#41 xiobit]

La parte buena para Intel es ya puede mejorar sustancialmente su próximo procesador, así campaña de marketing diciendo que su nuevo procesador mejora en un 50% el rendimiento.

[#42 Ainur]

#9 La venta de acciones fue desde noviembre, si bien es cierto que el problema pudo pasar desapercibido hasta mediados del año pasado

[#43 borteixo]

#15 a ver, que está en portada un poquito más abajo.
es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-
Igual no es tanta conspiración..

[#44 Frankss]

#40 Pero entonces, esta noticia es errónea no?
Según tu enlace, el problema sería este:
"Intel's CPUs speculatively execute code potentially without performing security checks"

Lo cuál me parece raro y probablemente tenga mucha más tema detrás, y no veo tan claro que Intel se salte estos checks de gratis sólo para ganar rendimiento, cuando le puede costar un montón de dinero (Intel y su coma flotante sabe que cuesta un dinero arreglar fallos hardware gordos).
Pero aún así, falta confirmación.
Y vamos, que me dan igual Intel y AMD, pero es sorprendente lo rápido que juzga la gente cuando aún no está ni confirmado.

[#45 Frankss]

#43 Último comentario que hago, porque estoy todo el rato explicando lo mismo.
Hay que encontrar el bug.
Hay que hacer el parche.
No se tarda 2 días en arreglar un bug hardware con software.

[#46 JCarlosCandela]

Una pregunta, compré hace menos de 1 año un procesador Intel, ¿entraría en la garantía devolverlo debido a que no se corresponde con lo que yo he comprado, al reducir el rendimiento de mi PC hasta un 30%?

[#47 joffer]

#15 #9 Me está recordando a lo de Volkswagen y sus famosos test

[#49 dreierfahrer]

#32 hombre: si saben del bug y no lo arreglan....

Es bastante PUTA ESTAFA...

[#50 Frankss]

#48 No está confirmado cuál es el bug.

#47 Pero hay una diferencia abismal.
En los coches hay unos benchmarks a pasar. Si no pasa el benchmark no vendes el coche
En procesadores hay unos benchmarks a enseñar. Lo haces para mostrar rendimiento, no para poder vender el proc.

#49 Están en ello...

[#51 joffer]

#50 Si te inventas el resultado o haces ingeniería para trampearlos como poco es competencias desleal y seguro se le tiran en lo alto como estafa.

[#52 Frankss]

#51 Pero la cosa es que lo hiciesen a sabiendas (y no, no me vale que el CEO vendiera acciones hace 1 mes, cuando probablemente el bug se estaba mirando de arreglar). Y estoy bastante seguro que alguien denunciará y se investigará.
Vamos yo lo veo así,
en el caso de Volkswagen había mucho que ganar (poder vender el coche)
En este caso, Intel tiene poco que ganar (un poco más de rendimiento) y mucho que perder (la posible denuncia millonaria y perdida de clientes)

[#54 joffer]

#52 El principal ingeniero de Intel abandona la compañía. 25 de Julio.

www.profesionalreview.com/2017/07/25/principal-ingeniero-intel-abandon

[#56 --202084--]

Menudo culebrón

[#57 Frankss]

#55 Yo hablaba de cuál es LA CAUSA del bug. Pensé que se sobreentendía.
Y la causa no se sabe aún, puesto que hay un embargo y no se sabe la causa ni cómo explotarla.
Pero supongo que si está el patch significa que se sabe todo jejeje.

[#58 nospotfer]

#27 En el diff se ve que añaden estas dos funciones:

static void __init pti_print_if_insecure(const char *reason)
{
 if (boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
  pr_info("%sn", reason);
}

static void __init pti_print_if_secure(const char *reason)
{
 if (!boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
  pr_info("%sn", reason);
}

Lo cual supone un método para diferenciar CPUs "seguras" de las "inseguras".
Leyendo un poco más el diff, vemos que se añaden funciones sólo para el caso en el que corran dos o más VMs, es decir, que es posible que para el caso en el que NO se corran VMs no se ralentice.
Además, incluye otra función para ignorar el insecure, permitiendo que en el equipo no se vea mermada su eficiencia, concretamente, aquí:

void __init pti_check_boottime_disable(void)
{
 char arg[5];
 int ret;

 if (hypervisor_is_type(X86_HYPER_XEN_PV)) {
  pti_print_if_insecure("disabled on XEN PV.");
  return;
 }

 ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
 if (ret > 0) {
  if (ret == 3 && !strncmp(arg, "off", 3)) {
   pti_print_if_insecure("disabled on command line.");
  return;
  }
  if (ret == 2 && !strncmp(arg, "on", 2)) {
   pti_print_if_secure("force enabled on command line.");
   goto enable;
  }
  if (ret == 4 && !strncmp(arg, "auto", 4))
   goto autosel;
 }

 if (cmdline_find_option_bool(boot_command_line, "nopti")) {
  pti_print_if_insecure("disabled on command line.");
  return;
 }

autosel:
 if (!boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
  return;
enable:
 setup_force_cpu_cap(X86_FEATURE_PTI);
}


Resumiendo, que sí, que es un bug crítico, que será corregido por defecto en las máquinas afectadas, pero sólo en los casos en los que realmente se pueda ver afectado, que NO es el caso de la mayoría de usuarios. Por lo menos en el Kernel de Linux.

[#59 KirO]

#53 el parche lo ha hecho la propia Intel por lo visto.

[#61 Frankss]

#60 Bug de Intel y me vienes con la randomización de direcciones. En fin, ya he visto el nivel. Aquí te dejo.

[#62 Kenzoryyy]

#46 aun es muy pronto, es un fallo/estafa super grave, ya veremos que pasa

[#64 frutosm]

#15 Se conoce el fallo desde otoño de 2016 y han sacado nuevos procesadores con el fallo
www.youtube.com/watch?v=TJTQbs3oJx8

[#65 Jakeukalane]

#58 es una muy buena noticia que no se aplique en todo momento. Yo tengo dos ordenadores con CPUs que no son una maravilla y prefiero estar expuesto antes que tener una merma de un 35%

[#66 Jakeukalane]

#46 en un mundo ideal lo que sería bueno que hicierais sería contactar los que haya pasado lo mismo para hacer más presión.

[#67 timeout]

#17 por lo que parece responde más a un hay que acabar con la 7ª generación para vender la 8ª

[#68 --410220--]

#17 Yo los veo al precio de siempre.

[#69 --519439--]

#4 No es solo por una cuestión de reconocimiento frente a Intel. Es en defensa de sus clientes (en concreto, los que han comprado CPUs de AMD y usan Linux, porque Microsoft parece que no va a hacer distinciones, es así de majo):
Si se les aplica el parche a todos indiscriminadamente, querrá decir que quien se ha comprado un Rizen va a tener en rendimiento algo más parecido a un opteron de hace 10 años. No hace ninguna gracia, como entenderéis.

[#70 --78935--]

#13 que las medidas implementadas via software para evitar el bug impliquen una pérdida de rendimiento no implica necesariamente que intel consiga un rendimiento X a costa de ese fallo de construcción...

[#71 Arkhan]

#69 Pues yo estoy siguiendo el tema por otros derroteros, mi portátil AMD a día de hoy es relativamente justito, como el parche empiece a afectar negativamente al rendimiento de la máquina ese ordenador lo puedo mandar a la basura ya mismo.

Deben aplicar el parche únicamente a las máquinas con Intel, y hacer la ingeniería que quieran hacer para que el rendimiento no se vea afectado. Si no pueden, pues nada, que Intel se haga cargo de la cagada y vaya pagando indemnizaciones.

[#72 mrpaco]

#46 devuelves el procesador y te comes la placa?

Los mas viejos del lugar, entre los que me encuentro, recordaran el escandalo FDIV que afecto a los Pentium 60 y 66, hace algo mas de 20 años, inicialmente Intel hizo comunicados minimizando el impacto del problema (quien quiera detalles es.wikipedia.org/wiki/Error_de_división_del_Intel_Pentium para no alargarnos mas).

Tras salir publicadas demostraciones de las desviaciones en calculos en casos practicos Intel no tuvo mas remedio que recular y ofrecer el cambio GRATUITO de todos los procesadores afectados, llamabas a un numero de telefono gratuito y te enviaban un kit de reemplazo con un procesador nuevo sin el error y las herramientas necesarias para reemplazar tu mismo el procesador, una vez hecha la operacion te recogian el procesador viejo.

Tengo en mis manos una de esas reliquias, un Pentium 60 con fecha de 1992 afectado por FDIV que en su dia su propietario no cambio, hay mucha gente que no cambio sus procesadores por falta de informacion.

[#73 --21146--]

#15 pues al parecer en reddit comentan que varios directivos de Intel vendieron acciones como locos en noviembre, por después de ser avisados de este bug.

¿Casualidades? No lo se.

Pero trankis, que los fan boys de Intel se dejarán la pasta en un procesador de 600 pavos que es solo un 8% más rápido que el procesador de 250 pavos y además pueden hacerle delic para sacarle la pasta de dientes.

[#74 --21146--]

#54 y el mejor de amd ficha por Intel.

Inside Job?

[#75 JCarlosCandela]

#72 la placa no me la como porque tengo intención de comprar un intel de los nuevos cuando los rebajen estrepitosamente de precio.

[#79 mrpaco]

#75 sera la placa compatible con el nuevo procesador?

[#80 javicho]

#1 en resumen no deberíamos tener que parchear en casa porque aunque tengamos varias máquinas virtuales levantadas en un pc, no parece importante que una acceda a la otra.
Lo que es una cagada y gorda es para todos los servidores de la nube donde te venden una maquina virtual que reside en el mismo hw que vaya usted a saber quien

[#81 Attanar]

Si entiendo bien la noticia, esto sólo afecta al rendimiento de procesos virtualizados, ya que no pueden acceder tan rápidamente a los recursos reales del ordenador.

De ser así, es un problema que no tiene impacto real para los usuarios, sino para empresas que virtualizan software: Amazon, Microsoft, etc. principalmente, y a nivel más pequeño cualquier CPD de una empresa que use servicios de virtualización como VMWare.

[#82 deabru]

#69 yo lo tendría claro si tuviese un ryzen y los del kernel no hiciesen distinciones: compilaba mi kernel y aplicaba el parche de AMD.

Software Libre y eso.

[#83 deabru]

#81 memoria virtual != máquinas virtuales.

[#84 Attanar]

#83 No veo que en el artículo se hable de memoria virtual por ninguna parte. Se habla de memoria compartida entre máquinas virtuales, que no tiene nada que ver con la memoria virtual o paginada.


La vulnerabilidad, a nivel de hardware, permite el acceso no autorizado a la memoria entre dos máquinas virtuales (VM) que se ejecutan en una máquina física, debido a la implementación defectuosa de Intel de sus conjuntos de instrucciones de virtualización de nivel de hardware.

[#85 Unnhell]

Pues yo me pongo el gorro de papel de aluminio y digo que este fallo es una propiedad oculta más de los Intel, del mismo tipo de las que podría proporcionar el Management Engine integrado en sus chips. Ese tipo de características que solo unos pocos conocen hasta que todos se enteran.

[#86 --78935--]

#76 Y para bajar el consumo de energía, y para solucionar bugs, y para poner excusas para venderte otra cosa. Lo normal vamos. Lo de dejar un bug a sabiendas e intencionadamente para mejorar el rendimiento suena a película. Me parece que es más probable que sea una un error no intencionado. O un bujero de la NSA, pero eso ya es otro tema..

[#87 --272073--]

#4 Es que AMD y ARM también son vulnerables
googleprojectzero.blogspot.in/2018/01/reading-privileged-memory-with-s

[#88 zeioth]

En Linux está garantizado que no va a afectar a AMD. En Windows y Mac en cambio, habrá que verlo, ya que son partners de Intel y probablemente prefieran hacerle la zancadilla a AMD antes que estropear sus relaciones comerciales.

[#90 --352927--]

#4 Me parece que si están afectados según Google: security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them."

[#91 --78935--]

#89 No me lo estás explicando de otra manera, me estás explicando otra cosa. No lo arreglan porque la manera de arreglarlo es rediseñar y cambiar la CPU. Por cierto, resulta que algunas variantes del bug afectan también a ARM y AMD que según tú no hace esas cosas. Todos la cagan y no siempre se puede arreglar con una actualización.

[#93 --78935--]

#92 ¿Pero qué acusación de intel? ¿te has mirado el paper original de Project Zero que son los que lo han sacado? googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-wi
Son tres vulnerabilidades y al menos una afecta a AMD y ARM también. Y AMD puede decir misa si hay una prueba de concepto funcionando en sus CPU's. Otra cosa es que el parche para intel no sea necesario porque está hecho para otra de las variantes.

[#95 --78935--]

#94 ¿Y como encaja esto en tu historia de que intel lo hace a propósito? ¿crees que si AMD no hubiese tenido esa suerte te regalaria una CPU nueva sin más?

[#97 --78935--]

#96 Ok.. No si yo no voy a defender intel de sus cagadas. Ha tenido su posición de monopolio muchos años y como tal pues ha hecho lo que le ha salido de las narices. AMD le habría pasado igual. Y mañana mismo puede salir otro fallo o descubrir que los AMD son más vulnerables de lo que parece y ya ese castillo de naipes que te has montado se cae.
El cambio de arquitectura del que hablas se hizo hace 15 años, está perfectamente especificado. Que el CEO venda acciones hace dos meses da a entender de que se han pispado del error hace 2 meses, no hace 15 años

[#99 --78935--]

#98 Lo de volkswagen fue intencionado, no aplica aquí.