Linux Mint Forums

I've been searching but haven't found the answer yet, so maybe someone here knows.

Microsoft's "update" for Meltdown and Spectre is only partial. They require that the BIOS/UEFI be updated too. So Intel which is working on the Meltdown vulnerability will push the updates apparently to the motherboard manufacturers, which will decide whether to pass that on to the consumers. AMD is denying that Spectre is a problem from what I found, even though Spectre affects AMD and it is only Meltdown which is an Intel problem. As an owner of several MSI, and some other older motherboards, I am doubting whether any of my computers will be fully updated. Here is more detail and the procedure for checking if Windows is fully patched with both software and BIOS/UEFI updates. https://www.bleepingcomputer.com/news/m ... cpu-flaws/

So my question is, since Microsoft is requiring BIOS or UEFI updates for full mitigation of Meltdown and Spectre, will Linux also require BIOS or UEFI updates for full mitigation?

Your BIOS will need to be updated no matter Linux, Win or Mac.
Aka, it's not Linux (or any other OS) that requires BIOS updates, it's your computer(s) themselves that need such.

It's a multi-layered strategy: hardware level (BIOS updates), OS (kernel updates) level, userland (eg. Firefox updates).
You update as much as possible (aka, available) for your computer(s) & operating system(s) used.

With standard x86 hardware, it is normally possible to get an update where you just reboot using a floppy, CD, or flash drive, and it re-flashes your BIOS chipset. With Apple, the only way such a hardware update is distributed is such that you must be actively running their OS. They are such insane control freaks that they will not allow you to access the update outside of a software update process.

This means that people like me will never see any hardware update they might produce for my model of MacBook Pro.

Have I mentioned that I can't wait to walk away from their hardware? (If only I'd won any of the recent types of lottery game here in the U.S.)

Thank you for the responses. Is there a good source indicating that computers running linux will need the BIOS/UEFI update too? I'm hoping that using the processor microcode updates in linux will make the BIOS updates unnecessary for linux computers. With the processor microcode we linux users get processor fixes from AMD and Intel through repositories instead of waiting for the motherboard manufacturers to release a BIOS update that includes the processor update.

My problem with BIOS updates is not the installation but the acquisition of the update. I have never messed up a BIOS update, so far. However my MSI motherboards usually don't get BIOS/UEFI updates more than two years after introduction from what I have seen. So since my motherboards are all older than two years, I don't expect MSI to update the UEFI for them even if a processor update is made available to MSI.

With you on the BIOS updates They scare the crap out of me. I've had one computer in my career 'brick' on a BIOS update.

Generally speaking, it's always better to update the BIOS as a 'whole', instead of just 'hot-patching' the processor via microcode updates. The BIOS update will most likely contain firmware / fixes for other stuff as well. That is, if such is available - as you said, vendors get...'bored' of releasing such couple years later...

Now in regards to the upcoming microcode releases...no details have been released yet. To be on the safe side, personally, i'd start by updating the kernel first: according to Canonical's announcement, patched kernels will become available on 9 January, and i'd refrain from installing newer microcode packages in this specific case for a while, say until the whole situation gets 'cooled' down / more details are known in regards to the nature / technical implementation of the fixes...

Edit: Spearmint got it faster - check this post here as to why i personally wouldn't rush installing newer microcodes until more details are known...start with the kernel on 9 January & firefox, and you're more than ok at least for starters...
viewtopic.php?p=1409656#p1409656

https://www.cnet.com/forums/discussions ... them-down/

viewtopic.php?f=58&t=260764

interestingly enough, intel has released 4 microcode updates since july of 2017...the latest update was yesterday in the wee hours of the morning...ive already changed over 3 of my 4 computers (my main driver for everyday is an AMD) INTEL computers to not only the 4:13 series kernel (only 4.4 and 4.13 kernels are getting the kernel security update on the 9th for linux mint...4:10 & 4:11 series not covered) but have also installed the Jan 5th 2018 newest microcode from INTEL on my dual core and core i5 processors...all works flawlessly...i am providing the link to Oregon State University Repository for intel microcode update...just click and install...64 bit solution is marked "amd64.deb" and before you ask the amd does NOT mean AMD chipset...its just what they call it meaning its for the 64 bit INTEL chipset install...DAMIEN

http://ftp.us.debian.org/debian/pool/no ... microcode/

DAMIEN1307 wrote:interestingly enough, intel has released 4 microcode updates since july of 2017...the latest update was yesterday in the wee hours of the morning...ive already changed over 3 of my 4 computers (my main driver for everyday is an AMD) INTEL computers to not only the 4:13 series kernel (only 4.4 and 4.13 kernels are getting the kernel security update on the 9th for linux mint...4:10 & 4:11 series not covered) but have also installed the Jan 5th 2018 newest microcode from INTEL on my dual core and core i5 processors...all works flawlessly...i am providing the link to Oregon State University Repository for intel microcode update...just click and install...64 bit solution is marked "amd64.deb" and before you ask the amd does NOT mean AMD chipset...its just what they call it meaning its for the 64 bit INTEL chipset install...DAMIEN

http://ftp.us.debian.org/debian/pool/no ... microcode/

Actually, the only one I'm seeing listed in System Settings > Driver Manager is the one dated 3.20170707, which I take to mean July 7, 2017.

The changelog for the most recent bundle from debian confirms it's got some mitigation for Spectre included. it is also marked as unstable.......so beware.

http://metadata.ftp-master.debian.org/c ... _changelog

intel-microcode (3.20171215.1) unstable; urgency=high

* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
New upstream microcodes to partially address CVE-2017-5715
+ Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
* Implements IBRS and IBPB support via new MSR (Spectre variant 2
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
* LFENCE terminates all previous instructions (Spectre variant 2
mitigation, conditional branches).

-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 04 Jan 2018 23:04:38 -0200

hi portreve...i did not go through the driver manager for this...i went here... http://ftp.us.debian.org/debian/pool/no ... microcode/ ...using my browser to obtain this from Oregon State University and downloaded the latest amd64.deb microcode dated jan.4th 2018...i have been updating over 20 linux based computers now over the last several days with intel chips and not one of them has borked by doing this...DAMIEN

Intel-Microcode 3.20171215.1 amd64. deb 04-Jan-2018 20:24 1.2m

uberdorf wrote:Thank you for the responses. Is there a good source indicating that computers running linux will need the BIOS/UEFI update too? I'm hoping that using the processor microcode updates in linux will make the BIOS updates unnecessary for linux computers. With the processor microcode we linux users get processor fixes from AMD and Intel through repositories instead of waiting for the motherboard manufacturers to release a BIOS update that includes the processor update.

My problem with BIOS updates is not the installation but the acquisition of the update. I have never messed up a BIOS update, so far. However my MSI motherboards usually don't get BIOS/UEFI updates more than two years after introduction from what I have seen. So since my motherboards are all older than two years, I don't expect MSI to update the UEFI for them even if a processor update is made available to MSI.

If you Google it you will find it. I have read about 20 or 30 articles about the problem and they all indicate that Linux is exactly like Windows and Mac in this situation.

Rocky Bennett wrote: If you Google it you will find it. I have read about 20 or 30 articles about the problem and they all indicate that Linux is exactly like Windows and Mac in this situation.

Unfortunately, Rocky, that is not correct about finding it with Google. I googled it when I posted, I said I searched for the answer, and I just googled it again just now in case something new came up. Still not there from what I could find. By the way, it would be helpful if you could prove statements with a link if you are going to take the time to make a post.

The only reference as of right now that comes up with Google, that might be applicable to Linux and BIOS updates is this link https://www.thomas-krenn.com/en/wiki/Sa ... nd_Spectre In the FAQ it says "firmware/microcode/BIOS updates are required, too" So we know that a microcode update is required for all OS, but it doesn't directly answer the question of whether a BIOS update is also required for Linux if the microcode is being loaded at startup. (You can enable microcode updates in Linux Mint with the driver manager. Other distros like debian require the microcode installed through apt and the blacklist removed, while Arch requires it through pacman.)

*edited to fix typo

OT

Portreve wrote:using a floppy

What's a floppy?

...uberdorf, it sounds to me like you just wanna avoid updating the bios 'as is'

However, you take way too literally the 'required' part: firefox already has been patched. The updated kernel also has you covered. Lots of system libraries / executables will be recompiled with retpoline & other fixes.
So, even if in a totally hypothetical scenario, where neither the kernel neither the apps got patched, you'd still be covered. Let alone that we're not talking about opening a random page & going 'poof' as misinformed people (with a Windows-malformed-jpeg-exploit background i assume?) like to think, we're talking about highly sophisticated & very time-consuming attacks here, at least so far (and it doesn't really look like this is gonna change).

So, in that sense, yes, provided you've updated the above, you could possibly avoid updating the whole BIOS, and you could instead just load the microcode (or even forget about it altogether). What would be the possible problems in such case? Quickly out of my mind:
1) An attacker, assuming he/she got access somehow in your machine, could disable the microcode from running at next boot, possibly without you even noticing.
2) You lose all the extra benefits / possible corrections that come from updating the bios as a whole (as i described above...admitedly not in great detail). For example, it's happened to me to load a microcode and notice a slight 2-3 degrees increase in temperature, then afterwards update the bios, and the temp had instead slightly decreased even more than before tweaking anything. Nothing truly extraordinary, but still: what extra magic did the bios contain & do? Who knows - it's a black box, only the vendors do know. On laptops, i've also occasionally noticed the battery capacity values being re-written / reset properly.

Now, by the end of the day, i'm just yet a random guy in the net, speaking out my equally random blurb
But to sum it up - even the maintainers responsible for packaging & distributing the microcode packages themselves in linux, still recommend updating the firmware 'properly' according to vendors' instructions if possible...so who am i to recommend otherwise & argue with them?
https://bugs.debian.org/cgi-bin/bugrepo ... =886367#17

Thank you for the link thx-1138.

Anyways, as I have mentioned, I don't mind installing a BIOS update if one ever becomes available. My motherboards are not likely to have BIOS/UEFI updates available to install. The more recent brands I have bought are MSI, which is a cheap brand for which I have never seen updates available after 2 years. I have some HP's from almost 10 years ago, a couple eMachines also from almost 10 years ago, and I don't expect HP or the now defunct eMachines to update them either. So I, and I suspect most other people unless they bought from a better manufacturer in the last few years, am/are not likely to have a BIOS update made available for installing. Most of us are just out of luck regarding getting a BIOS update for this bug.