Announcement

Collapse
No announcement yet.

Ubuntu 15.04 Will Attempt To Better Update CPU Microcodes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Adarion View Post
    [disclaimer: the following is as far as I understood]
    There might be better people here to explain but ?code is kind of a firmware that runs inside the CPU on a very low level. Some of that is only used during initialization, some might run all the time. Often APUs are more complex and include more functions than the pure computing unit but video decoders, encoders, USB controllers and so on, and you collect all that code under the label "firmware". Now the CPU comes with no or a firmware built in that is read every boot. Some obtain this from the BIOS at boot time. But there is also the option to give the CPU/APU an updated firmware (bugfixes, security issues, enhanced performance and so on) - and the operating system's kernel can offer a more recent firmware to the CPU. If the CPU accepts this newer blob should then be loaded and executed.
    The downside is - it is still a proprietary blob. And: Today the often have a crypto signature, so you can't load your own firmware - unless you have the key. Which you haven't.
    The pro side is that no malware can load itself at lowest level and live inside the CPU and do nasty stuff from there. The con side is: No freedom firmware, no own firmware, you have to live with what the CPU manufacturer provides you. You also do not have control over this. That means: Firmware/Microcode runs at lowest level, can achieve SMM (!) and this way phone home totally transparent to you, your OS and your anti-malware solution. It is like somebody stops time and exchanges the chair you sit on (under your ass! ) and puts a new chair there. And you will not notice it. Also this firmware can limit the functions of your CPU. Nvidia and intel are actually doing this or at least planning to do so. Intel wanted to sell CPUs and you had to pay extra to "release" certain functions or better speed. Nvidia might pretend the GPU to be a newer model but it is just an ooold chip rebranded. Or limit GPU functions. (The 3.5 GB desaster was hardware, though )
    Thanks for the answer. A last question: code updating affects bios or operating system? Is there a way to update bios bios code by hardware peripherals code so to avoid pci unknown device issue during POST, though ACPI and APIC demands to operating system device management in modern systems?

    Comment


    • #12
      Originally posted by Azrael5 View Post
      Thanks for the answer. A last question: code updating affects bios or operating system? Is there a way to update bios bios code by hardware peripherals code so to avoid pci unknown device issue during POST, though ACPI and APIC demands to operating system device management in modern systems?
      crisb explained it better

      cpu microcode does not affect anything but the cpu
      not that you will notice anything different after it is "updated"

      how it works is that the kernel module "microcode.ko" checks /lib/firmware/ for microcode, then uploads it to the cpu



      for updating bios i think i used flashrom once
      the recommended way from the motherboard vendor might be a smarter plan
      (like mine has a way to flash by putting a file on a stick then choosing to update in bios)

      Comment


      • #13
        Originally posted by Espionage724 View Post
        Are microcode updates temporary or permanent? Or I guess a better question; do they just affect the running session, or does it persist after reboots?

        I heard a while back that Intel was distributing microcode updates to prevent overclocking on certain processors that some motherboard vendors unlocked; not sure how true that is, but as to how concerning it might be might depend on the above.
        They are applied on boot, either by BIOS/UEFI or by the kernel.

        Comment


        • #14
          Originally posted by Oedner View Post
          "The microcode data file ... will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system."
          Here on Fedora 21 I don't have a /etc/firmware folder.

          Comment


          • #15
            Originally posted by gens View Post
            crisb explained it better

            cpu microcode does not affect anything but the cpu
            not that you will notice anything different after it is "updated"

            how it works is that the kernel module "microcode.ko" checks /lib/firmware/ for microcode, then uploads it to the cpu



            for updating bios i think i used flashrom once
            the recommended way from the motherboard vendor might be a smarter plan
            (like mine has a way to flash by putting a file on a stick then choosing to update in bios)
            Ok thanks, so this operation concern with linux kernel replacing bios information by microcode newest CPU's microdata without any firmware bios involvement.

            Comment


            • #16
              Originally posted by mark45 View Post
              Here on Fedora 21 I don't have a /etc/firmware folder.
              /lib/firmware

              Comment


              • #17
                Originally posted by Azrael5 View Post
                Ok thanks, so this operation concern with linux kernel replacing bios information by microcode newest CPU's microdata without any firmware bios involvement.
                BIOS has nothing to do with this

                Comment


                • #18
                  Package cryptokey more reliable than CPU/firmware key for security

                  Originally posted by Adarion View Post
                  I thought that was a matter of the kernel. But then I am gentoo and compile my own kernels and put everything right in. I have few modules and never had an initrd (what is that good for anyway ). And I mean, what means "better microcode updates"? You can probably ship the latest blob and maybe somehow improve loading at kernel boot time but the microcode itself is a blob provided by the CPU vendor so you can't really change much about it. And a lot of CPUs/APUs today even want this one crpytographically signed, for mixed reasons. :/
                  There have been documented efforts be security agencies to get control of Windows machines by replacing firmware updates with their own. Since Windows cooperates with them and they have Windows keys this is easy, If your distro does not provide them with a key they have a much harder time getting into your Linux machine this way-UNLESS you accept a "linux-firmware" update when your package manager complains about an invalid signature.

                  The CPU firmware signing key is not to be trusted against the NSA. It's possible that Intel will refuse to provide it in the post-Snowden era for business reasons, just as Google claims to be encrypting data against the NSA while selling it to everyone else. It's also possible that the wealthy corporate bosses at Intel (like at Shell, etc) see the NSA as part of the military and the military as their own security force. Even if they have clammed up for a while, that will only last until the next terrorist strike anywhere in the world where encryption can be plausably blamed for assisting the attackers.

                  By comparison, if Canonical got caught givng GCHQ signing keys for Ubuntu packages, that would be the end of Ubuntu and everyone knows it. Even Red Hat could not afford this kind of fallout, while Microsoft's rather different end user base tolerated the Windows 2000 NSA key revelation with barely a whisper. When it REALLY counts (Snowden, etc) and performance is acceptable with the firmware that came on the CPU's ROM, it makes sense to use the firmware that came on the CPU assuming that was sourced randomly with cash. Below the Snowden level, everyone should refuse to install unsigned firmware packages if their distro normally signs packages.

                  As for that CPU firmware: we know damned well that Intel is not to be trusted with something like Boot Guard, even though for a lot of us the true "turtles all the way down" level of security would be a chip fabbed ourselves from an open source design on a some kind of descendant of 3-d printers, only accepting firmware signed with our own keys and locked to our own bootloaders or kernels. The problem then becomes the printer that fabs the CPU...

                  Comment


                  • #19
                    Originally posted by Luke View Post
                    As for that CPU firmware: we know damned well that Intel is not to be trusted with something like Boot Guard, even though for a lot of us the true "turtles all the way down" level of security would be a chip fabbed ourselves from an open source design on a some kind of descendant of 3-d printers, only accepting firmware signed with our own keys and locked to our own bootloaders or kernels. The problem then becomes the printer that fabs the CPU...
                    Printer? We should all be carving our own CPUs out of silicon with dental picks!

                    Comment


                    • #20
                      Originally posted by Adarion View Post
                      The con side is: No freedom firmware, no own firmware, you have to live with what the CPU manufacturer provides you. You also do not have control over this. That means: Firmware/Microcode runs at lowest level, can achieve SMM (!) and this way phone home totally transparent to you, your OS and your anti-malware solution. It is like somebody stops time and exchanges the chair you sit on (under your ass! ) and puts a new chair there. And you will not notice it. Also this firmware can limit the functions of your CPU. Nvidia and intel are actually doing this or at least planning to do so. Intel wanted to sell CPUs and you had to pay extra to "release" certain functions or better speed. Nvidia might pretend the GPU to be a newer model but it is just an ooold chip rebranded. Or limit GPU functions. (The 3.5 GB desaster was hardware, though )
                      Well, for me just to understand, I guess this "con" side would exist also without the possibility to install/update the microcode through the OS, I mean also by just upgrading the BIOS: or before these microcodes weren't used at all and it's all a new thing? From my noob POV, SMM malware hacks remind me of a badUSB nightmare... just there's nothing to do about. Also wondering: will there be more "libre" machines available (like gluglug) in the future or because of these microcodes there won't be any (I'm pretending they'll always be proprietary blobs)?
                      Probabling hoping in further development and for personal use availability of the Loongson CPUs is just utopia

                      Comment

                      Working...
                      X