Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 57

Thread: openSUSE without kernel binary blobs?

  1. #11

    Default Re: openSUSE without kernel binary blobs?

    So similar to what I would prefer Intel also says that the "normal preferred method to apply microcode updates is using the system BIOS" adding that it "can be done at runtime using the operating system". Then the question transforms to: why don't we do it the way the manufacturer recommends and why does the distro use the other way, instead of recommending the recommended one?

    Quote Originally Posted by susejunky View Post
    "... The downside of removing proprietary firmware from the kernel is that it will cause loss of functionality of certain hardware that does not have a free software replacement available ..."
    Doesn't that also contradict the recommendation of the manufacturer? If it is possible to do it once throug the BIOS, why should the OS do it on every boot?

    Yet i didn't dare to test how my Intel CPU does without its microcode.
    Are you saying that your CPU may not work without the microcode provided by the distro? Makes no sense.

  2. #12
    Join Date
    Sep 2014
    Location
    Germany
    Posts
    332

    Default Re: openSUSE without kernel binary blobs?

    Quote Originally Posted by heyjoe View Post
    Doesn't that also contradict the recommendation of the manufacturer? If it is possible to do it once throug the BIOS,
    Updating the firmware/microcode of a device via BIOS/UEFI implies installing a (new/updated) BIOS/UEFI which includes the updated firmware. Is that correct?

    Who should provide all those new/updated BIOSs/UEFIs?

    If firmware updates had to be done exclusively via BIOS/UEFI then - on every required firmware update - the manufacturer (of the device to be updated) had to contact all motherboard manufacturers who sell (and once sold!) boards which can handle that specific device, hand them over the new firmware and ask them to update their BIOS/UEFI for the boards in question and to provide these new/updated BIOSs/UEFIs to their customers.

    I can recall at least three intel microcode updates within the last twelve months (and my system contains several more devices which make use of firmware which in turn gets updated more or less frequently) so i can't believe that updating firmware/microcode exclusively via BIOS/UEFI would work.
    Quote Originally Posted by heyjoe View Post
    ...Are you saying that your CPU may not work without the microcode provided by the distro?
    No! I said: I have not tried to run my system without the CPUs microcode (and i certainly never will because i do not want to make my system vulnerable to known CVEs which intel fixed by microcode).

    Nevertheless i would be very interested to know how a system performs without the CPUs microcode. So if you do have any practical experience in this please share it here.

    Regards

    susejunky

  3. #13

    Default Re: openSUSE without kernel binary blobs?

    Quote Originally Posted by susejunky View Post
    Updating the firmware/microcode of a device via BIOS/UEFI implies installing a (new/updated) BIOS/UEFI which includes the updated firmware. Is that correct?
    I don't know. I am reading what Intel writes and asking.

    Who should provide all those new/updated BIOSs/UEFIs?
    Assuming that the answer to the above is "yes" (and I don't know if such assumption is correct for microcode in particular) that should be the motherboard manufacturer.

    If firmware updates had to be done exclusively via BIOS/UEFI then - on every required firmware update - the manufacturer (of the device to be updated) had to contact all motherboard manufacturers who sell (and once sold!) boards which can handle that specific device, hand them over the new firmware and ask them to update their BIOS/UEFI for the boards in question and to provide these new/updated BIOSs/UEFIs to their customers.
    I don't read anywhere "exclusively". I read "recommended". Also what you explain may be incorrect. To my mind the CPU manufacturers should publish updated microcode, the MB manufactuers should download it and update BIOS/UEFI accordingly, and the end user should in his turn follow the updates of the MB manufacturer. I.e. - nobody should "contact" anyone, just like nobody contacts me to update the version of openSUSE.

    I can recall at least three intel microcode updates within the last twelve months (and my system contains several more devices which make use of firmware which in turn gets updated more or less frequently) so i can't believe that updating firmware/microcode exclusively via BIOS/UEFI would work.
    My understanding is that firmware resides in ROM, i.e. needs to be written only once, not on every boot. Then it is read and executes on every boot. So it confuses me to read the replies here which imply that firmware is (in some way) ran by the OS on each boot. Please someone correct me if I am wrong and clarify.

    I have not tried to run my system without the CPUs microcode (and i certainly never will because i do not want to make my system vulnerable to known CVEs which intel fixed by microcode).

    Nevertheless i would be very interested to know how a system performs without the CPUs microcode. So if you do have any practical experience in this please share it here.
    Perhaps you mean the microcode *updates*. I don't think it is possible to run the CPU "without the microcode" (as in completely without any microcode) because of what it is and the way it works.

    I still hope to get answers to my initial questions.

  4. #14
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,343

    Question Re: openSUSE without kernel binary blobs?

    Quote Originally Posted by heyjoe View Post
    But why? If I want to update my BIOS - I download the update and do it myself. Same for SCSI controller or whatever. Why should the CPU be any different? IOW: why should the distro be a mid-man? I mean - I not that I do or don't mind, just want to know why this is made to be like that.
    Unfortunately or, maybe fortunately, the microcode which is loaded at boot-time has to be packaged for the operating system in question.
    • CPU manufacturers and the manufacturers of other devices which need to be loaded with microcode have absolutely no interest in packaging their microcode on a per Operating System basis – they only supply the code to be loaded to the device at boot time and, leave the implementation of the driver needed to do just that up to the Operating System maintainers …


    Quote Originally Posted by heyjoe View Post
    How to the so called "Libre" distros run without all that? Are they any worse?
    As pointed out in other replies here, there are devices which absolutely need microcode to be loaded at boot time – in other words the hardware running the “Libre” distribution doesn't behave as expected …

    Quote Originally Posted by heyjoe View Post
    Again - how come "Libre" distros work without that?
    I suspect the system behaviour at run-time isn't really that which could be expected of the hardware platform in question …

    Quote Originally Posted by heyjoe View Post
    Also - I certainly don't flash my BIOS on each boot. And I would be definitely concerned to find out that a firmware-level updated can come through the OS update. I have never thought that the OS would touch anything below Ring 0. Is that something new?
    No it's not new; AFAIK firmware and microcode have been around since about 1975 – in Mini-Computers – before the IBM-PC was brought to market …
    • Just a thought, does anyone know if the Commodore PET, Radio Shack TRS-80, BBC Micro and, the Apple I (all pre IBM-PC) had firmware and/or microcode?

    I suspect, yes …

    BTW, I'm not suggesting that, Charles Babbage's “Analytical Engine” (1837) and the code written for it by Ada Lovelace (1843) offer an initial insight into the reasons why firmware and microcode are in fact a good idea …


    Quote Originally Posted by heyjoe View Post
    Sorry if these questions sound dumb.
    No, they're not dumb.
    In fact, I find it quite refreshing that, someone is questioning the current “state of affairs” which people such as myself simply accept without bothering to think about what's going on …

  5. #15
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    19,877
    Blog Entries
    1

    Default Re: openSUSE without kernel binary blobs?

    In a nutshell - At boot, the UEFI firmware (or BIOS) loads the microcode in to the CPU. Microcode updates can be incorporated with UEFI firmware (or BIOS) updates. Updates can also be provided by operating systems to load new microcode at boot time. The Linux kernel loads the update the microcode (CPU firmware) to the CPU's volatile memory at boot time.
    openSUSE Leap 15.0; KDE Plasma 5

  6. #16

    Default Time to stop using computers?

    Thanks for the explanations guys.

    I have taken the time for a quick refresh of my (as it seems dated) knowledge.

    Here is a summary which may be interesting along the lines of this discussion (anyone please feel free to correct anything which is wrong):

    Strictly speaking microcode and firmware are not identical.

    Firmware:

    • is the more generic term for low-level software
    • is specific to the particular hardware
    • runs on the hardware itself (e.g. video, sound, hard disk chip)
    • resides in a non-volatile memory (ROM) of the particular hardware BUT (which is new to me):

      It's becoming more common in some types of hardware for its "firmware" to be stored in driver software and loaded onto the device when it's booted/initialised, instead of leaving it permanently on the device.
      [...]
      Microcode is a subset of this latter type of "firmware".
      (source)



    Microcode:
    • is a hardware technique for interpreting programming instructions (machine code) to lower level CPU hardware instructions (actual sequences for the circuitry)
    • is part of "firmware" loaded through drivers (as mentioned above)
    • is loaded onto the CPU at boot, by the BIOS, but can be replaced later in the boot stage by the OS as well (e.g. to fix bugs without having to replace the whole CPU)

      IOW: It makes sense to update microcode through BIOS as it will be available to any OS running on the machine. But OTOH it may be futile considering the possibility of that being replaced by the OS.

      Intel "microcode updates" are in fact "firmware" updates in the sense that they update a lot more than just the microcode translation unit of the processor.

      These unified processor package updates we call "microcode updates" for Intel also update other on-die microcontrollers (such as the PMU and the power management core) as well as several parameter tables for different on-die processor subsystems. They are rather complex.
      (source)

      Typically, a microcode patch is uploaded to the CPU by the motherboard firmware (e.g., BIOS or UEFI) or the operating system during the early boot process.
      While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet.
      [...]
      To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks.
      Source: Reverse Engineering x86 Processor Microcode. The white paper also includes specific examples of such microcode Trojans.


    To me all that sounds like a quite valid reason to avoid binary blobs and to prefer hardware which has no such proprietary components, rather than rely blindly on the updates of manufactures who obviously created products vulnerable at so many levels.

    It seems I am looking for the impossible.

  7. #17
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,601

    Default Re: openSUSE without kernel binary blobs?

    Read these two
    https://en.wikipedia.org/wiki/Firmware
    https://en.wikipedia.org/wiki/Microcode
    and you will see that the definitions of these are not 100% set and that some even see them as synonyms.
    Henk van Velden

  8. #18

    Default Re: openSUSE without kernel binary blobs?

    Quote Originally Posted by hcvv View Post
    Read these two
    https://en.wikipedia.org/wiki/Firmware
    https://en.wikipedia.org/wiki/Microcode
    and you will see that the definitions of these are not 100% set and that some even see them as synonyms.
    I have read them earlier and even shared the second link in an earlier post. But thanks. Good to have them in such thread.

  9. #19
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,343

    Cool Re: Time to stop using computers?

    Quote Originally Posted by heyjoe View Post
    It seems I am looking for the impossible.
    Agreed. Given modern technology, IMHO, it's impossible …

  10. #20
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,609
    Blog Entries
    1

    Default Re: openSUSE without kernel binary blobs?

    I don't know if it should be difficult to understand the use of microcode firmware updates...
    (Some of the following based on hear-say)

    - Yes, once upon a time not that long ago (about 10 years ago?) Intel and MS got together and suggested a new way to improve performance applying some new ideas of the time... Up until then, computing architecture had largely been based on strict layers and modularity. Upper layers are built on succeeding lower layers and lower layers could be built to emphasize stability and reliability. But on this particular day, Intel and MS had an inspiration, what if higher layers (ie the OS) inform the lower layer(s) (ie BIOS, other firmware) to re-configure for better performance? And so, a new channel of communications came to be where the firmware could accept instructions from above. But still, from what I've seen microcode updates are only pin-holes of functionality by a specified API to remain highly secure (no hacker can send a command that might compromise the CPU or other critical hardware subsystem)

    - Example 1 I've seen where microcode instructions exist.
    It's taken many many years but VMware I think has finally figured out how to take advantage of special I/O and memory management features related to virtualization.

    - Example 2 I've seen where microcode instructions exist.
    Mitigations for Meltdown and Spectre (side loading) exploit vectors have been distributed through OS updates, but this is a relatively new feature in Intel CPUs. This suggests that over time, Intel has been carefully expanding the kinds of things available through a microcode update so that a complete BIOS re-flash or CPU replacement is not necessary. Keep in mind that so far, there is no final solution for Spectre and Meltdown through these updates, only the methods used to exploit can be addressed so far... A proper fix is possible only by replacing the CPU altogether.

    Bottom line, in this modern world where a number of things around us change with increasing rapidity, this is a way for hardware to continue to have a reasonable lifetime expectation.

    HTH,
    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

Page 2 of 6 FirstFirst 1234 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •