La cosa empeora: el parche para Spectre de Microsoft deja algunos PCs con procesador AMD inutilizables [ENG]

El parche de Microsoft para los bugs Spectre y Meltdown podrían estar dejando PCs equipados con [procesadores] AMD inutilizables. Un extenso hilo en answers.microsoft.com registra numerosas instancias en las cuales la actualización de seguridad para Windows KB4056892, el parche para Meltdown/Spectre de Redmond, deja algunos PCs equipados con [procesadores] AMD con el logo de inicio de Windows y poco más.

[#3 Veelicus]

El parche que ha hecho Microsoft en funcion de la documentacion que le ha pasado Intel deja los PCs de AMD fritos???, que cosa mas rara oiga

[#5 apetor]

#3 Me da que son las "prisas" y que se han dejado alguna combinación procesador-estado sin probar... ocurre con algunos Athlon...

[#80 AGlC]

#5 Si, algunos como el mío
(Cagandome en todo desde mi móvil)

[#1 JoanSerrallonga]

Bueno, el parche funciona, no te pueden hackear

[#2 apetor]

#1 Pues funciona, sí, parecido, sólo que consumiendo más electricidad, a darle al interruptor o desenchufarlo.

[#4 ChukNorris]

#1 Lo convierte de un plumazo en el sistema operativo más seguro. Chupate esa Linux!!!

[#15 frankiegth]

#1. Ni te pueden hackear ni puedes encender el PC. Ese 'parche' ya lo conocíamos todos...

[#35 BastianBaltasarBux]

Y seguimos sin ninguna explicación ni comunicado por parte de Microsoft.

Lo que ocurre es lo siguiente: Se instala el parche, se reinicia el ordenador y se queda el logo de windows congelado sin posibilidad de hacer nada, al forzar el reinicio dos veces el asistente de Windows desinstala el parche y puedes volver a entrar. El parche se vuelve a descargar y otra vez a empezar...

Yo he tenido que pausar los updates porque la situación era insufrible.

Por ahora no hay ni explicación, ni comunicado ni solución ni nada y la gente está que trina por los foros de Microsoft.

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/after-installation-of-kb4056892-boot-failure-after/6c015632-2a45-4725-a882-f231f8c88f36?auth=1

[#52 Desactivado]

#35 eso es justo lo que me pasa a mi con un Athlon 64

[#82 Desactivado]

#35 Ya hay comunicado, lo he subido porque me parece importante que esté la gente informada, sobre todo los usuarios de ADM

Comunicado de Microsoft por el bloqueo de Windows en sistemas AMD tras la actualización de seguridad de Meltdown [ENG]

Comunicado de Microsoft por el bloqueo de Windows ...

Hay uno en el foro que tiene un AMD Ryzen Threadripper 1950 de los nuevos y que también le pasa (página 10)

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/after-installation-of-kb4056892-boot-failure-after/6c015632-2a45-4725-a882-f231f8c88f36?auth=1

[#44 Desactivado]

Doy fe, soy el poseedor de un AMD antiguo y con el último parche windows no arranca, a partir del tercer intento arranca en modo recuperación, desinstala el parche y vuelve a funcionar, después vuelve a intentar instalarlo entrando en un bucle.

[#22 TheGreatDoc]

En realidad no es un parche para Spectre y Meltdown, es un parche para mantener el valor de Intel en bolsa.

[#25 idiran]

#24 No es un bug. No es un problema de implementación, sino de diseño. Ahora mismo no se sabe como hacer un procesador que resuelva el problema sin una pérdida importante de rendimiento. Esto no es un bug.

[#27 Tolker]

#25 https://tecnovortex.com/intel-y-la-suma-de-todos-los-miedos/

[#31 Desactivado]

#27 #24 #6

Lo interesante es que una vez analizada la debilidad y viendo cómo saca los datos .... es que no hay forma de pararlo con la arquitectura actual. Vamos, que si no es spectre será spectra (qué madre ha sonado eso)

Me ha costado entender cómo sacar los datos ... pero el que lo ha diseñado es el puto amo del calabozo. Pal que le interesa, una explicación espero que un poco claro (es sólo de la parte de sacar los datos de la parte protegida, el cómo lo hacen spectre o meltdown va en otro sitio)

http://www.calderodemurias.com/2018/01/spectre-recuperacion-del-dato-entre-lo.html

[#53 Yomisma123]

#31 Gracias por el link, quería votarte positivo. Te compenso en otros comentarios

[#56 Desactivado]

#53

Do not worry.

[#64 apetor]

#25 y #31 Ojo, eso no es verdad en la parte mas gorda, meltdown. Se sabe como hacerlo y se sabe que habra un impacto en el IPC, si, pero AMD ( en meltdown ) lo hace bien y tiene buen IPC.

[#83 Desactivado]

#64

Meltdown es sólo una manera de acceder a los datos protegidos (en este caso, fuerza una excepción). Lo que hace el parche KPTI (o KAISER) es mover las tablas de memoria del kernel a otro sitio (al parecer antes se compartían en el espacio de direccionamiento del proceso, pero protegidas)

Es posible (aunque más complejo) desarrollar un Meltdown II que vaya a otro sitio a buscar las mismas tablas. El problema grave es que es posible acceder a la zona de memoria protegida y eso es muy complejo de resolver.

Ahora mismo, sólo se me ocurre proteger criptográficamente por HW la memoria, como pueden hacer (al menos) los SPARC M-7. No tengo claro si es posible protegerlo por SW (encriptar la memoria de manera segura por SW ya que siempre van a poder acceder a las zonas de memoria protegidas)

[#86 apetor]

#83 Jode... lo he dicho varias veces ya, para soluconar meltdown basta con hacer los chequeos de privilegios ANTES de hacer el acceso a memoria en la ejecucion especulativa. No tienes muy claro como va el tema, creo...

[#92 Desactivado]

#86

El tema es que para hacer eso hay que cambiar todas las CPUs y rehacer la ejecución especulativa, aparte de la out-of-order y te cargas buena parte de la optimización de la CPU.

[#93 apetor]

#92 El ejemplo es AMD, ellos lo hacen bien.

[#94 Desactivado]

#93

No, no lo hacen bien. Son vulnerables a spectre, como casi todos.

De hecho, meltdown o spectre son dos formas de hacer lo mismo; acceder a datos protegidos usando la caché de manera indirecta.

La única forma que habría de protegerse de eso sería encriptar la memoria por HW (claves distintas para cada anillo del OS) de manere que aunque saques los datos del kernel no te sirvan (SPARC T-7)

[#95 apetor]

#94 En Spectre, en cuanto a la CPU se refiere, no hay violacion del limite modo usuario vs modo kernel; hace falta usar cosas de los kernels para hacer cache side channel attack de kernelmode a kernelmode indirectamente, desde una peticion de modo usuario.

Meltdown, que es lo gordo, usa cache side channel attack tambien, pero gracias a que EN INTEL, esa ejecucion especulativa no chequea los accesos a memoria desde modo usuario a modo kernel ANTES de leer los datos a cache, ese cache side channel attack sirve para violar la barrera modo usuario vs modo kernel.

Yo estoy un poco cansado de explicar esta y otras cosas pero diria que mucha gente no tiene las cosas claras en todo esto.

[#101 Desactivado]

#93

Y vuelve la burra al trigo.

https://access.redhat.com/security/vulnerabilities/speculativeexecution

. There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

[#84 idiran]

#31 Exacto, no es un problema de implementación. No hay nada que corregir realmente, no en el chip. Funcionan así.

La única forma de enfrentarse a estas cosas es tener en cuenta la seguridad en tiempo de diseño. Al hacer esto te dotas de una colección de mecanismos de seguridad a los que podrás echar mano cuando salgan imprevistos parecidos a este, que, entonces sí, serían detalles de implementación.

[#32 suzudo]

#25 Entonces los AMD ryzen, los RISC-V, los microordenadores raspberry pi etc ¿tienen ese "bug"?
Porque están diciendo que para esos modelos, no

[#36 pawer13]

#32 los AMD Ryzen sí, los Raspberry tienen un procesador ARM, pero de gama tan baja que no tiene implementada esa funcionalidad (y así son, bastante lentos en comparación con cualquier móvil de gama media). Los RISC-V no, pero no sé si es porque no lo implementan o porque lo hacen de otro modo

[#38 suzudo]

#36 Ah. Pues vale pero decían que los ryzen estaban libres desde la misma AMD

[#40 pawer13]

#38 si no entendí mal, los AMD están libres de Meltdown, no Spectre, que les afecta pero de un modo no tan grave como a Intel

[#69 suzudo]

#40 leí de la misma AMD que spectre afectaba a los AMD FX para abajo pero los ryzen de AMD quedaban libres, risc-V parecería que también libre y Raspberry-pi tampoco tenían ninguno...

no se, no se... bueno a ver que sale al final

[#78 Desactivado]

#69 Acabo de ver en el foro de Microsoft a uno que le ha afectado con un Ryzen 1950x Threadripper y ese es de los más nuevos así que cuidadito

[#107 suzudo]

#78
Pues vaya...
Muchas gracias por la info

[#41 Desactivado]

#36 #38 Os seguís liando con lo mismo...

Se han descubierto tres bugs. Los dos primeros (Spectre) afectan a cualquier CPU con ejecución especulativa, sea x86, ARM, o POWER. El tercero (Meltdown) sólo afecta a CPUs Intel.

[#68 suzudo]

#41 ¿todos tienen ejecución especulativa de la misma forma?

[#112 apetor]

#68 No. Ejecucion especulativa de tipo "vete ejecutando instrucciones mas alla de la actual" lo hacen casi todos los procesadores tipo "out of order execution", que son casi todos los potentes y que son los que nos ocupan.

* Atento que vienen curvas * ( estaba pensando en retocar esto y hacer un miniarticulo, quiza lo haga )

El caso es que cuando el procesador se esta ejecutando en modo usuario ( esto es, aplicaciones normales ), los accesos a memoria de kernel ( memoria del nucleo del sistema operativo y drivers de dispositivos ) no estan permitidas, pues supondria un problema de seguridad y comprometeria dicho nucleo o drivers. Todos los procesadores implementan circuiteria para que una instruccion de usuario que viole esta norma produzca un "fallo" que es capturado por el nucleo y hace que la aplicacion se cierre y la seguridad del sistema no se comprometa. Las aplicaciones pueden evitar ser cerradas por estos fallos ( capturando "excepciones" ) y continuar su ejecucion por otra rama de instrucciones pero nunca podran saltarse esa barrera y esa instruccion que intenta leer memoria de kernel no podra hacerlo.

Por otro lado, los procesadores modernos tienen una memoria intermedia muy rapida llamada cache; cuando una instruccion lee algo de memoria RAM ( que es mucho mas lenta que la cache ), en vez de leerse directamente y ya esta, lo leido tambien se almacena en esa memoria cache para que, si ocurren accesos a la misma direccion en un futuro proximo, no haga falta leerlos desde la RAM otra vez y se lean mucho mas rapido desde la cache.

La cache es muy rapida pero su tamaño es mucho menor a la de la RAM, por eso el procesador va usando la cache descartando cosas viejas o de acceso poco frecuente y dejando solo lo reciente o lo accedido frecuentemente.

Pues bien, el fallo gordo, meltdown, se da porque, en procesadores intel, hay una diferencia fundamental con respecto a los demas fabricantes:

--- Intel:

Supon que estoy ejecutando la instruccion N y la ejecucion especulativa va ejecutando al mismo tiempo las instrucciones "futuras" N+1, N+2,... asi unas cuantas y al mismo tiempo. A su vez, todas esas instrucciones van accediendo a memoria y las cosas que se van leyendo se quedan almacenadas en la memoria cache. Pues supon que la instruccion N+2 tiene un acceso a memoria de modo kernel ( acceso que no debe poder hacer, como he explicado en el parrafo dos ) y que indica que eso que leeria desde esa direccion de kernel debe depositarse en un registro X. Y supon que la instruccion N+3 tiene un acceso a memoria de usuario apuntado por [Base+(X*1000)], donde X es el mismo registro donde la instruccion N+2 depositaria su resultado. Esto es, la instruccion N+3 leeria de memoria de usuario y dependiendo de el valor de ese X leido en N+2, se leeria de Base+0000, Base+1000, Base+2000,...

Bien, todo esto esta pasando casi casi en paralelo y en un momento dado el procesador se da cuenta de que la instruccion N+2 no debia de haber accedido a la memoria de kernel ( como explico en el parrafo dos ) y deshace la ejecucion de N+2 y de N+3 y provoca el fallo para que el nucleo del sistema operativo decida si cerrar el programa o, si el programa ha capturado la excepcion, pueda continuar su ejecucion pero siempre sin haber podido leer esa memoria de kernel.

Hasta aqui todo bien, todo se deshace y N+2 no ha conseguido leer la memoria de kernel ( el registro X quedara intacto, valdra lo que valia antes de ejecutar N+2, no lo que se leeria de memoria de kernel ) y N+3, a efectos, tampoco se h ejecutado por que se han deshecho sus cambios. ¿ verdad ? Puesss, no, hay un matiz: aunque los cambios de N+2 y N+3 se hayan desecho, lo leido por N+2 y N+3 ha quedado en la cache. Una siguiente instruccion que acceda a la posicion de memoria de kernel donde N+2 intento acceder seguira sin poder acceder, por mucho que lo leido por N+2 y que ahora se vuelve a intentar leer este en la cache, eso provoca un fallo ( el mismo que lo explicado en el parrafo dos y en el parrafo anterior a este ). Pero ¿ que pasa si en vez de eso ejecutamos una instruccion que acceda a una direccion de memoria como [Base+(Y*1000)] ( que segun valga Y ese acceso se hara a [Base+0000] o [Base+1000] o [Base+...] ) como hacia N+3 ? recuerda que esas direcciones eran memoria de usuario asi que era legal acceder a ellas. Pues de cualquier manera esta instruccion funcionara bien, ya que ese [Base+...] esta en memoria de usuario, lo que pasa es que, dependiendo del valor que le demos a esa Y antes de ejecutar esta instruccion, y dependiendo de si ese valor de Y coincide con el valor que habia tenido X al ejecutar N+3 tras ejecutar N+2 DENTRO de la fase de ejecucion especultiva, ese acceso a [Base+(Y*1000)] leera directamente de memoria RAM o, si Y coincide con el X de ese momento, desde la cache. A nosotros nos da igual lo que lea de esa [Base+(Y*1000], es memoria de usuario y no supone nada poder leer de ella. Pero claro, como segun ese valor de Y, se leera de cache o de RAM, que pasa, pues que hay un Y=algo para el cual el acceso es a cache y es mucho mas rapido ( parrafos 3 y 4 ).

Si vamos probando valores de Y y haciendo el acceso repetidamente para Y=0, Y=1, Y=2... hasta, por ejemplo, 255, y medimos los tiempos de acceso para cada iteracion, habra un Y=algo para el cual el tiempo de acceso a memoria que sea mucho mas rapido por haber estado en la cache debido a que ya se accedio al ejecutarse N+3.

Y recuerda, esa interacion Y=algo sera rapida cuando este en cache y estara en cache cuando valga lo mismo que valio X cuando se ejecuto N+3 en la ejecucion especulativa. Finalmente, X, en el momento de ejecutarse N+3 en la ejecucion especulativa, ¡¡¡ valia lo que N+2 habia leido de memoria de kernel !!!

Asi que, probando valores de Y y viendo cual es el que tarda poco, podemos inferir el valor de lo que, por mucho que sus efectos fueran descartados/deshechos al ver que N+2 violaba la barrera usermode>kernelmode, se habia leido de kernel.

Esto es, esto es una forma poco ortodoxa y lenta ( aun asi muy rapida ) de leer cualquier byte de memoria de kernel desde una aplicacion cualquiera.

Nos hemos saltado el esquema de privilegios de memoria que se viene utilizando desde el 386 ( 1985, si no recuerdo mal ). Esto no quiere decir que el fallo venga desde ahi, viene desde los primeros Core, creo.

--- El resto de fabricantes:

No se sabe como, pero como analisis de caja negra o de comportamiento observable desde el exterior, AMD, ARM y otros:

a) o bien chequean los privilegios de acceso de la direccion a la que se accede en ejecucion especulativa y lo hacen ANTES de leer nada y ponerlo en la cache

b) o bien, cuando se dan cuenta de la violacion de acceso de forma diferida, no solo deshacen los efectos de la instruccion que viola la barrera usermode>kernelmode, sino que, ademas de eso, "limpian" las entradas de cache correspondientes de la ejecucion de esa y todas las posteriores instrucciones.

Me decanto por la a) y, en caso de AMD, creo que eso se hace bien por que AMD lleva muchos años teniendo la MMU muy acoplada, totalmente mezclada, diria yo, a toda la circuiteria de ejecucion; vamos, estan fusionadas. Intel lleva varias generaciones con la MMU en la CPU tambien, si, pero puede que no este tan fusionada. Pero bueno, todo esto es especulacion.

[#50 Desactivado]

#36 edit

[#58 Desactivado]

#32 Sólo el Spectre que es parcheable sin pérdida de rendimiento.

Las Raspberry son inmunnes a todos

[#57 Desactivado]

#25 Pregúntale a AMD, Spectre es parcheable sin pérdida de rendimiento, Meltdown es el problema y cuyo parche es el que provoca la pérdida de un 30% de rendimiento y es exclusivo de Intel

[#66 Desactivado]

#62 no obstante desinstalala si lo ves oportuno, que no te extrañe que provoque el uso de un sistema parecido a KAISER y provoque una pérdida de rendimiento (o inestabilidad) equivalente a la de los Intel que en Linux paso parecido cuando marcaron a todos los procesadores x86 como inseguros ante Meltdown

[#96 Orgfff]

#66 Gracias, Harkon. Veo que entiendes del tema de Windows.
Una pregunta, ¿sabrías decirme cómo puedo ver el proceso que deja congelado a mi PC? El caso es que cuando ocurre, sólo tengo la opción de pulsar el botón de encendido x segundos hasta que se apaga y luego volver a encender el PC, y lo raro es que arranca como si no hubiera habido fallo (ya sabes, lo de la opción de arrancar en modo seguro cuando ha habido un apagado forzoso).

[#98 Desactivado]

#96 Abriendo el monitor de recursos o el adminsitrador de tareas y vas a procesos, luego ordenas por uso de CPU y habitualmente tendrás un proceso usando el 100% de la CPU pero vamos puede pasarte que no, yo desinstalaría ese update, de hecho yo lo hice, mi novia tiene el FX 6300 y también se lo he quitado por si las moscas

[#37 Don-nadie]

Tengo que reconocer que hay gente con valor, no instalo yo un parche de Mocosoft sacado a la carrera y que afecta directamente a la CPU ni "cocío" Moriles. Actualmente todos los equipos de mi empresa y los míos particulares, van con XP o con W7 con todas las actualizaciones desactivadas, si ahora mismo me pusieran en la disyuntiva de Spectre o W10 con parche, posiblemente me quedase con Spectre, creo que me espiaría menos.

Un saludo y que os se leve el parche.

[#42 Desactivado]

#37 ¿Sabes por qué Microsoft fuerza ciertos parches? Pues por los listos que desactivais las actualizaciones. Luego sale un fallo de seguridad super gordo que se cepilla miles de PCs, como el Wannacry, y resulta que llevaba parcheado desde hacía meses pero la gente no se había instalado el parche.

[#77 chavi]

#42 Sabes por qué los "listos" desactivan las actualizaciones?. Porque son tan chapuceras que imliden trabajar.

Chapuzas.

[#43 Desactivado]

#37 ande vas con XP y w7 so loco

[#70 mrkroket]

#43 #45 Y sin updates....

[#45 deabru]

#37 XP... es jugársela ya.

[#6 idiran]

No entiendo las prisas aterrorizadas para instalar un parche cuando no existe ningún exploit. Por lo menos aprovechar para probarlo bien antes ¿no?

[#8 apetor]

#6 Sí, eso es.

[#48 Desactivado]

#6 Cómo que no hay exploit? Tú no andas muy enterado del tema no?

intel cpu - Using #Meltdown to steal passwords in real time

https://www.reddit.com/r/sysadmin/comments/7o109b/using_meltdown_to_steal_passwords_in_real_time/

cc #8 #9 #11 #19 #39 #46

Por cierto en mis dos ordenadores (ambos AMD Ryzen y FX) ya tenía bajado el parche pero no aplicado (faltaba el reinicio) los acabo de desinstalar y bloquear las actualizaciones durante 35 días 😅

Gracias #0 que si no quizás me hubiese quedado sin ambos

[#63 apetor]

#48 Quiza se refiera a que no hay malware usando el exploit, pero esperar mucho puede ser jugarsela, si. Ahora, las prisas traen estas cagadas tambien.

[#73 chavi]

#63 Como sabes eso?

[#87 apetor]

#73 Ahi esta el tema, no lo se y es peligroso asumirlo; yo no lo asumiria. Pero si digamos limitas tu actividad, no entras mas que en sitios de confianza ( que pueden haber sido hackeados, si ), etc. quiza puedas asumir unos dias mas de riesgo hasta que se hayan limado asperezas en dichos parches; tampoco es una postura descabellada.

[#9 ur_quan_master]

#6 Hay que aprovechar el tirón para instalar de rebote los parches de la NSA.

[#10 idiran]

#9 Viste las presentaciones de Snowden? Él tenía un menú para entrar en cualquier ordenador, algo totalmente automatizado. Un click y dentro.

[#49 Desactivado]

#10 video o link, por favor

[#11 court]

#6 Si existen exploits comunicado-amd-respecto-seguridad-procesadores-eng/c06#c-6

Comunicado de AMD respecto a la seguridad de sus p...

[#14 idiran]

#11 vale, pero, ¿liberados en la selva?

[#19 Desactivado]

#14 Dale 2 horas a un programador experimentado y veremos como empiezan a aparecer leaks.

[#39 Desactivado]

#14 Puede que no los tenga tu vecino el cracker, pero seguro que hay grupos tochos de hackers (agencias de espionaje, servicios de información) que lo tienen o trabajan en ello.

[#71 harapo]

#39 Dios mío, toda mi colección de porno en peligro de ser robada por hackers rusos!

[#74 chavi]

#71 Cuando su PC sea una calefacción, hablamos...

[#75 harapo]

#74 Um. No me parece mal como concepto, pero creo que los hackers rusos tendrán otras cosas más importantes que hacer con mi equipo. Minar criptomonedas, desestabilizar gobiernos, o tomar los planos secretos de la estación orbital...

[#89 apetor]

#75 Minar crypto == calefaccion.

[#13 ED209]

#6 "no hace falta aplicar parches de seguridad, no existe ningún exploit, estos no son los androides que buscáis"

[#24 Tolker]

#6 No existe ningún exploit y el bug es de hace 20 años.

[#46 sangetsu]

#6 para spectre no pero para meltdown ya lo hay.

[#51 LelakiSerius]

#6 Las prisas es por la alta difusión que ha tenido dicha vulnerabilidad. Si se hubiesen callado, podrían haber pasado años hasta que a alguna mente malévola la encontrase y la explotase.

[#76 chavi]

#51

Supongo que es irónico....

[#85 idiran]

#51 Por lo que dicen, ha saltado la liebre un mes antes de tiempo.

[#72 chavi]

#6 Que no existe qué?

[#90 idiran]

#72 Hay muchas cosas que no existen:

- Todo lo sobrenatural, incluyendo lo que dicen las religiones
- Los efectos de las medicinas "alternativas"
- Las justificaciones de las ideologías, por ejemplo del feminismo
- La mayoría de las conspiraciones, aunque ocasionalmente alguna acierte
- Los OVNIs y su puta madre
- La conciencia fuera del cerebro
- etc.

[#100 Desactivado]

#99 Cuando leí la noticia al principio lo que parecía decir es que el ordenador quedaba "convertido en un ladrillo". Releyéndola sí, más bien parece que el problema es que el windows no tira, pero al ordenador en sí no le pasa nada.

Retiro lo dicho.

[#29 Desactivado]

Tengo una sospecha: aquellos que no quieren pagar por Windows 10 pueden unirse al Windows Insider, que básicamente les envía a ellos los parches antes que al resto. ¿Serán éstos los que están siendo afectados?

[#81 f5inet]

#29 Hombre, si estas en el programa Insider sabes a lo que te expones.

[#97 Desactivado]

#81 Me expongo a que no me funcione el windows. Pero lo que se supone que dice el artículo es que jode el ordenador y que ya no arranca.

Por algo un poco menos grave (te sigue arrancando, pero en la práctica no puedes reinstalar ningún otro sistema operativo) casi crucifican a Canonical hace un mes.

[#99 f5inet]

#97 El ordenador te funciona. lo que no te funciona es el windows.
Metele un liveCD de linux, a ver si arranca...

[#23 Tronchador]

Este sí es por fin el año de Linux en el escritorio.

[#65 Desactivado]

#62 instalada pero no aplicada (no aplicaba hasta esta noche a no ser que seas del programa beta insider) te falta reiniciar, la mía estaba así y ya me estaba diciendo que reiniciase para aplicar los parches.

Además he estado investigando y los bloqueos son con los antiguos Athlon 64, Opteron y Sempron

[#12 Desactivado]

y zas!!!! Microsoft se carga la competencia de Intel

[#21 Jakeukalane]

A mí me daba cosa actualizar el kernel en mi Manjaro por la pérdida de rendimiento. No he notado nada de diferencia, eso sí, GNOME sigue gastando memoria como él solo... Ni Unity en tiempos de la 11.10... Quizás debería haber seguido con 32 bits.

[#33 neotobarra2]

Es muy grave lo mal que está gestionando Windows las actualizaciones de Windows 10. Algo tan importante en materia de estabilidad y seguridad... Y resulta que a muchísima gente le provocan más problemas las actualizaciones que dejar el equipo desactualizado.

Porque esto no es de ahora. Esto no ha pasado por primera vez con el parche de Spectre: lleva ocurriendo desde hace años, así que tampoco será ésta la última. Yo tengo mi equipo con Windows update deshabilitado desde que me apareció uno de esos problemas de reinicios cíclicos que no tuve cojones a solucionar de ninguna manera, y encima desde Microsoft answers me recomendaban formatear y reinstalar todo... Ahí fue cuando dije "¿Qué es lo peor que puede pasar si las desactivo? ¿Tener que formatear?"

[#7 mefistófeles]

Nos vamos superando

[#54 Desactivado]

Yo desde que actualicé se me traba hasta el ratón, y uso intel y nvidia (i7 6700k y 1080 gt, casi nada) .... con éso os lo digo tó.

[#55 A1234]

Por eso yo sigo en windows 8.1 y con las actualizaciones en modo buscar actualizaciones, pero permitirme decidir si deseo descargarlas e instalarlas. Dentro de un par de meses cuando ya se haya estabilizado esto a lo mejor actualizo.

[#88 acastro]

Típico de Microsoft. Si no tienes un problema no te preocupes. Nosotros te lo proporcionamos.
Hace falta ser bastante burros

[#18 Orgfff]

Tengo un AMD FX 6300 y ya se me ha congelado el PC tres veces desde la última actualización del 5 de enero. Inutilizado no, pero que me ha producido cuelgues que antes no ocurrían sí.

[#60 Desactivado]

#18 Windows se parchea siempre de lunes a martes, el 5 no era ni lunes ni martes

[#62 Orgfff]

#60 Lo que tú digas. Mira la imagen y fíjate en la fecha del parche KB4056892.

[#79 Desactivado]

#60 Hay uno en el foro con esa misma CPU diciendo que le pasan cosas raras, no tiene el problema del arranque pero hay cosas que le han dejado de funcionar y otro con un Threadripper 1950x de los nuevos que ni le arranca

Tienes aquí el hilo

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/after-installation-of-kb4056892-boot-failure-after/6c015632-2a45-4725-a882-f231f8c88f36?auth=1

[#67 Luarto]

En un AMD turion X2 64 me pasó lo mismo. La diferencia fue que pude regresarlo a un punto de restauración relativamente viejo y volvió a arrancar. Ese proceso lo hice 3 veces, la verdad no sabia que era por la actualización hasta que leí este post y bloquee el Windows update.
Raro que no le haya servido lo de los puntos de restauración a los del hilo..

[#91 MRamiro]

No quiero ser mal pensado, pero Microsoft tiene muchas acciones de Intel.

[#26 Rubier]

Se me ha instalado la actualización hace un rato y tengo un Ryzen 5 1600 y de momento sin problemas. Iré viendo.

[#61 Desactivado]

#26 solo afecta a los AMDs más antiguos, el 64, Opteron y Sempron

[#30 Desactivado]

Creo que es un "poco" sensacionalista si afecta a los Athlon, CPU que tendrá ya sus 15 años... últimamente intel y seguidores solo buscan noticias que les quiten culpa por medio del "salpicar".

[#16 juanlinux]

Pues oye, yo uso procesador amd con linux y windows, le instale el parche en windows 10 y va muy bien, así que vosotros sabreís lo que haceís, pero ami me va bien., quizás sean ordenadores precocinados desde fabrica, que vienen para utilizar el tiempo que dure lo que viene y en paz y no dejan tocar nada o es muy complicado, me refiero a algunos ordenadores hp que no dejan hacer nada y alguna que otra casa.

[#17 Desactivado]

#16 Yo tengo un pc rojo y tampoco me afecta. Recomiendo a los usuarios que tengan errores que pinten sus ordenadores para que les vaya todo bien.

[#20 sonixx]

#16 bueno el tema es que en la entrada ponen podrían, no leo litigias que huelen a sensacionalistas antes de entrar

[#28 Aokromes]

#16 en forocoches habia gente intentando instalar a mano el parche del meltdown en ordenadores amd, no me extrañaria que ese fuese el caso de esta "noticia"

[#34 fpove]

#16 De que color es la torre, creo que solo pasa con las violetas, las negras y blancas van bien.

[#47 Desactivado]

#16 a mi m ha fallado en un amd athlon II 6400+ pero revierte la actualizacion y acaba entrando pero lleva desde el dia 3 actualizándose y reiniciando.

[#59 Desactivado]

#16 He estado investigando y sólo afecta a las AMDs antiguos tipo Athlon 64, Opteron y Sempron