Announcement

Collapse
No announcement yet.

Linux 6.6 Unconditionally Enables x86 CPU Microcode Loading Support

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

  • #11
    Originally posted by PublicNuisance View Post
    Can anybody translate this for me ? How exactly would this change the Linux kernal ? Would it mean all closed source microcode would be loaded regardless of whether it's needed by the system ?
    No, it only means that the code for handling AMD and Intel CPU microcode loading is unconditionally part of the x86(-64) kernel. If it's not provided with any microcode to load, it won't do anything.

    To make it unconditional rather than a compile-time option as it is today, means a reduction in the maze of #ifdef macros, and reduces the testing matrix. Evidently they are thinking that that's worth more than a few kB of unused kernel code for those that don't need or want to load updated microcode.

    No more dangerous than allowing closed source code to do who knows what.
    That ship has already sailed, as the CPU is shipped with closed source microcode to begin with. The whole FSF RYF idiocy is just cutting off one's nose to spite one's face.

    To each their own. The libre kernel is optional so those who wish to use it can continue to and those that don't want it can continue not losing it. I never understand the hate it gets by people who can just choose to not use it. Having options is rarely a bad thing.
    Indeed, to each their own. The upstream kernel has no obligation to accommodate the linux-libre effort, but they are still free to modify the upstream kernel however they see fit, subject to the terms of the license.
    Last edited by jabl; 04 September 2023, 03:55 AM.

    Comment


    • #12
      Originally posted by stormcrow View Post
      You Chicken Littles need to learn a little reading comprehension. The pull request explicitly says "bare metal", as in not a virtual machine.
      There is no way to kill the kconfig option (which is the same for both bare metal and vm) and keep the firmware loading code out of vm kernels. Since they compiled the code unconditionally, it will be there for vms.

      Comment


      • #13
        Originally posted by jabl View Post
        That ship has already sailed, as the CPU is shipped with closed source microcode to begin with. The whole FSF RYF idiocy is just cutting off one's nose to spite one's face.
        My take on it, not that it's anything more than my opinion, is that whatever closed source firmware my hardware has baked in is there and isn't going away. It's bad but to me it would be worse to allow them to install even more closed source code down the road that could enhance any nefarious stuff they have going on. Everyone will find their own line in the sand. I want bug fixes and security patches but to get them I have to trust that companies, who have terrible track records , are only giving me bug fixes and security updates. It's a suspension of disbelief I can't muster.

        Comment


        • #14
          My 2 cents...

          No processor manufacturer will ever publish the sources of the firmware. It's just not only software, but in most cases, also contains part of the design of the hardware that overrides it's native configuration, and these are trade secrets, so there's no chance in H**L that this will be open. EVER. (Do you ever considered publish your IP address, your /etc/passwd and /etc/shadow files?? this would be the hardware equivalent of it.)

          The exeption would be AMD. This company will open some parts of it, but will keep sensitive parts closed. After all, security by obscurity is required in a world where web browsers are allowed to run code.

          ARM doesn't give a s***t about open source. Of it's licensors, only Samsung and Rockchip seems to care enough to pay external development to develop drivers for inclusion in the Kernel (E.g. Rockchip pays Collabora to develop open source drivers) but Rockchip themselves only cares about closed software and android, and Samsung only cares about android for 2 or 3 years, and then they will declare your expensive paperweight obsolete.

          Nvidia only cares for its entreprise users, and doesn't give a S**t about open source at all.

          My take: If you have a smartphone, and you still demand open firmware for your PC, you have far more bats in your belfry than you realize. You need to seek professional help.

          For the rest of us: Avoid Intel processors that have V-PRO enabled, since these are explicitally hardware spy enabled (like any smartphone out there). At least intel is quite honest in this aproach.

          Paranoid people can put an openwrt enabled router or pfsense enabled machine with a processor before the firmware era to feel more safe. And these people wants to avoid AMD notebooks with Pluton enabled hardware. And maybe avoid any of the ryzen 7000+ processors. who knows?

          Comment


          • #15
            Originally posted by rene View Post
            disappointing for those who want a minimal, non bloated kernel, ... :-/ even for VMs, ..!
            I'm sorry you feel the need to save 100 instructions in a 3MB kernel binary.

            Comment


            • #16
              Originally posted by PublicNuisance View Post
              Can anybody translate this for me ? How exactly would this change the Linux kernal ? Would it mean all closed source microcode would be loaded regardless of whether it's needed by the system ?
              All systems need microcode patches, if they exist. Unless you like your system crashing and bugging out.
              Originally posted by PublicNuisance View Post
              No more dangerous than allowing closed source code to do who knows what. To each their own. The libre kernel is optional so those who wish to use it can continue to and those that don't want it can continue not losing it. I never understand the hate it gets by people who can just choose to not use it. Having options is rarely a bad thing.
              As if your CPU didn't come with about 100x as much closed-source microcode burned into it. How do you feel about that closed source code? Any safer? It isn't.

              Don't like closed source microcode? Don't buy an x86 processor. That's 100% on you.

              Comment


              • #17
                Originally posted by jabl View Post

                Indeed, to each their own. The upstream kernel has no obligation to accommodate the linux-libre effort, but they are still free to modify the upstream kernel however they see fit, subject to the terms of the license.
                They're also free to run Hurd.

                Comment


                • #18
                  Originally posted by Developer12 View Post

                  I'm sorry you feel the need to save 100 instructions in a 3MB kernel binary.
                  It is more than 100 instructions, and a more than 3MB kernel. It is a trusted code base principal question and the last time I checked the AMD driver wasted 16MB or so of statically allocated microcode update buffer in its default configuration. Ask Amazon, Netflix, Google how they feel about that for their 100,000 servers ;-)

                  Comment


                  • #19
                    Originally posted by rene View Post

                    ...Ask Amazon, Netflix, Google how they feel about that for their 100,000 servers ;-)
                    I'd rather ask for a free server. I dont mind used 😁
                    Hi

                    Comment

                    Working...
                    X