Announcement

Collapse
No announcement yet.

Linux 6.6 Unconditionally Enables x86 CPU Microcode Loading Support

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

  • stiiixy
    replied
    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 😁

    Leave a comment:


  • rene
    replied
    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 ;-)

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • Developer12
    replied
    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.

    Leave a comment:


  • stargeizer
    replied
    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?

    Leave a comment:


  • PublicNuisance
    replied
    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.

    Leave a comment:


  • marios
    replied
    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.

    Leave a comment:


  • jabl
    replied
    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.

    Leave a comment:


  • stiiixy
    replied
    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. As for the "Libre" people, I doubt anyone in the upstream kernel care what that tiny number of absolutists will do. It's all a bit hypocritical and dangerous from a security perspective in my view.
    Make a statement, cherry pick a piece from the statement, and insult everyone whilst purveying your opinion.

    I've been 'demented' on linux (I pronounce it lie-nix, so there) since the nineties, and whilst I feel as if this might be a piece of 'news' being misrepresented, it is still certainly a piece that needs THOROUGH investigating and reporting on the concerns it carries.

    The security++ bandwagon has its limits also, especially when a lot of people already dont want these blobs (I personally accept them for now, but it is dwindling, and AI is 'getting there').

    We quite possibly may well be impacted at a level almost out of reach for the linux majority (ie non-dev, non-maintain, non-compile).

    My hackles are up, and they'll go down when they've been suitably redressed with facts and real information. Not your opinion.

    I mean no personal offence, but this is at a level where you just don't fuck around.

    Leave a comment:

Working...
X