Slashdot Mirror
Red Hat Reverts Spectre Patches to Address Boot Issues (bleepingcomputer.com)
An anonymous reader quotes BleepingComputer:
Red Hat is releasing updates for reverting previous patches for the Spectre vulnerability (Variant 2, aka CVE-2017-5715) after customers complained that some systems were failing to boot. "Red Hat is no longer providing microcode to address Spectre, variant 2, due to instabilities introduced that are causing customer systems to not boot," the company said yesterday. "The latest microcode_ctl and linux-firmware packages are reverting these unstable microprocessor firmware changes to versions that were known to be stable and well tested, released prior to the Spectre/Meltdown embargo lift date on Jan 3rd," Red Had added.
Instead, Red Hat is recommending that each customer contact their OEM hardware provider and inquire about mitigations for CVE-2017-5715 on a per-system basis. Besides Red Hat Enterprise Linux, other RHEL-based distros like CentOS and Scientific Linux are also expected to be affected by Red Hat's decision to revert previous Spectre Variant 2 updates, so these users will also have to contact CPU/OEM vendors.
At least one site "characterized the move as Red Hat washing its hands of the responsibility to provide customers with firmware patches," writes Data Center Knowledge, arguing instead that Red Hat "isn't actually involved in writing the firmware updates. It passes the microcode created by chipmakers to its users 'as a customer convenience.'" "What I would have said if they'd asked us ahead of time is that microcode is something that CPU vendors develop," Jon Masters, chief ARM architect at Red Hat, told Data Center Knowledge in a phone interview Thursday. "It's actually an encrypted, signed binary image, so we don't have the capability, even if we wanted to produce microcode. It's a binary blob that we cannot generate. The only people who can actually generate that are the CPU vendors."
Instead, Red Hat is recommending that each customer contact their OEM hardware provider and inquire about mitigations for CVE-2017-5715 on a per-system basis. Besides Red Hat Enterprise Linux, other RHEL-based distros like CentOS and Scientific Linux are also expected to be affected by Red Hat's decision to revert previous Spectre Variant 2 updates, so these users will also have to contact CPU/OEM vendors.
At least one site "characterized the move as Red Hat washing its hands of the responsibility to provide customers with firmware patches," writes Data Center Knowledge, arguing instead that Red Hat "isn't actually involved in writing the firmware updates. It passes the microcode created by chipmakers to its users 'as a customer convenience.'" "What I would have said if they'd asked us ahead of time is that microcode is something that CPU vendors develop," Jon Masters, chief ARM architect at Red Hat, told Data Center Knowledge in a phone interview Thursday. "It's actually an encrypted, signed binary image, so we don't have the capability, even if we wanted to produce microcode. It's a binary blob that we cannot generate. The only people who can actually generate that are the CPU vendors."
I didn't knew it had the reboot feature!
As written in the summary, the CPU maker is the only entity who can create a fixed microcode, be it for inclusion into firmware (BIOS/UEFI) files or in Linux kernel microcode files. So asking the OEM vendors won't help one bit cause they can simply do nothing at all except use a file create by Intel. If RH is too small to force Intel to create working microcode without boot up bugs, then others aren't big enough either.
Then next thing is: what will RH do in the future? Never apply the Spectre microcodes due to instability? If so, what happens in the future when other microcode updates are needed, like before? Intel has afaik only a single microcode file for Linux for pretty much all CPUs together. There is no mix and match, no way for Linux to selectively choose what to load. That is why RH had to go back to an older version without the breakage for Spectre. they couldn't just disable the new buggy part of the microcode.
This file you can see and download here: https://downloadcenter.intel.c...
Normally it lives in your initrd.
Sooner or later RH has to include a current microcode file from Intel in RHEL again. Would have been nice if they had clearly communicated this to their customers. Not "wash their hands" but "we will continually work with Intel until this issue is resolved."
I understand why they stopped distributing the microcode. It is something that they cannot test fully, cannot fix and which might brick customers' hardware. If something goes wrong I expect someone to try to sue them. Distributing the microcode bring little benefit (to RedHat) but brings potential risk/cost.
The onus is really on AMD/Intel/... to test the new microcode on *every* CPU that they have produced and with a large selection of releases & configurations of operating systems (MS Windows, Linux, macOS, ...) with different support chips (RAM, USB, ...). Yes: a lot of work, but they are the ones who screwed up here. They have also known about these problems for some 6 months - so it is a complete disgrace that they have not already produced the microcode updates AND tested them.
Hopefully in a month or two, when the testing has been done properly: RedHat, Microsoft, ... will push out the microcode updates. We need these distributors, or vendors, to do so because otherwise very few machines will end up patched. Large organisations might contact the CPU vendors, most SME or home users probably don't know what the machines contain and won't think to worry about the update... which would just leave them vulnerable for when someone works out how to produce a real Spectre cracker program. It is ''when'' not ''if''.
Seems like there is more damage being done by the Meltdown / Spectre hysteria and attendant patch frenzy than by exploits of the vulnerabilities themselves.
Friends don't let friends Spectre patch their computers!
"each customer contact their OEM hardware provider and inquire about mitigations for CVE-2017-5715 on a per-system basis. "
Translation: each customer of Intel better think twice next time they consider and trust said company.
So Linux provides the ability to update the CPU microcode during boot. Does Windows do something similar? I know that Microsoft has control over their Surface devices and often rolls out UEFI / BIOS updates via Windows updates, but does the OS itself have this functionality too?
It would seem there's a pretty big exposure if Linux is able to push out updates directly from Intel, but Microsoft says: Apply a BIOS update from your PC OEM. Last BIOS issued to my motherboard was in 2014 and it is listed as beta.
This is Intel's fault, they should front the cost, effort and storm of support calls from the industry to get their microcode patches out (and wash, rinse, repeat until they get it *right*).
They want to control their ISA with an iron fist, including sticking encrypted, secret blobs and extra processors in their North/South/East/Westbridges or whatever, then they can deal with the fallout when *they* screw up.
If this were the auto industry they'd be already be banned from selling any units in warehouses with this flaw, and working on little boxes to put a new CPU in and a return voucher to send with it for every single damn CPU out there. Hell, Samsung at least tried to get people to send their undeniably defective products back in exchange for fixed ones. The fact that Intel is "too big to fail" is just another sign the industry has been too anticompetitive for far too long.
I miss the choice of architectures that were actually in commodity systems.
And reality have it that you are full of shit.
Closed-source encrypted binary blobs from Intel are causing booting problems and you're trying to blame it on open source? And then pretending to be another AC to praise yourself? Seriously, APK?
...and I'll say it again: there has been WAY too much hype and hysteria (Hhhhmmm: Hype and Hysteria would be a GREAT band name!) around these issues. A) The vulnerabilities are far too esoteric to be really useful when there are a gazillion very easy, well-worn paths to get at your systems. B) Yes, ultimately, these vulnerabilities need to be addressed, but in a much more reasoned, thoroughly tested fashion as opposed to the current "OMG! I must flash my BIOS, install the latest microcode and update the kernel AT ONCE or all my base are belong to them!!" mindset. Perspective, please.
See subject: POWER to make a system unbootable! Power to secure so well you can't use a computer!
Yes, yes: I know - UNJUSTIFIABLE 'downmods' FROM DUBAI (/.'s BizX is outta there) are forthcoming AGAIN https://linux.slashdot.org/comments.pl?sid=11639297&cid=55967889/ on this post too like last time of course (mark my words - it's "the best they got" (lol, ALL they got) vs. fact).
(POWER that makes me lmao!)
* Hahahaha!
APK
P.S.=> "PoWeR" to make your system go "POOF" - it's "MaGiC", lmao (openSORES truly IS for 'poofs' as the brits say, lol!)... apk
Wow, few paragraphs about Intel's fuckup and the culprit name isn't mentioned even once. It's Intel. Red Hat merely retracted updates developed and provided by Intel.
:wq
Oh, I see. So you can't find someone else's code to copy and call your own OpenSORES to fix it? Ok. I understand.
If he could justify the "STRAIGHT FROM DUBAI" comment, it would put these idiot "editors" in their place.
Are you insane? Don't you have some meds that might help?
Here's 1 https://www.bizx.com/contact/ and another https://www.bizx.com/about/team/ want more? Lookup "Dubai" and "BizX" (parent company of slashdot) on any search engine. How do you think the otherwise worthless toad that owns this place got money to buy it? His non-existent 'intellect'?? A trustfund baby or funding from Dubai is how.
Whipslash/Logan Abbott the power of DUBAI compels you https://linux.slashdot.org/comments.pl?sid=11639297&cid=55968457/ do they have more money to supply to you to buy up US media to program more sheeple with more traitor SJW bullcrap with your blackhat SEO tactics you're known to use?
The poster isn't suggesting Poettering literally did that, but rather suggesting that Poettering is that evil.
captcha: domineer
The post was fucking useless. I guess I need to look up what actually justifies a downmod, but that should.
Whipslash/Logan Abbott the power of DUBAI compels you https://linux.slashdot.org/comments.pl?sid=11639297&cid=55968457/ do they have more money to supply to you to buy up US media to program more sheeple with more traitor SJW bullcrap with blackhat SEO tactics you're known to use?
I hope BizX sues you for slander lol.
Thanks. This site was purchased to push an agenda. The timing went along with a lot of other weird things. Sucks that it isn't publicly traded. I looked on EDGAR a while back, and there are a ton of entries on Slashdot Media, but it looks as though it's just a little piece of someone's portfolio pushed around like a poker chip or a liquored up 19-year-old floozie at a frat party. California secretary of state office didn't have much to report either.
so I do not need to worry about Intel's f*ckups anymore: https://www.youtube.com/watch?... ;-)
Hey Von Braino It's in written form (no slander) or even libel. BizX is out of dubai in the links posted in the link you clicked on and his own former employees say he does blackhat seo on glassdoor reviews Von Braino!
Does look like a dubai connection. Most sites push someone's agenda. A globalist agenda that's not out for your good as a U.S. Citizen.
Under Oracle Linux 7.4, the command "ls /lib/firmware/intel-ucode/ | wc -l" reports 95 files in that location.
You can run "rpm -qi microcode_ctl" and "rpm -ql microcode_ctl" to get more information about what these are.
The microcode update "should not" brick hardware. The output of the command "rpm -qi microcode_ctl | tail -3" tells you why:
The microcode update is volatile and needs to be uploaded on each system boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts back to the old microcode.
I'm curious about AMD Ryzen with Vega graphics. Will they have all the fixes when they come out? Will they do a good job at 4k graphics?
It looks like an interesting chip and something worth considering, but only if I can ditch the standalone video card and maybe make a super compact PC. Maybe something like a NUC PC with M.2. and 16GB..?
I could possibly just strap that directly to my 4k tv's monitor arm. It is not as if you really need a CD drive anymore for much.
If AMD can make a nice integrated solution and sell it as a replacement to Intel's security problems, well this might be a good year for them..
I wondered about CPU micrcode hacking and I got the answer here: the micrcode update is signed. That suggests modern Intel CPU have a crypto engine to verify the update. I wonder how long will we live before someone leaks private key.