• AMD busca excluirse del parche de Kernel Intel VT, sus CPUs son seguras y el parche merma su rendimiento


    La inspección minuciosa de los parches del kernel revela un código que obliga a las máquinas que ejecutan cualquier procesador x86, sea Intel o AMD, a parchearse, independientemente del hecho de que los procesadores AMD sean inmunes. AMD busca que al menos el kernel de Linux incluya una línea de código como “(c-> x86_vendor! = X86_VENDOR_AMD)“, mientras que si el procesador usado no es AMD se marque como “X86_BUG_CPU_INSECURE“

    Leer en meneame.net | Noticia original

15 Comentarios

  1. Zeioth /  hace 1 año

    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.

  2. Unnhell /  hace 1 año

    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.

  3. Attanar /  hace 1 año

    Si entiendo bien la noticia, esto sólo afecta al rendimiento de procesos virtualizados, ya que no pueden acceder tan rápidamente a los recursos reales del ordenador.

    De ser así, es un problema que no tiene impacto real para los usuarios, sino para empresas que virtualizan software: Amazon, Microsoft, etc. principalmente, y a nivel más pequeño cualquier CPD de una empresa que use servicios de virtualización como VMWare.

    • deabru /  hace 1 año

      memoria virtual != máquinas virtuales.

      • Attanar /  hace 1 año

        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.

        • deabru /  hace 1 año

          Lo que te quería contestar es que el tema de las virtuales, de acceder a la memoria de otra máquina virtual, no es más que una consecuencia del bug. Hay otras, pero todo viene derivado de que un proceso pueda acceder a la memoria de otro proceso (o del sistema, en este caso)

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

          en.wikipedia.org/wiki/Virtual_memory

          The primary benefits of virtual memory include freeing applications from having to manage a shared memory space, increased security due to memory isolation, and being able to conceptually use more memory than might be physically available, using the technique of paging.

  4. perote /  hace 1 año

    Menudo culebrón o_o

  5. JCarlosCandela /  hace 1 año

    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%?

    • Kenzoryyy /  hace 1 año

      aun es muy pronto, es un fallo/estafa super grave, ya veremos que pasa :-S

    • Jakeukalane /  hace 1 año

      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.

    • mrpaco /  hace 1 año

      devuelves el procesador y te comes la placa?

      Los mas viejos del lugar, entre los que me encuentro, recordaran el escandalo FDIV que afecto a los Pentium 60 y 66, hace algo mas de 20 años, inicialmente Intel hizo comunicados minimizando el impacto del problema (quien quiera detalles es.wikipedia.org/wiki/Error_de_división_del_Intel_Pentium para no alargarnos mas).

      Tras salir publicadas demostraciones de las desviaciones en calculos en casos practicos Intel no tuvo mas remedio 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.

      • JCarlosCandela /  hace 1 año

        la placa no me la como porque tengo intención de comprar un intel de los nuevos cuando los rebajen estrepitosamente de precio.

        • mrpaco /  hace 1 año

          sera la placa compatible con el nuevo procesador?

  6. xiobit /  hace 1 año

    La parte buena para Intel es ya puede mejorar sustancialmente su próximo procesador, así campaña de marketing diciendo que su nuevo procesador mejora en un 50% el rendimiento. {0x1f602}{0x1f602}

  7. cucufatesan /  hace 1 año

    Primero los motores de explosión, ahora los procesadores de silicio. ¿Qué será lo siguiente? :troll:

  8. manolo_tenaza /  hace 1 año

    ¿Los procesadores de 64 bits están afectados?

    • frutosm /  hace 1 año

      Sí todos los de Intel desde hace 10 años.

      • manolo_tenaza /  hace 1 año

        :wall::wall::wall:

    • Protogenes /  hace 1 año

      En principio, que yo sepa, sí, los de 2007 hasta ahora.

    • nospotfer /  hace 1 año

      En el diff se ve que añaden estas dos funciones:

      static void __init pti_print_if_insecure(const char *reason)
      {
       if (boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
        pr_info("%sn", reason);
      }

      static void __init pti_print_if_secure(const char *reason)
      {
       if (!boot_cpu_has_bug(X86_BUG_CPU_INSECURE))
        pr_info("%sn", reason);
      }

      Lo cual supone un método para diferenciar CPUs "seguras" de las "inseguras".
      Leyendo un poco más el diff, vemos que se añaden 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)
      {
       char arg[5];
       int ret;

       if (hypervisor_is_type(X86_HYPER_XEN_PV)) {
        pti_print_if_insecure("disabled on XEN PV.");
        return;
       }

       ret = cmdline_find_option(boot_command_line, "pti", arg, sizeof(arg));
       if (ret > 0) {
        if (ret == 3 && !strncmp(arg, "off", 3)) {
         pti_print_if_insecure("disabled on command line.");
        return;
        }
        if (ret == 2 && !strncmp(arg, "on", 2)) {
         pti_print_if_secure("force enabled on command line.");
         goto enable;
        }
        if (ret == 4 && !strncmp(arg, "auto", 4))
         goto autosel;
       }

       if (cmdline_find_option_bool(boot_command_line, "nopti")) {
        pti_print_if_insecure("disabled on command line.");
        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.

      • Jakeukalane /  hace 1 año

        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%

  9. mcfgdbbn3 /  hace 1 año

    Sponsors of CPUgate. PAMMMMmmmmm… papam PAPAM.

    • kandalf /  hace 1 año

      ¿Tendrá relación con este tema, o será mas bien que amazon se quiere quitar de encima los micros 1151 "antiguos"?

      • BlueDeathScreen /  hace 1 año

        ni idea, sólo nuestro un hecho.

    • Harkon /  hace 1 año

      Na solo han bajado un poco, el 7700 valía 299 la semana pasada y ahora 296

    • timeout /  hace 1 año

      por lo que parece responde más a un hay que acabar con la 7ª generación para vender la 8ª

    • Arke /  hace 1 año

      Yo los veo al precio de siempre.

  10. sinjuice /  hace 1 año

    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

    • Franki15 /  hace 1 año

      Pero Intel no decide nada.

      • sinjuice /  hace 1 año

        Ya, no digo que decida, al igual que AMD no decide mucho, pero cada uno intentara presionar donde pueda.

        • Franki15 /  hace 1 año

          Presionar? Intel ha enviado su parche y AMD ha visto que afecta a sus CPUs y pide cambiarlo (tendrá que enviar un parche para parchear el parche :-D)

          • sinjuice /  hace 1 año

            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.

  11. Ze7eN /  hace 1 año

    Movimiento lógico por parte de AMD.

    • VladTaneev /  hace 1 año

      Hombre, es que la cagada de Intel es tan grande, que si realmente ellos no están afectados es de justicia que se reconozca.

      • Ze7eN /  hace 1 año

        Totalmente de acuerdo, y mira que yo llevo usando Intel casi toda mi vida.

        • VladTaneev /  hace 1 año

          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.

          • Franki15 /  hace 1 año

            Conocían? De dónde sacas eso? A que lleven 1 mes trabajando en un parche no lo llamaría "conocer"

            • Harkon /  hace 1 año

              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.

              • Franki15 /  hace 1 año

                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

                • Harkon /  hace 1 año

                  A ver como te lo explico, para diseñar un procesador que permite usar y acceder a direcciones de memoria hardware por la cara lo tienes que hacer adrede, no es un fallo, es intencionado y a sabiendas de las problemáticas que tiene tanto de seguridad como de estabilidad del sistema {0x1f609}

                  PD: que pronto se nos olvidan otros "fallos" como el dieselgate de Volkswagen

                  • Franki15 /  hace 1 año

                    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.

                    • dreierfahrer /  hace 1 año

                      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.

                      • Franki15 /  hace 1 año

                        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.

                        • dreierfahrer /  hace 1 año

                          hombre: si saben del bug y no lo arreglan....

                          Es bastante PUTA ESTAFA...

                    • Harkon /  hace 1 año

                      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.


                      www.reddit.com/r/pcmasterrace/comments/7nthay/a_quick_summary_of_the_c

                      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

                      www.meneame.net/m/actualidad/ceo-intel-vendio-mitad-acciones-mes-antes

                      Está 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.)

                      • Franki15 /  hace 1 año

                        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 ;)

                        • Harkon /  hace 1 año

                          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.

                          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.


                          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 ;)

                          • Franki15 /  hace 1 año

                            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.

                            • Harkon /  hace 1 año

                              pero como que no está confirmado si van a parchear todo AWS en 2 días y todo Azure el día 10? {0x1f602}{0x1f602}{0x1f602}

                              Como no te refieras a que no está confirmado si lo sabían... Y ni eso, vuelvo a repetir que para hacer que un procesador pueda acceder a memoria mediante direcciones hardware, o sin esos chequeos de seguridad, hay que hacerlo a conciencia sabiendo a los problemas de seguridad a los que te expones

                              • Franki15 /  hace 1 año

                                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...

                                • joffer /  hace 1 año

                                  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.

                                  • Franki15 /  hace 1 año

                                    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)

                                • Harkon /  hace 1 año

                                  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

                  • HortografiaKreatiba /  hace 1 año

                    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.

                      • HortografiaKreatiba /  hace 1 año

                        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.

                • w33d /  hace 1 año

                  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

                  • Franki15 /  hace 1 año

                    Ú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.

                    • Harkon /  hace 1 año

                      que el parche para las Linux ya está hecho y probado que no te enteras

                      • Franki15 /  hace 1 año

                        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.

                        • Harkon /  hace 1 año

                          La causa la sabemos todos los que sabemos como funciona la arquitectura de un procesador, a un "listo" se lo ocurrió saltarse la regla básica de dejar al procesador acceder directamente por hardware a direcciones de memoria sin ninguna comprobación de seguridad o con una seguridad ineficiente

                          Que dicen que no saben ni como explotarla? JAJAJAJA

                          Te dejo un video del ejemplo de ataque

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

                          Aquí explicado también

                          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.

                          pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-th

                          • Franki15 /  hace 1 año

                            Bug de Intel y me vienes con la randomización de direcciones. En fin, ya he visto el nivel. Aquí te dejo.

                            • Harkon /  hace 1 año

                              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.

                              siliconangle.com/blog/2018/01/02/intel-patches-critical-processor-secu

                              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

                            • Harkon /  hace 1 año

                              Hala, ahí lo tienes, tan simple como ejetutar tres lineas de comandos de sistema operativo ;)

                              twitter.com/brainsmoke/status/948561799875502080

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

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

                              twitter.com/pmoust/status/948567759708966917

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

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

                              34C3 - ASLR on the line

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

                • joffer /  hace 1 año

                  #9 Me está recordando a lo de Volkswagen y sus famosos test

              • callmewind /  hace 1 año

                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...

                • Harkon /  hace 1 año

                  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 ;)

                  • callmewind /  hace 1 año

                    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..

                    • Harkon /  hace 1 año

                      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

                      • callmewind /  hace 1 año

                        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.

                        • Harkon /  hace 1 año

                          Comunicado de AMD al respecto

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

                          En español aquí

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

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

                          Como dice otro usuario en la noticia

                          "el resumen es que no. De momento de las tres variantes del ataque AMD ha negado que sus procesadores sean 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."

                          • callmewind /  hace 1 año

                            ¿Pero qué acusación de intel? ¿te has mirado el paper original de Project Zero que son los que lo han sacado? googleprojectzero.blogspot.com.es/2018/01/reading-privileged-memory-wi
                            Son tres vulnerabilidades y al menos una afecta a AMD y ARM también. Y AMD puede decir misa si hay una prueba de concepto funcionando en sus CPU's. Otra cosa es que el parche para intel no sea necesario porque está hecho para otra de las variantes.

                            • Harkon /  hace 1 año

                              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 ;)

                              • callmewind /  hace 1 año

                                ¿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?

                                • Harkon /  hace 1 año

                                  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 ;)

                                  • callmewind /  hace 1 año

                                    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

                                    • Harkon /  hace 1 año

                                      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

                                      • callmewind /  hace 1 año

                                        Lo de volkswagen fue intencionado, no aplica aquí.

                                        • Harkon /  hace 1 año

                                          Es que lo que estoy diciendo es que fue intencionado, es decir, a partir de descubrir el fallo no querer arreglarlo, la única diferencia

                                          • callmewind /  hace 1 año

                                            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.

                                            • Harkon /  hace 1 año

                                              el Spectre ha salido a relucir a partir del fallo de Intel (meltdown), el segundo es mucho más sencillo detectarlo y reproducirlo el segundo ha salido precisamente porque se han metido al lio todos a buscar la manera de explotar el fallo, unas pruebas suficiente intensivas habría sacado a relucir el meltdown pero no el spectre que ha necesitado que toda la comunidad se vuelque en buscar posibles fallos. De hecho hay parche para el Meltdown porque los datos se han hecho públicos, para Spectre aún no hay fix pero no hay tanto riesgo porque es practicamente imposible de explotar (aunque claro, todo al tiempo)

                                            • Harkon /  hace 1 año

                                              Para que vayas abriendo boca de lo que opina Linus Torvals

                                              A competent CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.

                                              I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

                                              .. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

                                              Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

                                              Because if that's the case, maybe we should start looking towards the ARM64 people more.

                                              Please talk to management. Because I really see exactly two possibibilities: Intel never intends to fix anything OR these workarounds should have a way to disable them. Which of the two is it?


                                              Please talk to management. Because I really see exactly two possibibilities:

                                              - Intel never intends to fix anything

                                              OR

                                              - these workarounds should have a way to disable them.



                                              www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/

                                              • callmewind /  hace 1 año

                                                Tampoco entiendo para qué me pasas esto. No tiene nada que ver con la teoría que te inventas.

                                                • Harkon /  hace 1 año

                                                  Repite conmigo ;)


                                                  Please talk to management. Because I really see exactly two possibibilities:

                                                  - Intel never intends to fix anything

                                                  OR

                                                  - these workarounds should have a way to disable them.


                                                  Aquí tienes el mail original de Linus

                                                  lkml.org/lkml/2018/1/3/797

                                                  • callmewind /  hace 1 año

                                                    Preferiría que te ahorrases esos chascarrillos si quieres itentar convencerme de algo.
                                                    Linus está cabreado y con razón,porque intel echa balones fuera, y aun así no veo donde coincide contigo con tu teoría conspiratoria.

                                                    • Harkon /  hace 1 año

                                                      A ver qué te tengo que poner la frase exacta de nuevo?

                                                      - Intel never intends to fix anything

                                                      Que básicamente viene a decir lo que te he dicho antes, conocían el fallo pero pasaron de arreglarlo porque NUNCA lo hacen (hasta que no les queda otra porque los han pillado y ni con esas a veces)

                                                      Y Linus está cabreado porque no hacen otra que echar balones fuera, para variar

                                                      • callmewind /  hace 1 año

                                                        No, dice literalmente 'intel nunca intenta arreglar nada'. Obviamente es una exageración, porque intel sí ha arreglado bugs en otras ocasiones. El resto es cosa tuya.

                                                        • Harkon /  hace 1 año

                                                          Lo dice por algo, no crees? siempre es la misma historia, no hemos sido nosotros, no sabíamos nada, ahora balones fuera, que si un fix por software, puff ya cansa

                                                          • callmewind /  hace 1 año

                                                            Sí, lo dice porque siempre hacen lo mismo, cagarla, echar balones fuera. Creo que no lo dice porque el sepa al igual que tú, que han provocado ese fallo intencionadamente hace 20 años para sacar ventaja a la competencia. Pero si consigues otro mail de Linus que diga algo que se parezca remotamente a eso.. bueno pensaré también que Linus flipa.

            • dreierfahrer /  hace 1 año

              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...

            • Ainur /  hace 1 año

              La venta de acciones fue desde noviembre, si bien es cierto que el problema pudo pasar desapercibido hasta mediados del año pasado

        • HortografiaKreatiba /  hace 1 año

          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.

      • Oberlus /  hace 1 año

        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.

        • Arkhan /  hace 1 año

          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.

        • deabru /  hace 1 año

          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.

    • javicho /  hace 1 año

      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

Ofertas

Loader noticialalminuto

Volver arriba

Esta web utiliza cookies, puedes ver nuestra política de cookies, aquí Si continuas navegando estás aceptándola