Announcement

Collapse
No announcement yet.

Benchmarks Of Intel's Latest Linux Microcode Update

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

  • #11
    Originally posted by cybertraveler View Post

    Careful with that. Modern Intel processes shut down after about 30 seconds if they are not fed their microcode. I don't know if removing the microcode package will mean the kernel has no microcode to feed the processor. If you're not sure, it might be a better idea to pin the version of the intel-ucode package you currently have installed instead of removing the package altogether.
    Doesn't the motherboard firmware feed the CPU with a microcode at boot? Otherwise we'd have less than 30 seconds to set up the BIOS....

    Comment


    • #12
      Originally posted by tildearrow View Post

      Doesn't the motherboard firmware feed the CPU with a microcode at boot? Otherwise we'd have less than 30 seconds to set up the BIOS....
      hmm. You could be right. That would make sense.

      Perhaps Linux only replaces the microcode that the motherboard feeds the CPU if it has a newer version of the microcode.

      Comment


      • #13
        Originally posted by cybertraveler View Post

        hmm. You could be right. That would make sense.

        Perhaps Linux only replaces the microcode that the motherboard feeds the CPU if it has a newer version of the microcode.
        That's exactly what Linux does.

        Comment


        • #14
          there are lots of different parts running firmware in a modern Intel CPU.

          the one that is required to avoid spurious locks and reboots is IntelME, the part that normally is used for lights-out management but that Intel has been mission-creep into other tasks (helping with the bring-up, handling some DRM etc.), it doesn't even run on the main x86 core,but on a dedicated core that is running even if the CPUis shut down.

          Given its position (ouside the reachof the CPU, in charge of management), it's critical: the slightest bug and you're at risk of getting your computer hacked while off.

          Laptop/Desktop ma manufacturer like Dell have been making custom"de-fanged" firmware that just do the barely strict minimum to bring up the hardware without spurious reboots, and completely remove any networking component so that if you don't need lights-out management, your computer ins't at remote risk.

          The microcode is a different piece: Remember the over-simplified metaphore that modern Intel and AMD are a CISC instruction set running over a collection of RISC units ? In an over-simplified manner, the microcode is the thing in between, the "program" that tells which micro-ops to execute for a given complex x86 instruction.
          The CPU has already one built-in, just in order to be able run machine code.But since the infamous pentium bug, it's field updateable in order to be able to "patch around" CPU design flaws. The BIOS can overload a newer one, and later the OS can also load anewer one, but it's optional (and does't survive reboot).

          The Linux kernel can load one into the CPU from the ucode-* packages, if available. if not, you're left with whatever bugs came in your CPU from the factory.

          Comment


          • #15
            interesting to see how some KVM virtualized work loads i.e. Nginx performed better than bare metal dedicated

            Comment


            • #16
              Originally posted by tildearrow View Post
              I'm not upgrading my microcode.

              If they find one more vulnerability I am going to legitimately cry.
              All this "anti-microcode-update" movement is getting out of hand.

              You're the anti-vaxxers of the computing world, lol.

              Comment


              • #17
                Originally posted by flower View Post

                but why? microcode updates are not a bad idea.
                if it's just because of spectre i'd use a version before it was fixed (like me on my gaming pc)
                someone just said that microcode updates were hard to avoid, and they arent, im not telling people to do this, just how to do it if they want, thats why i put the quotes on fix

                Comment


                • #18
                  Originally posted by starshipeleven View Post
                  All this "anti-microcode-update" movement is getting out of hand.

                  You're the anti-vaxxers of the computing world, lol.
                  I just don't want to lose performance yet because I am working on projects that require enough performance to deliver their results in time, and yes, they do a lot of data transfer.

                  Comment


                  • #19
                    This 30 second rule sounds like bs.

                    Comment


                    • #20
                      Remember when people didn't use encryption on their wireless networks because it was slower? Same story all over again.

                      Comment

                      Working...
                      X