Portada
mis comunidades
otras secciones
#25:
#11 En realidad, estas vulnerabilidades son propias de la arquitectura. La mayoría no se pueden replicar en AMD porque su implementación de SMT es distinta y es más segura por diseño. Todas y cada una de las vulnerabilidades que han salido son porque para no penalizar el rendimiento (asumiendo la mejor de las intenciones), Intel se ha ahorrado hacer chequeos o poenr limitaciones a muchas operaciones, dejando registros legibles por procesos que no deberían tener acceso. Algunos de estos caminos no se van a poder encontrar nunca en los procesadores de AMD porque simplemente su sistema de multihilo funciona distinto, aunque de cara a la abstracción de un sistema operativo parezca idéntico al usuario.
La cosa es que Ryzen/TR/Epyc son procesadores con una arquitectura moderna, y en Intel están en la enésima iteración de Core. Algunas de estas vulnerabildades van hasta los tiempos de Netburst (Pentium 4), y la mayoría las tienes desde los primeros Core (que por cierto, Intel ya ha dicho que no va a parchear nada de antes de 2011, así que todos esos Core 2 Duo con Windows XP se van a quedar como están). Curiosamente, los últimos modelos tienen vulnerabilidades extra.
El problema es que no puedes coger y cambiar el sistema de Hyper Threading de un Xeon sin cambiar básicamente la CPU entera, pero vamos, es lo que les va a tocar, porque nadie va a comprar un lote de mil procesadores de $3000 sabiendo que son un coladero de seguridad y no se van a arreglar, o si se "arreglan", será a costa de reducir su rendimiento por debajo de lo que dan procesadores que valen la mitad o menos.
La cosa es que Ryzen/TR/Epyc son procesadores con una arquitectura moderna, y en Intel están en la enésima iteración de Core. Algunas de estas vulnerabildades van hasta los tiempos de Netburst (Pentium 4), y la mayoría las tienes desde los primeros Core (que por cierto, Intel ya ha dicho que no va a parchear nada de antes de 2011, así que todos esos Core 2 Duo con Windows XP se van a quedar como están). Curiosamente, los últimos modelos tienen vulnerabilidades extra.
El problema es que no puedes coger y cambiar el sistema de Hyper Threading de un Xeon sin cambiar básicamente la CPU entera, pero vamos, es lo que les va a tocar, porque nadie va a comprar un lote de mil procesadores de $3000 sabiendo que son un coladero de seguridad y no se van a arreglar, o si se "arreglan", será a costa de reducir su rendimiento por debajo de lo que dan procesadores que valen la mitad o menos.
#9:
#5 #4 Ahora mismo EPYC es una plataforma bastante mas robusta que Intel, que se ha dormido en los laureles. Además los que "vivimos de esto", sabemos que hay más mierda por salir. Peeeeero, como hay acuerdos de confidencialidad no se pueden sacar.
Como sera la bola de nieve que la recomendación de Intel es desactivar HT. Perder un 20-40% de rendimiento en un entorno profesional debería ser motivo suficiente para no volver a comprar en la vida esa marca.
Y ojo, AMD tiene también sus cosicas (que saldrán en breve), si bien, el impacto va a ser mucho menor en los rendimientos.
Como sera la bola de nieve que la recomendación de Intel es desactivar HT. Perder un 20-40% de rendimiento en un entorno profesional debería ser motivo suficiente para no volver a comprar en la vida esa marca.
Y ojo, AMD tiene también sus cosicas (que saldrán en breve), si bien, el impacto va a ser mucho menor en los rendimientos.
#7:
#4 tan probado está Intel, que descubren una nueva vulnerabilidad grave cada 6 meses.. 
El problema no es que Intel esté "probado", el problema es que prácticamente todo el software está compilado con optimizaciones para Intel, y por lo tanto penaliza en AMD. Además de que la gente tiene miedo al cambio innato. La realidad es que prácticamente el 100% del software que funciona en Intel funciona también en AMD, porque tienen el mismo juego de instrucciones.
El problema no es que Intel esté "probado", el problema es que prácticamente todo el software está compilado con optimizaciones para Intel, y por lo tanto penaliza en AMD. Además de que la gente tiene miedo al cambio innato. La realidad es que prácticamente el 100% del software que funciona en Intel funciona también en AMD, porque tienen el mismo juego de instrucciones.
Comentarios
#5 #4 Ahora mismo EPYC es una plataforma bastante mas robusta que Intel, que se ha dormido en los laureles. Además los que "vivimos de esto", sabemos que hay más mierda por salir. Peeeeero, como hay acuerdos de confidencialidad no se pueden sacar.
Como sera la bola de nieve que la recomendación de Intel es desactivar HT. Perder un 20-40% de rendimiento en un entorno profesional debería ser motivo suficiente para no volver a comprar en la vida esa marca.
Y ojo, AMD tiene también sus cosicas (que saldrán en breve), si bien, el impacto va a ser mucho menor en los rendimientos.
#9 ¡Dónde quedó el "Full Disclosure" y esas pequeñeces! ¡Yastás haciendo otro clon para publicar un artículo sobre el tema!
#13 Desgraciadamente no se puede. Los contratos son leoninos. Ni que decir que Intel te cierra las puertas.
#16 Cuando entren en tu despacho los jerifaltes, y vean las fotos de ardillas en la pared, empezarán a atar cabos.....
#28 Aparento normalidad en mi trabajo. No conocen mi oscuro secreto.
#28 Vamos bien si solo ven las fotos, y no las jaulas, los "botes de gel" (lubricante), el papel higiénico y las maquinillas de afeitar, ...
#4 tan probado está Intel, que descubren una nueva vulnerabilidad grave cada 6 meses..
El problema no es que Intel esté "probado", el problema es que prácticamente todo el software está compilado con optimizaciones para Intel, y por lo tanto penaliza en AMD. Además de que la gente tiene miedo al cambio innato. La realidad es que prácticamente el 100% del software que funciona en Intel funciona también en AMD, porque tienen el mismo juego de instrucciones.
#7 Ese "prácticamente el 100%" es el problema. ¿Si es el 99%, y ese 1% te toca a tí?
#18 digo prácticamente porque hay software específico para procesadores Intel, que detectan el ID del procesador y si no es Intel no funciona. No se trata de software generalista, sino software de la propia Intel o software muy optimizado para Intel, y en este último caso se ofrece la alternativa para AMD. En ambos casos este software podría funcionar en AMD, pero se limita por software su ejecución de forma adrede. Vamos, que no es una lotería como insinúas en tu comentario.
#7 #24 Creo que estás equivocado. Lo de que Intel en su compilador identifice una cpu Intel y use un código que utilice ciertas instrucciones que hacen que todo vaya más rápido mientras que cuando identifica una cpu como AMD, el software elige no usarlas, con la penalización de rendimiento que conlleva... creo que eso fue hace muchísimos años y ya no ocurre porque hubo una multaca de la ostia.
Aparte que entre EU y USA le metieron una multa a Intel por prácticas monopolísticas tales como vender por debajo del precio de coste, sobornar a fabricantes (dell por ejemplo) para que no montasen ordenadores con AMD y muchas otras cosas variadas como la del complilador que mencionas. De hecho Intel sigue debiendo más de 1.500 millones de dólares a AMD y si no me equivoco todavía no ha pagado ni un duro.
#31 no, no me equivoco. Eres tú quien confunde distintas cosas.
Los compiladores tienen flags de optimización para las distintas extensiones de las CPUs, y muchas de estas optimizaciones son excluyentes entre sí. Vamos, que no puedes optimizar para todas las CPUs, tienes que elegir, y como las CPUs Intel son mayoritarias, la gran mayoría de desarrolladores de software optimizan para Intel e ignoran AMD. Además puedes optimizar el código fuente adrede para aprovechar las extensiones de las CPUs, y esto queda en manos de los desarrolladores, de la misma forma que puedes programar para usar un solo hilo, o optimizar el software para sacar rendimiento de las CPUs multicore con concurrencia.
El mejor ejemplo de esto son los minadores de criptomonedas para CPUs. Los desarrolladores de los mismos no tienen ningún interés en penalizar a AMD ni a Intel, sino todo lo contrario, ya que en la mayoría de los casos se llevan un porcentaje del tiempo de computación para beneficio propio. Un minador optimizado para Intel funciona en AMD, pero con un rendimiento penoso, y viceversa.
Hace tiempo que tengo abandonado el tema de minadores, pero he refrescado la memoria con Google para la ocasión, y te dejo un ejemplo; cpuminer-opt, de código abierto, y depende de ti el compilarlo con las optimizaciones para tu CPU:
https://github.com/JayDDee/cpuminer-opt
#41 Creo que te estás liando tú solo. Lo que tú dices ya no ocurre porque Intel ya fue multada por eso. Aparte que es historia.
Beginning in 1999 with the Pentium III, Intel introduced SSE instructions to their processors. This set of about 70 new instructions provided faster calculations for single precision floats. The expansion to this, SSE2, introduced with the Pentium 4 in 2001 greatly expanded floating point calculations and AMD was obliged to include these instructions in their AMD64 CPUs beginning in 2003.
Although both Intel and AMD produced chips that could take full advantage of these new instructions, the official Intel compiler was optimised to only allow Intel CPUs to use these instructions. Because the compiler can make multiple versions of each piece of code optimized for a different processor, it’s a simple matter for an Intel compiler to choose not to use improved SSE, SSE2, and SSE3 instructions on non-Intel processors. Simply by checking if the vendor ID of a CPU is ‘GenuineIntel’, the optimized code can be used. If that vendor ID is not found, the slower code is used, even if the CPU supports the faster and more efficient instructions.
This is playing to the benchmarks, and while this trick of the Intel compiler has been known since 2005, it is a surprisingly pernicious way to gain market share.
We’ll be stuck with this for a while. That’s because all code generated by an Intel compiler exploiting this trick will have a performance hit on non-Intel CPUs, Every application developed with an Intel compiler will always perform worse on non-Intel hardware. It’s not a case of Intel writing a compiler for their chips; Intel is writing a compiler for instructions present in both Intel and AMD offerings, but ignoring the instructions found in AMD CPUs.
Si eso que tú afirmas siguiese ocurriendo, AMD no podría estar compitiendo con Intel de la manera que lo está haciendo. Confundes optimizar para una CPU con hacer que el código vaya peor en otro procesador de manera artificial, que es por lo que Intel ganó la batalla a AMD hace 15 años.
Aquí te dejo la historia por si te interesara. https://hackaday.com/2015/12/09/echo-of-the-bunnymen-how-amd-won-then-lost/
#42 Yo en ningún momento he hablado de hacer que el software vaya peor en otros procesadores, en todo momento he hablado de optimizaciones. Presta más atención a lo que lees.
De mi opinion personal...
El daño a su reputacion ha sido gravísimo, antes tu decias Intel o AMD y habia discrepancias sobre rendimiento puro (Intel) y la relación rendimiento/precio (AMD), a día de hoy cuando hablo con gente simplemente mencionas Intel y escuchas el ñiiiiiiii
Esto les va a a hacer muchisimo daño a la larga
#1 Ahora mismo EPYC da una soberana torta a Intel en muchos aspectos. El problema es el "cambio" y a mucha gente de sistemas le da el telele oír habar de AMD.
#2 Todavía recuerdo una vulnerabilidad en el kernel de linux durante mucho años, que solo afectaba a AMD, y que le hacía perder mucho rendimiento. Con esto intento decir que TODO está probado en Intel, y no tanto en AMD, por lo que es normal que se sea renuente al cambio.
#4 No se rick, parece falso...
#4 Yo no recuerdo ninguna vulnerabilidad, lo que si recuerdo es el bug del tlb (translocation buffer). Puedes buscar "tlb bug amd", hablamos de hace 10 años. Y esto lo se de primera mano porque mi ordenador ahora mismo sigue siendo un Phenom 2 1100t (2011) con 6 cores, afectado por este bug y que se sigue comiendo con patatas en multithread a la mitad de las cosas que saca Intel hoy día.
#52 ¡Eso!, el subconsciente me ha traicionado. Era un "bug".
#2 Yap pero a lo q me refiero es que ves un cambio en la cultura, antes era impensable para servidor propuestas con AMD (o al menos había que justificar decisión) y a día de hoy yo al menos veo que la corriente empieza a cambiar.
En la noticia:
"Intel pierde cuota de mercado a un ritmo preocupante"
No me preocupa mucho. Mucho más me preocupan mis computadores y mis datos.
#8 sino se me escapa algo: los computadores "tuyos, en tu casa, que no den un serivcio de Hosting o procesado compartido o escritorio compartido" no se ven afectados en cuanto a seguridad por estos "bugs"(si en cuanto a potencia por el parche que "lo solventa").
Si "tus ordenadores" son Espacios de una nube, por ejemplo azure, si podrian estar en peligro.(además de pagar lo mismo por menos potencia efectiva).
#30 Yo estoy en esas con intel
#30 #34 #35. Es el calor, amigo.
Desde mi punto de vista un alto consumo energético que requieran de sistema de disipación de calor exagerados han dejado de ser una opción para el día a día de la informática, PCs de última generación para experimentación y juegos 'Triple A' aparte.
La Raspberry Pi y muchos proyectos similares o derivados han marcado
un viejoun nuevo y muy interesante camino de bajo consumo, disipación pasiva y prestaciones muy aceptables.#30 Pues como cualquiera que viviera con un Prescott.
La pela es la pela, y cada vulnerabilidad es como un grifo abierto de dinero.
#29 Hombre es que si vienes a trollear soltando mentiras es normal . No te preocupes que te lo devuelvo y puedo estar así hasta el infinito, tú mismo
Bueno, supongo que Intel llevaba mucho tiempo reinando en el sector y esto no le vendrá mal para depurar un poco su arquitectura. Es lo que pasa cuando te acomodas y haces refritos sin parar. Por otro lado, me alegro por AMD, llevan un tiempo haciendo las cosas bien y encima, son nuevamente los elegidos para sostener la nueva generación de consolas, tanto de Sony como de MS.
#47 Si, ya, que lo haga otro y, si acaso, tú pones 10 eurillos desde casa y por internet... ya te he entendido, ya...
En el 2016 compré un I7-6700K porque su relación prestaciones / precio eran buenas, pero ahora probablemente esa relación haya empeorado. Me pregunto si se podría presentar una demanda individual y colectiva contra Intel por la pérdida de prestaciones, aunque por lo que leo en el artículo a nivel de usuario personal el impacto no es tanto.
#23 Presentar una demanda siempre es posible. No sé a qué esperas.
#32 me refiero a presentarla y que tenga posibilidades de salir a favor, ¡que hay que decirlo todo!, pero bueno si me la financias mañana mismo voy al juzgado.
Sería cuestión de consultar con un abogado especialista en estos temas y quizás realizar una solicitud de microfinanciación para sacarla adelante.
#23 Los de Facua y similares están ocupados con cosas importantes como el anuncio machista de El Corte Inglés del día de la madre. Cuando tengan tiempo para menudencias, se pondrán con ello.
#23 Si alguien se toma la molestia de leerte, su respuesta sera; El perjuicio futuro era desconocido en el momento de su venta y su impacto no justifica la continuacion de este proceso judicial, improcedente.
Si quieres que prospere deberias estar preparado para enseñar un par de ingenerias a unos cuantos jueces, letrados y toda una cadena judicial que superara los 60 años de media sin que se ofenda en el proceso y te manden a tu casa acusado de desacato a la autoridad
#38 En realidad, absolutamente todos los procesadores que utilicen ejecución especulativa y tengan una memoria caché son sensibles a Spectre: ARM, PowerPC... Es una cuestión inherente a ambos conceptos.
Lo que me sorprende es que no se hubiese descubierto la idea antes...
A ver cuando los medianos siguen el mismo paso. Estoy buscando VPS basadas en AMD sin recurrir a Amazon ni Microsoft, pero no hay modo de encontrar nada.
MDS es sin duda lo peor que le ha podido pasar a Intel y los proveedores de servicios en la nube están ahora mismo bien jodidos. Para que las máquinas virtuales sean completamente seguras, además de las mitigaciones, es necesario desactivar el hyperthreading y eso supone no poder vender el núcleo lógico como vCPU. O reducen el rendimiento el 40% o suben el precio al doble.
Siendo un profano en la materia, la sensación que da es que esas vulnerabilidades las tienen todos y sólo hay que encontrarlas.
#11 entonces no has entendido nada.
#17 No te lo niego, aunque con lo elaborado de tu prosa tampoco te lo compro. Añado a mi argumento el factor tiempo: hoy sufre intel, en unos años AMD, en otros años EPYC...
#19 nada de nada, pero tu sigue echando campanas al vuelo, igual asi terminas acertando.
#11 En realidad, estas vulnerabilidades son propias de la arquitectura. La mayoría no se pueden replicar en AMD porque su implementación de SMT es distinta y es más segura por diseño. Todas y cada una de las vulnerabilidades que han salido son porque para no penalizar el rendimiento (asumiendo la mejor de las intenciones), Intel se ha ahorrado hacer chequeos o poenr limitaciones a muchas operaciones, dejando registros legibles por procesos que no deberían tener acceso. Algunos de estos caminos no se van a poder encontrar nunca en los procesadores de AMD porque simplemente su sistema de multihilo funciona distinto, aunque de cara a la abstracción de un sistema operativo parezca idéntico al usuario.
La cosa es que Ryzen/TR/Epyc son procesadores con una arquitectura moderna, y en Intel están en la enésima iteración de Core. Algunas de estas vulnerabildades van hasta los tiempos de Netburst (Pentium 4), y la mayoría las tienes desde los primeros Core (que por cierto, Intel ya ha dicho que no va a parchear nada de antes de 2011, así que todos esos Core 2 Duo con Windows XP se van a quedar como están). Curiosamente, los últimos modelos tienen vulnerabilidades extra.
El problema es que no puedes coger y cambiar el sistema de Hyper Threading de un Xeon sin cambiar básicamente la CPU entera, pero vamos, es lo que les va a tocar, porque nadie va a comprar un lote de mil procesadores de $3000 sabiendo que son un coladero de seguridad y no se van a arreglar, o si se "arreglan", será a costa de reducir su rendimiento por debajo de lo que dan procesadores que valen la mitad o menos.
#25 Gracias rey.
#25 "Intel ya ha dicho que no va a parchear nada de antes de 2011"
Pero todas estas vulnerabilidades requieren en todas que tengas "acceso a la maquina" es decir que no afectan al uso normal(salvo por la bajada de rendimiento del parche) que un particular suele hacer de un ordenador, sino que más bien afectan a granjas de servidores, escritorios en la nube, hostings, etc. ¿o se me escapa algo al respecto?
Si es así, pocas maquinas quedarán con 10 años de antigüedad en esos centros, ¿no?
#40 Sí, el no parchear nada de antes de 2011 no va a afectar a Amazon, es más que si algún día se materializa un ataque no habrá forma de evitar que afecte a esos sistemas. En muchos casos esos sistemas se usarán en integrados industriales y demás, donde da igual, porque no hay conexión con el exterior, pero tienes también por ejemplo sedes de la administración u hospitales que actualizan sus equipos una vez por siglo donde la cosa no estará tan clara. Y bueno, el típico ordenador del abuelo que usa para mirar Facebook y entrar en páginas de "quién te tiene bloqueado".
Por otro lado, eso, algunas de las vulnerabilidades simplemente no son parcheables. De ahí que la solución pase por directamente desactivar el hyperthreading.
#44 Viendo como trabajan, "extraoficialmente" en la administración y especialmente hospitales, es el menor de sus problemas.
Ejemplo: Todos los pcs del departamento de un familiar de un gran hospital del pais tienen TeamViewer instalado(sin licencia), se llevan historias de pacientes a casa y en sus ordenadores personales, etc. Todo, por lo que sé, con buena fé, pero se saltan toda normativa de seguridad y LOPD habitualmente por no decir diariamente.
#50 En españa olvidate del tema de la seguridad, el ultimo programa que se desarrollo e implemento para modernizar la judicatura hizo practicamente publicos (nivel hacker script kiddie, segun la propia policia) todos los archivos judiciales introducidos en el mismo y nadie hizo nada.
#11 Y no te falta razón, AMD de momento no se ha demostrado vulnerable a Meltdown pero si a Spectre, o sea que seguro seguro tampoc es.
https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/
No voy a decir que os lo dije, perooo...
En cualquier caso hay familias de ataques de canal lateral estilo Meltdown/Spectre que también afectan a AMD.
Aun así, las tres últimas familias de ataques, denominadas "microarchitectural data sampling" (ver https://cpu.fail ) han sido una cagada para Intel pero guena, guena.
#6 sí pero a Intel la penalizan un 16% y a AMD un 3%, es decir las mitigaciones penalizan más de 5 veces más a Intel que a AMD
Intel pierde en sus CPUs 5 veces más rendimiento de media que AMD por las mitigaciones contra vulnerabilidades [ENG]
Intel pierde en sus CPUs 5 veces más rendimiento d...
tomshardware.comYa lo dijo el tito Linus que intel la cago bién, y ese tiene unas maneras de decirlo que tal vez no le gusten a mucha gente,pero a mi manera de ver tiene más razón que un santo y, de programación , de procesadores, servidores, del kernel linux etc.. sabe lo que no sabemos a aquí 100.000 personas juntas.
Ademas, los AMD no sólo te procesan la información si no que puedes hacer barbacoas poniendo la panceta encima del procesador
#10 Los Ryzen/Epic son bastante más frios que sus equivalentes Intel
#14 Toma que se te cayó un negativo
#10 El hombre desactualizado. ¿Tienes también algún chiste sobre Windows 95 con el que amenizarnos?
#20 #10 #26 Cualquiera que haya vivido con un AMD a 90 grados en su casa no lo olvida fácilmente
#10 Are you from the past?
#10 Venga va, sólo la falta la cita de la memoria expandida y sus 640k y ya tenemos el pack completo.
#10 Para pasar un invierno calentito en Siberia no hay nada como un Pentium D