EDICIóN GENERAL
469 meneos
3220 clics
AMD busca excluirse del parche de Kernel Intel VT, sus CPUs son seguras y el parche merma su rendimiento

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“

| etiquetas: amd , parche , kerne , intel vt , rendimiento
Comentarios destacados:                          
#4 #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.
#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
Movimiento lógico por parte de AMD.
#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.
#4 Totalmente de acuerdo, y mira que yo llevo usando Intel casi toda mi vida.
#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.
#6 Conocían? De dónde sacas eso? A que lleven 1 mes trabajando en un parche no lo llamaría "conocer"
#9 Lo dice porque a sabiendas del dato ya sabemos de donde saca Intel el rendimiento, de saltarse normas básicas de arquitectura de procesadores, cosa que AMD no hace.
#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
#15 A ver como te lo explico, para diseñar un procesador que permite usar y acceder a direcciones de memoria hardware por la cara lo tienes que hacer adrede, no es un fallo, es intencionado y a sabiendas de las problemáticas que tiene tanto de seguridad como de estabilidad del sistema {0x1f609}

PD: que pronto se nos olvidan otros "fallos" como el dieselgate de Volkswagen
#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.
#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.
#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.
#32 hombre: si saben del bug y no lo arreglan....

Es bastante PUTA ESTAFA...
#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...
#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.
#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)
#52 El principal ingeniero de Intel abandona la compañía. 25 de Julio.

www.profesionalreview.com/2017/07/25/principal-ingeniero-intel-abandon
#54 y el mejor de amd ficha por Intel.

Inside Job?
#50 Explícame como es que no está confirmado cual es el bug si en Linux ya existe el parche para ese bug, como es posible hacer un parche para un bug desconocido? Joder la de chorradas que tengo que leer
#53 el parche lo ha hecho la propia Intel por lo visto.
#59 Aquí tienes a uno que ha conseguido leer de la memoria reservada al kernel

www.meneame.net/m/Retuit/bingo-ikpti-intel-kernel-page-table-isolation
#24 no sé de donde coño sacas que el fallo es sólo cuando se virtualiza? es en cualquier caso, incluso ejecutando un miserable javascript de una página web, sólo que en sistemas virtualizados hay aún más peligro dado como funciona un sistema que virtualiza (aislamiento de memoria entre máquinas virtuales, con este bug una máquina virtualizada podría acceder a datos de su host físico o incluso a datos ejecutandose en otras máquinas virtuales en el mismo host)


If successfully exploited,

…   » ver todo el comentario
#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 ;)
#36 Revisa conceptos, memoria virtual no significa que tengan que ser máquinas virtuales, la noticia está mal explicada, puedes mirartelo donde quieras pero estará en inglés (la noticia original la tienes abajo con el bug explicado y que lleva una década en los procesadores)

En informática, la memoria virtual es una técnica de gestión de la memoria que permite que el sistema operativo disponga, tanto para el software de usuario como para sí mismo, de mayor cantidad de memoria que esté

…   » ver todo el comentario
#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.
#44 pero como que no está confirmado si van a parchear todo AWS en 2 días y todo Azure el día 10? {0x1f602} {0x1f602} {0x1f602}

Como no te refieras a que no está confirmado si lo sabían... Y ni eso, vuelvo a repetir que para hacer que un procesador pueda acceder a memoria mediante direcciones hardware, o sin esos chequeos de seguridad, hay que hacerlo a conciencia sabiendo a los problemas de seguridad a los que te expones
#25 If successfully exploited, it could allow any program running on your computer (including a webpage with JavaScript) to access memory used by the operating system, giving it total control over your computer.

www.reddit.com/r/pcmasterrace/comments/7nthay/a_quick_summary_of_the_c
#15 jajjaja y tu que cojones sabes si intel conocía o no. Putos flipaos que no tenéis ni idea y aseguráis como si fuerais parte del consejo de intel
#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
#20 pues como mínimo lo sabe hace 6 meses justo antes de sacar la ultima ornada de procesadores y no avisaron. Yo a eso lo llamo estafar al personal
#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..
#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.
#45 que el parche para las Linux ya está hecho y probado que no te enteras
#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.
#57 La causa la sabemos todos los que sabemos como funciona la arquitectura de un procesador, a un "listo" se lo ocurrió saltarse la regla básica de dejar al procesador acceder directamente por hardware a direcciones de memoria sin ninguna comprobación de seguridad o con una seguridad ineficiente

Que dicen que no saben ni como explotarla? JAJAJAJA

Te dejo un video del ejemplo de ataque

www.youtube.com/watch?v=ewe3-mUku94

Aquí explicado también…   » ver todo el comentario
#60 Bug de Intel y me vienes con la randomización de direcciones. En fin, ya he visto el nivel. Aquí te dejo.
#61 Pero tú sabes como funciona un procesador? leete bien el comentario que te he añadido el párrafo que interesa, precisamente los de pythonsweetness son los que han ayudado a descubrirlo, de hecho fueron los primeros en hacerlo

Los tienes aquí mencionados

The Python Sweetness blog, which first reported on the bug, said the vulnerability was first identified by developers working on the Linux kernel, though it also affects Windows operating systems. It added that a number of

…   » ver todo el comentario
#61 Hala, ahí lo tienes, tan simple como ejetutar tres lineas de comandos de sistema operativo ;)

twitter.com/brainsmoke/status/948561799875502080

Eso combinado con esto (sí el ataque redandomización de direcciones que te he puesto antes) y consigues la información que quieres

That along with your talk on ASLR bypass w/ JS in #34c3 is scary AF.

twitter.com/pmoust/status/948567759708966917

Luego venme a decir que aún no saben explotarlo ;)

Te vuelvo a poner el mismo video, la próxima vez antes de hacer el cuñao informate bien que no tienes nidea

34C3 - ASLR on the line

www.youtube.com/watch?v=ewe3-mUku94
#15 #9 Me está recordando a lo de Volkswagen y sus famosos test
#15 Se conoce el fallo desde otoño de 2016 y han sacado nuevos procesadores con el fallo :roll:
www.youtube.com/watch?v=TJTQbs3oJx8
#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.
#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...
#70 Para qué se hacen los cambios en una arquitectura de un procesador? ah, ya, que para conseguir más rendimiento que con la anterior arquitectura, pues eso ;)
#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..
#86 Te lo voy a explicar de otra manera, cambias la arquitectura y consigues más rendimieno pero te deja un agujero de seguridad y NO lo arreglas porque te sale más caro arreglarlo y perderias esa ganancia de rendimiento es así de facil
#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.
#91 Comunicado de AMD al respecto

www.meneame.net/m/tecnología/comunicado-amd-respecto-seguridad-proces

En español aquí

AMD niega la acusación de Intel de que sus procesadores son vulnerables por un fallo de seguridad

es.gizmodo.com/amd-niega-la-acusacion-de-intel-de-que-sus-procesadores

Como dice otro usuario en la noticia

"el resumen es que no. De momento de las tres variantes del ataque AMD ha negado que sus procesadores sean

…   » ver todo el comentario
#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.
#93 sí, sí la he mirado, también he mirado los ataques, tanto el meltdown como el spectre y luego he visto el comunicado de AMD al respecto precisamente de esas declaraciones en las que explica claramente que la probabilidad de realizar el ataque es cero y la otra es parcheable sin perdida de rendimiento ;)
#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?
#95 Sigue encajando a la perfección, compañía A hace un cambio de arquitectura para hacer más rápido el acceso a memoria sobrepasando a compañía B, cambio que hace que sea vulnerable a un tipo de ataque (Meltdown), compañías A y B además son vulnerables por diseño de arquitectura compartida a otro tipo de ataque cuya probabilidad es cero en una variante (Spectre) y parcheable sin pérdida de rendimiento en la otra (también Spectre)

Conclusión, compañía A y debido a los acontecimientos pasados…   » ver todo el comentario
#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
#97 Que rápido se nos olvidan otros casos chpuceriles estilo volkswagen, había gente que ni lo sabía en la compañía, no estoy diciendo que todos lo sepan pero sí gran parte, al menos el equipo que cambió la arquitectura y o que la probó (las cosas se prueban no sé si lo sabes) y me da que se pasó deliberadamente por encima porque es que ese fallo canta mucho, de hecho para hacer el cambio en la arquitectura que te permita leer direcciones hardware de memoria se implementó aparte un sistema de…   » ver todo el comentario
#98 Lo de volkswagen fue intencionado, no aplica aquí.
#99 Es que lo que estoy diciendo es que fue intencionado, es decir, a partir de descubrir el fallo no querer arreglarlo, la única diferencia
#100 Y yo te digo que lo de volskwagen no fue un fallo y no se por qué lo sacas a relucir. Y que seguramente el fallo lo han descubierto hace poco tiempo, meses a lo mucho. Pero lleva más de una década existiendo. Y no se puede arreglar por que es un fallo de hardware.
¿se lo pueden haber callado ese tiempo? sí, y seguramente lo han hecho. E incluso puede que sea la mejor opción. ¿Es una cagada de intel sobretodo? sí. ¿Afecta a AMD? también. ¿AMD es mejor que intel en sus procesos de testing? quien sabe, de momento les ha ido mejor pero eso no quiere decir nada. ¿Ha sido intencionado el fallo? no.
Y que me voy a comer algo ale.
#97 Vaya pues parece que Intel como mínimo lo sabía hace 6 meses y no avisaron ;)

www.meneame.net/story/intel-lanzo-generacion-coffee-lake-sabiendo-proc
#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...
#9 La venta de acciones fue desde noviembre, si bien es cierto que el problema pudo pasar desapercibido hasta mediados del año pasado
#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.
#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.
#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.
#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."
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
#3 Pero Intel no decide nada.
#10 Ya, no digo que decida, al igual que AMD no decide mucho, pero cada uno intentara presionar donde pueda.
#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 :-D)
#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.
Acaban de ponerlos a mitad de precio en Amazon
www.amazon.es/gp/aw/s/ref=nb_sb_noss?k=intel
#17 ¿Tendrá relación con este tema, o será mas bien que amazon se quiere quitar de encima los micros 1151 "antiguos"?
#21 ni idea, sólo nuestro un hecho.
#17 Na solo han bajado un poco, el 7700 valía 299 la semana pasada y ahora 296
#17 por lo que parece responde más a un hay que acabar con la 7ª generación para vender la 8ª
#17 Yo los veo al precio de siempre.
Sponsors of CPUgate. PAMMMMmmmmm… papam PAPAM.
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
#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…   » ver todo el comentario
#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%
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-
#34 Sí todos los de Intel desde hace 10 años.
#34 En principio, que yo sepa, sí, los de 2007 hasta ahora.
Primero los motores de explosión, ahora los procesadores de silicio. ¿Qué será lo siguiente? :troll:
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. {0x1f602} {0x1f602}
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%?
#46 aun es muy pronto, es un fallo/estafa super grave, ya veremos que pasa :-S
#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.
#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…   » ver todo el comentario
#72 la placa no me la como porque tengo intención de comprar un intel de los nuevos cuando los rebajen estrepitosamente de precio.
#75 sera la placa compatible con el nuevo procesador?
Menudo culebrón o_o
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.
#81 memoria virtual != máquinas virtuales.
#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.
#84 Lo que te quería contestar es que el tema de las virtuales, de acceder a la memoria de otra máquina virtual, no es más que una consecuencia del bug. Hay otras, pero todo viene derivado de que un proceso pueda acceder a la memoria de otro proceso (o del sistema, en este caso)

Que no era exclusivo de máquinas virtuales, pero hay gente que ha visto hablar del tema mencionando la memoria virtual y se ha confundido:

en.wikipedia.org/wiki/Virtual_memory

The primary benefits of virtual memory include freeing applications from having to manage a shared memory space, increased security due to memory isolation, and being able to conceptually use more memory than might be physically available, using the technique of paging.
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.
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.
«12
comentarios cerrados

menéame