Announcement

Collapse
No announcement yet.

Ubuntu 15.04 Will Attempt To Better Update CPU Microcodes

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

  • #21
    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 )
    Hi Adarion,

    This is as my own understanding, but after consideration it seems as though μcode would result in processing overhead (ie, for fma, ignore the three least significant digits). I'm not sure this is the case, however.

    Comment


    • #22
      Originally posted by horizonbrave View Post
      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
      Microcode is around since Pentium Pro i think? CPU updates are are signed so there shouldn't be issues with malware.
      Also - if you don't trust chip manufacturers with their microcode why trust them at all? There are known cases of chips with weird security holes and sometimes even clear backdoors.
      Even better - sometimes you get counterfeit chips that have a cpu inside emulating functions of original chips - like in the case of FTDI usb-serial converters.

      Full Libre machines would be possible essentialy only with Open Source chips. With the rest - there always could be something inside

      Comment


      • #23
        Originally posted by Marc1n View Post
        Full Libre machines would be possible essentialy only with Open Source chips. With the rest - there always could be something inside
        Thanks God for that!

        Seriously, we've had upgrade-able microcode (on both CPUs and GPUs) for many generations now. Some people need to take their heads out of the 'but it's not open!' sand. The notion that all IHVs are inherently malevolent, and we will somehow overcome them by using only open-source software is beyond naive.

        Comment


        • #24
          Hmmm, CPU microcode updates handled by Linux.

          Where are the open source hardliners on this? Just imagine the cheek of Intel - binary blobs for linux!!!

          When can I expect to see an effort to provide complete and unencumbered open source GPL compliant CPU microcode for Intel processors?

          (for the sarcasm impaired people: this post is a troll)
          Last edited by hoohoo; 16 March 2015, 04:13 PM.

          Comment


          • #25
            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.
            Permanent. Modern Intel CPUs (and AMD also I assume) are RISC-like at the silicon level: the CISC x86 instruction set is supported by the silicon running code ("microcode") which implements x86. This was first implemented in the mid-1990's. So the x86 instruction set is executed at one remove from the silicon. As such if Intel discovers a bug in the x86 instruction set for one of it's CPUs then generally the bug could be corrected by modifying the microcode.

            Probably microcode can control other aspects of the CPU, like what you describe, but I don't know the details well enough to say yes or no.

            Comment


            • #26
              Are you sure about the updates being permanent ? My understanding was that they were soft-loaded into a CAM (content-addressable memory) which patched the permanent microcode in the CPU.
              Test signature

              Comment


              • #27
                Originally posted by bridgman View Post
                Are you sure about the updates being permanent ? My understanding was that they were soft-loaded into a CAM (content-addressable memory) which patched the permanent microcode in the CPU.
                Your understanding is correct:

                Secure your applications and networks with the industry's only network vulnerability scanner to combine SAST, DAST and mobile security.

                and finally I see this every time I reboot my PC (AMD Athlon II x3) :
                Code:
                [    3.527444] microcode: CPU0: patch_level=0x010000b6
                [    3.530880] microcode: CPU0: new patch_level=0x010000c8
                [    3.530900] microcode: CPU1: patch_level=0x010000b6
                [    3.530908] microcode: CPU1: new patch_level=0x010000c8
                [    3.530917] microcode: CPU2: patch_level=0x010000b6
                [    3.530925] microcode: CPU2: new patch_level=0x010000c
                So either my BIOS downgrades the microcode each time[*] or it's not permanent.


                [*] Which can't be. Well, this is for intel but anyway:
                Code:
                The microcode revision is an incremental version number - you can only successfully apply an update if the current
                microcode revision is less than the revision supplied.
                (Source: http://inertiawar.com/microcode/ )

                Comment


                • #28
                  Originally posted by bridgman View Post
                  Are you sure about the updates being permanent ? My understanding was that they were soft-loaded into a CAM (content-addressable memory) which patched the permanent microcode in the CPU.
                  I could be wrong about permanent. I thought they were persistent across reboots, and I was calling that permanent.

                  Comment

                  Working...
                  X