Portada
mis comunidades
otras secciones
#16:
#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 😉
PD: que pronto se nos olvidan otros "fallos" como el dieselgate de Volkswagen
PD: que pronto se nos olvidan otros "fallos" como el dieselgate de Volkswagen
#2:
Movimiento lógico por parte de AMD.
#6:
#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.
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.
#7:
#5 No cabe duda que ahora mismo Ryzen es una opción muy interesante. Han vuelto al terreno de juego.
El problema principal es que en el mercado de servidores ahora mismo esto es un golpe en pleno corazón. Casi todo se virtualiza y una empresa seria va a querer el parche aplicado. Aunque es cierto que dependiendo de lo que tengas montado (vease un servidor con varias máquinas virtualizadas) puede no existir ese problema y lo dejas sin parchear. Pese a que eso suponga un riesgo de procesos virtualizados que puedan acceder a otros procesos virtualizados.
Si AMD se pone las pilas puede hacer mucho daño en ese sector. En estos instante ThreadRipper es una opción más que deseable.
El problema principal es que en el mercado de servidores ahora mismo esto es un golpe en pleno corazón. Casi todo se virtualiza y una empresa seria va a querer el parche aplicado. Aunque es cierto que dependiendo de lo que tengas montado (vease un servidor con varias máquinas virtualizadas) puede no existir ese problema y lo dejas sin parchear. Pese a que eso suponga un riesgo de procesos virtualizados que puedan acceder a otros procesos virtualizados.
Si AMD se pone las pilas puede hacer mucho daño en ese sector. En estos instante ThreadRipper es una opción más que deseable.
#58:
#27 En el diff se ve que añaden estas dos funciones:
static void __init pti_print_if_insecure(const char *reason)
">
static void __init pti_print_if_secure(const char *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)
return;
">
ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
if (ret > 0) pti_print_if_insecure("disabled on command line.");
return;
">
if (ret == 2 && !strncmp(arg, "on", 2)) goto enable;
">
if (ret == 4 && !strncmp(arg, "auto", 4))
goto autosel;
}
if (cmdline_find_option_bool(boot_command_line, "nopti")) 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.
static void __init pti_print_if_insecure(const char *reason)
">
static void __init pti_print_if_secure(const char *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)
return;
">
ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
if (ret > 0) pti_print_if_insecure("disabled on command line.");
return;
">
if (ret == 2 && !strncmp(arg, "on", 2)) goto enable;
">
if (ret == 4 && !strncmp(arg, "auto", 4))
goto autosel;
}
if (cmdline_find_option_bool(boot_command_line, "nopti")) 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.
#26:
#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:
https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438
Llámalo casualidad si quieres
https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438
Llámalo casualidad si quieres
#1:
Un resumen breve pero conciso del problema: https://elchapuzasinformatico.com/2018/01/intel-esta-serios-problemas-cpus-tienen-una-vulnerabilidad-arreglarla-implica-35-rendimiento/
#3:
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
Comentarios
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 😉
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.
https://www.profesionalreview.com/2017/07/25/principal-ingeniero-intel-abandona-la-compania/
#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
Bingo! IKPTI (Intel Kernel Page-Table Isolation) BUG [ENG]
Bingo! IKPTI (Intel Kernel Page-Table Isolation) B...
twitter.com#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, 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.
https://www.reddit.com/r/pcmasterrace/comments/7nthay/a_quick_summary_of_the_current_intel_cpu_bug/
El CEO lo sabía hace más de un mes y por eso vendió todas las acciones, el hecho de que no hayan avisado antes hace sospechar bastante
El CEO de Intel vendió la mitad de sus acciones un mes antes de conocerse el fallo de seguridad de los procesadores
El CEO de Intel vendió la mitad de sus acciones un...
es.gizmodo.comEstá confirmado que el único procesador no afectado es el Pentium original
The issue impacts all modern Intel CPUs. (Edit: It's been confirmed that the latest unaffected CPU is the original Pentium.)
#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é disponible físicamente.
https://es.wikipedia.org/wiki/Memoria_virtual
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Repite conmigo : Permite que los programas de usuario normales, desde las aplicaciones de bases de datos hasta JavaScript en los navegadores web, puedan discernir en cierta medida el diseño o el contenido de las áreas protegidas de kernel.
La persona Random sabe bastante más que tú de como funciona un procesador por dentrop y yo también que para eso soy ingeniero informático
#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? 😂 😂 😂
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
#16 Veamos, no es tan directo. En el fondo el que hace la trampa es la precarga, algo que Intel hace mucho para ir adelantando trabajo. El problema es que mediante el bus lateral se puede acceder a esos datos precargados, saltándose así la seguridad de las páginas.
Probablemente no sea intencionado...pero después de 10 años. Me temo que estaban al tanto de ello.
#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.
https://www.reddit.com/r/pcmasterrace/comments/7nthay/a_quick_summary_of_the_current_intel_cpu_bug/
#31 Pues no es tan sencillo. Depende de muchas condiciones. Vuelvo a repetir que el problema es en la precarga que hace el procesador y el acceso al bus lateral de datos. Que permite en los casos que se ha ejecutado precarga, acceder a los datos por el bus lateral...con lo que te pasas el aislamiento de página por el forro de los huevers.
Muy bonito sobre el papel. Pero dificil de implementar. ¿Hay que parchearlo? Sin duda alguna.
#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:
https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438
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.
https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438
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
Aquí explicado también
https://media.ccc.de/v/34c3-9135-aslr_on_the_line
En cuanto a la utilidad, obtener cualquier dato protegido ejecutandose en el Kernel, desde claves privadas, contraseñas, etc...
tienes más información aquí en la cual explica el concepto de "memoria virtual" que no solo implica a máquinas virtuales sino a TODOS los procesos, los cuales usan TODOS, sin excepción, memoria virtual en el sistema
Recap: Virtual Memory
In the usual case, when some machine code attempts to load, store, or jump to a memory address, modern CPUs must first translate this virtual address to a physical address, by way of walking a series of OS-managed arrays (called page tables) that describe a mapping between virtual memory and physical RAM installed in the machine.
Virtual memory is possibly the single most important robustness feature in modern operating systems: it is what prevents, for example, a dying process from crashing the operating system, a web browser bug crashing your desktop environment, or one virtual machine running in Amazon EC2 from effecting changes to another virtual machine on the same host.
The attack works by exploiting the fact that the CPU maintains numerous caches, and by carefully manipulating the contents of these caches, it is possible to infer which addresses the memory management unit is accessing behind the scenes as it walks the various levels of page tables, since an uncached access will take longer (in real time) than a cached access. By detecting which elements of the page table are accessed, it is possible to recover the majority of the bits in the virtual address the MMU was busy resolving.
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
#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 major security patches for the Linux kernel have been pushed out over the Christmas and New Year holidays, which are likely to be an attempt to fix the new bug.
https://siliconangle.com/blog/2018/01/02/intel-patches-critical-processor-security-bug-fix-imposes-35-performance-hit/
Anda deja de buscar excusas con tal de tener razón que no sabes ni lo que hablas, pareces un crio de 16 años intentando sacar pecho
#61 Hala, ahí lo tienes, tan simple como ejetutar tres lineas de comandos de sistema operativo
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.
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
#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
#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
Comunicado de AMD respecto a la seguridad de sus procesadores [ENG]
Comunicado de AMD respecto a la seguridad de sus p...
amd.comEn español aquí
AMD niega la acusación de Intel de que sus procesadores son vulnerables por un fallo de seguridad
https://es.gizmodo.com/amd-niega-la-acusacion-de-intel-de-que-sus-procesadores-1821754715
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 vulnerables. ¿Quiere decir esto que se descubra una nueva variante de ataque y esta pueda afectar a AMD? Podría ser, por eso dice que la probabilidad ahora mismo es cercana a cero.
En resumen de los ataques que ahora mismo se conocen sobre el problema de acceso al bus de datos lateral con la precarga expeculativa AMD no es vulnerable. Puesto que por su propia arquitectura esto no se permite (da error de fallo en página). Es decir AMD si hace las comprobaciones de seguridad en la unidad expeculativa."
#92 ¿Pero qué acusación de intel? ¿te has mirado el paper original de Project Zero que son los que lo han sacado? https://googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-with-side.html
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 (venta de stock options por el CEO de esa compañía) y demás chapuzas de diseño realizadas en el pasado (usar pasta termica de mala calidad en los procesadores deliberadamente para que no se puedan overclockear los procesadores, etc) me hace sospechar de que esta compañía A tiene todas las papeletas o la mayoría de ser complice o conocedora de tal fallo en el diseño de sus procesadores
Puedes no estar de acuerdo si no quieres pero esas son mis razones
#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 seguridad para evitar la lectura de la parte del kernel deliberadamente, esto quiere decir que eran conscientes de que sin ese sistema había vulnerabilidad, así que tienes dos opciones
1- No probaron el sistema adecuadamente => Panda de inútiles (que no lo creo)
2- Lo probaron y descubrieron que no funcionaba adecuadamente => Eficientes pero dar marcha atrás a una arquitectura es muy costoso y la vulnerabilidad dificil de detectar (muy probable)
Obviamente me puedo equivocar pero hechos pasados de Intel me hacen pensar que han "tapado" deliberadamente el fallo, y si no toda la compañía al menos parte de ella
#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
Intel lanzó su generación Coffee Lake sabiendo que los procesadores eran vulnerables a Meltdown y Spectre
Intel lanzó su generación Coffee Lake sabiendo que...
elchapuzasinformatico.com#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
#5 No cabe duda que ahora mismo Ryzen es una opción muy interesante. Han vuelto al terreno de juego.
El problema principal es que en el mercado de servidores ahora mismo esto es un golpe en pleno corazón. Casi todo se virtualiza y una empresa seria va a querer el parche aplicado. Aunque es cierto que dependiendo de lo que tengas montado (vease un servidor con varias máquinas virtualizadas) puede no existir ese problema y lo dejas sin parchear. Pese a que eso suponga un riesgo de procesos virtualizados que puedan acceder a otros procesos virtualizados.
Si AMD se pone las pilas puede hacer mucho daño en ese sector. En estos instante ThreadRipper es una opción más que deseable.
#7 ye están en ello:
http://www.amd.com/es/products/epyc
#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 Es que AMD y ARM también son vulnerables
https://googleprojectzero.blogspot.in/2018/01/reading-privileged-memory-with-side.html?m=1
#4 Me parece que si están afectados según Google: https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them."
Un resumen breve pero conciso del problema: https://elchapuzasinformatico.com/2018/01/intel-esta-serios-problemas-cpus-tienen-una-vulnerabilidad-arreglarla-implica-35-rendimiento/
#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
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 )
#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
https://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.
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:
https://es.gizmodo.com/el-ceo-de-intel-vendio-la-mitad-de-sus-acciones-un-mes-1821732438
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. 😂 😂
Ya han metido X86_BUG_CPU_INSECURE directamente en el parche del kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/x86/mm/pti.c?id=5aa90a84589282b87666f92b6c3c917c8080a9bf
#27 En el diff se ve que añaden estas dos funciones:
static void __init pti_print_if_insecure(const char *reason)
">
static void __init pti_print_if_secure(const char *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)
return;
">
ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
if (ret > 0) pti_print_if_insecure("disabled on command line.");
return;
">
if (ret == 2 && !strncmp(arg, "on", 2)) goto enable;
">
if (ret == 4 && !strncmp(arg, "auto", 4))
goto autosel;
}
if (cmdline_find_option_bool(boot_command_line, "nopti")) 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.
#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%
Primero los motores de explosión, ahora los procesadores de silicio. ¿Qué será lo siguiente?
¿Los procesadores de 64 bits están afectados?
#34 Sí todos los de Intel desde hace 10 años.
#37
#34 En principio, que yo sepa, sí, los de 2007 hasta ahora.
Sponsors of CPUgate. PAMMMMmmmmm… papam PAPAM.
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.
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:
https://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.
Menudo culebrón
#75 sera la placa compatible con el nuevo procesador?
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.
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
#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 https://es.wikipedia.org/wiki/Error_de_divisi%C3%B3n_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.
#72 la placa no me la como porque tengo intención de comprar un intel de los nuevos cuando los rebajen estrepitosamente de precio.