edición general
241 meneos
3733 clics

Correo de responsable de AMD a los desarrolladores del kernel Linux [ENG]

Los procesadores AMD no están sujetos a los tipos de ataques que el kernel la característica de aislamiento de la tabla de página protege contra. La microarquitectura de AMD no permite referencias de memoria, incluidas referencias especulativas, que acceder a datos privilegiados más altos cuando se ejecuta en un modo privilegiado menor cuando ese acceso daría como resultado un error de página.

| etiquetas: amd , problema pti , kernel , linux
Comentarios destacados:              
#10 Por actualizar el resumen que parece ser que se sabe ya un poco más:

1) Intel afectada de los 3 casos.
2) AMD de uno, el menos malo y el que menor impacto tiene.
3) ARM de uno, el menos malo y el que menor impacto tiene.

A nivel de usuario, aplicando el parche y punto. No hay grandes diferencias.

En servidores es una gran cagada con consecuencias muy serias.
  1. No he entendido un pimiento, pero meneo. (Me he encontrado una Woll damm escondida en el fondo de la nevera) :-)
  2. #2 Cerveza mañanera, la mejor compañera. Salud.
  3. Tiene pinta que Intel quiere minimizar el problema diciendo que es de todos.

    Lo cierto es que los procesadores Intel van a perder un 30% de rendimiento.
  4. #2 Imagino que ya ha dejado de estar "Voll" :-D
  5. #5 Probablemente pierden más, dependiendo del escenario. Las pruebas preliminares hablan de un 7-30%, pero es que se hicieron benchmarks demasiado genéricos. En el hilo sobre el parche se habla de caídas generalizadas de doble digito en el rendimiento en entornos de virtualización y paravirtualización, mayores cuantas más VMs haya en ejecución.

    Súmale a esto que la virtualización enterprise está prácticamente comida por Intel, por lo que imagínate la leche... azure, google cloud, aws, todo aquello que corra sobre k8s o openstack. Incluso docker.
  6. #2 Básicamente, que sus procesadores no sufren de ese "pequeño problema" que es que un proceso quiera acceder a zonas de memoria a las que no tiene permiso, incluso "probando al azar", y se le permita dicho acceso, sino que en tal caso salta un error de acceso a memoria como está mandado.

    Sé que ahí hay un chiste malo mezclado con el procés, pero dejo el calzador a otro.
  7. /* Assume for now that ALL x86 CPUs are insecure */
    Trolleo del güeno :troll:
  8. #11 ¡No lo había visto! Lo bueno es que en el patch del patch, los de AMD han quitado esa línea diligentemente :-D
  9. #0, no es buena idea poner la entradilla traducida directamente de Google :palm:
  10. Lo ha traducido M. Rajoy: Los procesadores AMD no están sujetos a los tipos de ataques que el kernel la característica de aislamiento de la tabla de página protege contra.
  11. #6 (Dale al me gusta si entiendes el alemán) :-D
  12. #16 Hombre blanco habla con lengua de serpiente.

    D.E.P. Javier Krahe
  13. Quien ha escrito esa entradilla?
  14. Mandas un correo de hace 1 semana justo hoy que se ha conocido que los procesadores de AMD sí están afectados?
  15. Me encanta ver directamente la lista de correo del kernel en Meneame :-)

    Para quien no entienda un carajo, aclarar que esto simplemente indica que en la última revisión del kernel de Linux los procesadores AMD no se ven afectados por la ralentización que provoca el workaround a la madre de todos los bugs de hardware.

    Alguien de AMD ha subido un parche, y el gran jefe indio Linus lo ha aceptado y mezclado con la rama principal.
  16. #1 No es lo mismo un comunicado que un parche para el kernel de linux que deshabilita las "medidas especiales" si la CPU es AMD.

    Vamos, en lugar de mandar al que escribe las notas de prensa AMD ha mandado a un desarrollador que se ha dejado de gilipolleces y ha zanjado el asunto con 4 líneas de código.
  17. #21 están afectados por Spectre, no por Meltdown. Este parche quería meter el workaround de Meltdown en todas las CPUs x86.
  18. #9 Tanto en los micros de Intel como en los AMD salta el error de acceso a memoria. La diferencia es que en los AMD salta antes siquiera de intentarlo, y en los Intel salta después, cuando se va a escribir el resultado de la instrucción. Y en este caso, aunque la instrucción no llegue a completarse, queda guarrería en la caché que permite determinar lo que allí había.
  19. #17 más bien tiene pinta de que lo ha traducido su primo:

    www.youtube.com/watch?v=CiUAovbXtwU
  20. #5 Perdón por el calzador, pero es que la excusa de intel me suena al PP diciendo que "la corrupcion es cosa de la sociedad y por eso ningun partido se libra" xD
  21. #28 jajajajaja
  22. #12" Exclude AMD from the PTI enforcement. Not necessarily a fix, but if
    AMD is so confident that they are not affected, then we should not
    burden users with the overhead"
    Tiro directo en la linea flotación intel. xD
  23. #3 Lamento hacer un comentario de nazi gramatical pero es por lo menos la tercera vez que leo en este asunto que "AMD jura y perjura...", así que supongo que no es algo puntual.
    Perjurar es jurar en falso, y es incorrecto el uso de esta palabra para hacer énfasis en que se está jurando algo, ya que de hecho al hacerlo así se está diciendo que el juramento no tiene validez.

    De nuevo, perdón por mi cuñadismo, y que conste que es con mis mejores intenciones.
  24. #33 Sacado de la RAE:

    perjurar

    Del lat. periurāre.

    1. intr. Jurar en falso. U. t. c. prnl.

    2. intr. Jurar mucho o por vicio, o por añadir fuerza al juramento.

    3. prnl. Faltar a la fe ofrecida en el juramento.
  25. #33 Me pasa lo mismo. Me chirría esa expresión cada vez que la oigo.
  26. #33 Pero es que se trata de una frase hecha, pese a estar de acuerdo con tu explicacion.
    "Jura y perjura" viene a decir que se está afirmando algo de todas las formas posibles.
    Algunas variaciones de esto (y algunas con errores similares a lo que comentas, no dicen exactamente lo que pretenden) serían:
    - Por activa y por pasiva.
    - Por lo civil o por lo criminal.
    - cienes y cienes de veces.
    - así me parta un rayo si miento.

    etcétera ^^

    Edit: Ojo, y todo esto sin acritud ninguna (para una cosa que me sé, pues voy y la cuento :-D)
  27. #34 Me la como, aunque huele de lejos a que lo de añadir fuerza viene de la introducción estilo "aceptamos barco" del mal uso, pero registrado en la RAE como tantas cosas al ser un uso real de la lengua viva.
    Basta ver que es contradictorio con el significado principal que comentaba, y que viene casi asociado a jurar por vicio es decir, al mal uso del juramento.
  28. #10 mm, que yo sepa AMD está afectado de Spectre 1 y si tiene solución por parche sin perdida de rendimiento.

    Luego ARM está afectada (en los últimos cortex-A) en Spectre 2. AMD aquí está "afectada" entre comillas pero no de manera aplicable para realizar un ataque (el atacante tendría que conocer las abreviaturas del BTB, cosa que no es predecible en AMD (y si en Intel y ARM), al menos no por ahora.

    Meltdown (la más grave) afecta solo a Intel (a la que afectan también spectre 1 y spectre 2)
  29. #36 No veo los casos iguales:
    Por activa o por pasiva quiere decir de todas las maneras, sin ser palabras excluyentes sino que amplían el ámbito de acción. Lo mismo para civil o criminal.
    Cienes de veces no tiene nada de raro salvo que está en desuso la palabra "cienes", se suele utilizar "cientos" pero sigue siendo correcta.
    El rayo ni lo veo relación, sólo es una frase hecha que enfatiza la convicción del hablante casi como si se apostara su vida (aunque sabemos que el rayo no va a caer si pierde).
    En el caso de "juro y perjuro..." sin embargo el significado sería "juro y miento al hacer el juramento que..." se utiliza como énfasis pero el significado que hay detrás es contradictorio.
    Como pone #34 este uso que sigo viendo contradictorio está no obstante registrado en la RAE.
  30. #37 Originalmente la frase se usaba cuando alguien ponia mucha insistencia en una mentira.
  31. #39 "Cienes de veces no tiene nada de raro salvo que está en desuso la palabra "cienes", se suele utilizar "cientos" pero sigue siendo correcta."

    Pues a mi esa frase me la ha dicho mi madre cienes y cienes de veces :-D :-D :-D
    ...y así me parta un rayo si miento!

    (perdón, no lo he podido resistir, ya paro :shit: )
  32. #33 Bien traído y necesario. Menéame te informa, Menéame te enseña.
  33. #31 las actualizaciones son automáticas.

    Firefox funciona como un tiro y libre Office igual que en Windows o mejor. No, realmente va mejor (aunque ni se acerca al MS office, que le da mil vueltas).

    La grabadora, la tarjeta de sonido, y todo lo demás funciona perfecto. Excepto los juegos (cosa que a mi me la pela).

    Ponte una Ubuntu. No necesitas saber programar.
  34. #45 Yo tengo el FX-8350 4ghz 8 cores y estoy muy contento.
  35. #3 AMD dice q no es vulnerable a Meltdown (la vulnerabilidad del parche), que una variante de Spectre no está demostrado que le afecte y que es vulnerable a otra (que según dicen hay que parchearla por software).
    Eso es lo que dice en su comunicado.
  36. Te habrás quedado a gusto pasando la entradilla por el traductor. Madre de cristo, qué redacción más penosa.
  37. #5 En efecto, a parte de cual sea el % de perdida de rendimiento de aplicar esta CHAPUZA para paliar meltdown, hablemos claro:

    En lo que respecta al apartado tecnico, chapo a los investigadores; pero ( there's always a but, isn't there ? ), en lo no tecnico, entendidas las tres variantes ( dos primeras = spectre y tercera = meltdown ) y visto el advisory, articulos, etc., lo tengo claro:

    - intel ha metido mucha pasta aqui, y eso, ojo, no es malo, es pasta merecida y pasta necesaria
    - spectre, las dos primeras variantes, con lo que sabemos, no se acercan ni de lejos a meltdown, tercers variante. La chicha gorda, riesgo e impacto del arreglo ( una CHAPUZA que hace sentirse sucio a cualquiera que entienda lo que hace ) esta en meltdown, del que solo intel adolece y, ya veremos, del que parece que han sacado ventaja por no aplicar los pertinentes chequeos. A ver como cambia el IPC de los micros que arreglen esto en hardware, podria haber sorpresas.
    - parece que esas dos variantes primeras, spectre, son algo metido para poder hacer totum revolutum y decir que "AMD tambien". NO, AMD NO, aqui el resumen es que hay dos cosas que no son mucha cosa ( cache side channel attacks en kernelmode ) y son faciles de paliar sin mucho trauma y luego esta el asunto real, meltdown, que es no chequear privilegios ANTES del acceso a memoria en ejecucion especulativa; intel lo hace, AMD NO.

    Con todo esto, leyendo y viendo la suavidad con la que se ha hecho todo, incluido el advisory y muchas publicaciones y viendo este totum revolutum y demas:

    Damage control, orquestado con tiempo.

    Al final, uno de los pocos que ha puesto la cosa en balance con franqueza, el señor Torovoltos.
  38. #25 "Intel Inside" es solo un eslógan comercial, no un modelo ni una familia de procesadores.

    Te quedan cosas por aprender, pero ánimo, con paciencia todo se consigue.
  39. #22 Como tocaba.
  40. #31 Si sirve para que te animes a probar, te diré que aunque ya había probado Linux antes, se convirtió en mi S.O. habitual "gracias" a una grabadora de CD's de HP que era una p*t* mierda bajo Windows.

    Y de esto hace unos 20 años.
  41. Para copypastear del translator esa entradilla, yo me habría estado quieto. O habría escrito alguna frase aleatoria en castellano, habría tardado menos y no habría quedado tan mal.
  42. #12 Mientras no lo consigan en Windows no se salen con la suya, que el So mayoritario
  43. #31 Es sólo para probar (con todas las funcionalidades, pero eso si, a velocidad usb/dvd, que puede ser un tanto lento comparado con un ssd o un disco duro y una instalación normal, salvo que realices una instalación en tu propio disco o en una máquina virtual, claro). El hard tiene que ser muy muy nuevo y/o de algún fabricante raro para que no esté soportado sin instalar nada, al menos en las distros más populares (tipo ubuntu).

    Evidentemente, se arranca desde un dispositivo que no es el disco duro, tu windows sigue ahí sin tocar (una vez más, salvo que instales en paralelo junto al windows, donde no se toca el windows pero si se mantiene ahí o si lo haces en una máquina virtual, que al fin y al cabo no es más que un fichero gordo) y los cambios no son permanentes, son "una sesión" por así decirlo.

    La programación no es necesaria para probar ni para usar linux en el día a día (mucha gente lo usa para cosas básicas sin tener ni puñetera idea de informática, así en general). La ventaja de linux es que tienes todo a mano para si en algún momento te interesa puedas hacerlo, si quieres compilarte, examinar, jugar y manipular tú mismo cualquier aplicación que esté en sus repositorios (el propio kernel incluído) puedas hacerlo.

    El positivo es probarlo por ti mismo y ver si de alguna manera puede ganarse un hueco en tu vida.
comentarios cerrados

menéame