Dell and HP Advise All Their Customers To Not Install Spectre BIOS Updates (bleepingcomputer.com) 88
An anonymous reader writes: The Spectre and Meltdown mess continues with Dell now recommending their customers to not install the BIOS updates that are supposed to resolve the Spectre (Variant 2) vulnerabilities. These updates have been causing numerous problems for users including performance issues, boot issues, reboot issues, and general system stability. Due to this, Dell EMC has updated its knowledgebase article with a statement advising customers to not install the BIOS update and to potentially rollback to the previous BIOS if their computers are exhibiting "unpredictable system behavior". ZDNet reports that HP too has issued a similar advisory. The computer manufacturer pulled its softpaqs BIOS updates with Intel's patches from its website, and said it would be releasing a BIOS update with a previous version of Intel's microcode on Thursday.
Spectre cannot be even practically exploited. (Score:5, Informative)
People still haven't gotten the point - this is testament to Intel's PR efforts to obfuscate the facts. It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown (affects only Intel CPUs). Un-fucking-believable. We truly live in the epoch of idiocracy.
Re: (Score:3)
Obligatory: Intel CPU Backdoor Report (Jan 1 2018) (Score:1)
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware [youtube.com]
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag [events.ccc.de]:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection [win-raid.com] and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide [github.io] using the me_cleaner [github.com] script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode [ptsecurity.com], use me_cleaner [github.com] with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit [github.com].
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode) [ptsecurity.com]
me_cleaner: Set HAP AltMeDisable bit with -S option [github.com]
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine [blackhat.com]
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it [eff.org]
Sakaki's EFI Install Guide/Disabling the Intel Management Engine [gentoo.org]
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws. [zdnet.com]
CVE-2017-5689 [cvedetails.com]: An unprivileged network attacker could gain system privileges to provisioned Intel manageability SKUs
CVE-2017-5705 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Manageability Engine Firmware
CVE-2017-5706 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Server Platform Services Firmware
CVE-2017-5707 [cvedetails.com]: Multiple buffer overflows in kernel in Intel Trusted Execution Engine Firmware
CVE-2017-5708 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Manageability Engine Firmware
CVE-2017-5709 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Server Platform Services Firmware
CVE-2017-5710 [cvedetails.com]: Multiple privilege escalations in kernel in Intel Trusted Execution Engine Firmware
CVE-2017-5711 [cvedetails.com]: Multiple buffer overflows in Active Management Technology (AMT)
CVE-2017-5712 [cvedetails.com]: Buffer overflow in Active Management Technology (AMT)
Useful links (Added 2017):
The Intel ME subsystem can take over your machine, can't be audited [ycombinator.com]
REcon 2014 - Intel Management Engine Secrets [youtube.com]
Untrusting the CPU (33c3) [youtube.com]
Towards (reasonably) trustworthy x86 laptops [youtube.com]
30C3 To Protect And Infect - The militarization of the Internet [youtube.com]
30c3: To Protect And Infect Part 2 - Mass Surveillance Tools & Software [youtube.com]
1. Introduction, what is Intel ME
Short version, from Intel staff:
Re: What Intel CPUs lack Intel ME secondary processor? [intel.com]
Amy_Intel Feb 8, 2016 9:27 AM
The Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current Intel chipsets, I even checked with the engineering department and they confirmed it.
Long version:
ME: Management Engine [libreboot.org]
The Intel Management Engine (ME) is a separate computing environment physically located in the MCH chip or PCH chip replacing ICH.
The ME consists of an individual processor core, code and data caches, a timer, and a secure internal bus to which additional devices are connected, including a cryptography engine, internal ROM and RAM, memory controllers, and a direct memory access (DMA) engine to access the host operating system's memory as well as to reserve a region of protected external memory to supplement the ME's limited internal RAM. The ME also has network access with its own MAC address through the Intel Gigabit Ethernet Controller integrated in the southbridge (ICH or PCH).
The Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored.
ME firmware versions 6.0 and later, which are found on all systems with an Intel Core i3/i5/i7 CPU and a PCH, include "ME Ignition" firmware that performs some hardware initialization and power management. If the ME's boot ROM does not find in the SPI flash memory an ME firmware manifest with a valid Intel signature, the whole PC will shut down after 30 minutes.
Quotes on Intel backdoors:
A message from RMS [fsf.org]
by Richard Stallman on Dec 29, 2016 09:45 AM
The current generation of Intel and AMD processor chips are designed with vicious back doors that users cannot shut off. (In Intel processors, it's the "management engine".)
No users should trust those processors.
2. The backdoor is next to impossible to de
Re: (Score:1)
Now that the news is out, it's just a matter of time until active exploits of Spectre 2 are in found in the wild.
Re: (Score:3, Informative)
Really?
While Meltdown is more awful, its mitigation is pretty much done with KAISER type patches to kernels. This is not a fix but is good enough for now. The same was done in Linux kernels for ARM.
Spectre is more tricky when it comes to making sure either of its variants cannot be used. And more vulnerabilities of the same type are likely to be found. Work on making things less vulnerable to it is still underway.
I get it that it's popular to bash Intel at this point and while they have done a lot to deserv
Communicating. (Score:5, Interesting)
ARM is probably the only one of the chipmakers doing the right thing here. Information is quick, public, to the point and fixes are deployed as soon as they are done. There are performance issues with ARM patches but they are taken as necessary.
They just got lucky to be right most of the time.
(Helps that they use a much simpler RISC architecture : Their engineer have probably less to review until they can give a definite answer about what is exploitable.
They can mass-exclude any ARM core that doesn't do speculative execution at all (e.g.: RaspberryPi) ).
AMD is just ignoring it altogether until they no longer can. Regarding Spectre: near zero chance > microcode and software updates are coming, this you can read in statement on their page.
Mordern CPUs *are* complex, it's not impossible for not everybody in a company to know every single details.
Spectre variant 2 is the perfect exemple : ."switch" block into machine code.
Variant 2 Spectre works by relying on extremely precise gory detail of the implementation of speculative execution around indirect jumps whose destination isn't even known at execution time
(e.g.: a jumptable whose index depends on a result that isn't computed yet.
e.g: That's one possible form to compile a C/C++
That's also what happens when you need to call the virtual overloaded member function of a C++ object member of an array and you haven't computed the index into the array yet)
The Google demo code relies on the format of the internal data that the branch predictor uses to makes it best guess to where this as of yet unkown destination isn't know.
(Basically, the CPU keeps notes of where it jumped-to most of the times during the past when encountering this point of code.
But the way the CPU write down "this point of code" in it notes is actually imprecise and can lead to confusion.
More or less, it's a hash and Google has found a way to cause a hash collision.
The attacker causes their own attack-program to jump to position A, whenever execution arrives at instruction B.
Then the exploited program reaches a different instruction C, but the CPU is confused and thinks it's again at instruction B, and jumps to position A "out of habit" based on its notes, even if in the exploited program, there's no way this could happen ever (e.g.: there's no "position A" listed in the jump table). )
Should Intel admit that they are vulnerable ? Yes, Google caught them with their pants down on this one.
But, the Intel Xeon exploited by Google demo code certainly works completely differently than any AMD CPU.
So for sure they can guarantee that the exact exploit code won't work for on AMD CPUs
(It would be reasonnable guess, even without speaking to any engineer)
Now: is it definitely impossible to somewhat exploit the jump prediction in a globally similar way ?
Well difficult to exclude.
AMD would need to discuss it at lengths with their engineers experts in branch prediction on their CPU.
So first "nearly-zreo" (Shouldn't not work, but who knows ?)
And then, once AMD manages to get hold eventually of the guy who knows: Oh, shit, it turns out there could be a completely different method that could perhaps be applied to exploit indirect jumps on some recent architectures.
So update the page to tell people to do the updates (while continuing to review with the engineer to try to give an actual answer whether there is actually a viable exploit).
AMD are trying their best, but CPUs are complex stuff, and it's not easy to give a definitive answer fast.
Re: (Score:3, Insightful)
...it's not impossible for not everybody in a company to know every single details.
This broke my brain. Can you re-word it as a car analogy?
Re: (Score:1)
Or maybe a series of tubes analogy?
Re: (Score:2)
While Meltdown is more awful, its mitigation is pretty much done with KAISER type patches to kernels. This is not a fix but is good enough for now. The same was done in Linux kernels for ARM.
It's good enough if you don't mind a 5-50% performance impact, depending on workload.
Spectre is more tricky when it comes to making sure either of its variants cannot be used. And more vulnerabilities of the same type are likely to be found. Work on making things less vulnerable to it is still underway.
AMD is already less vulnerable to it than Intel, because Intel did things they knew were unsafe to gain a speed advantage over AMD.
I get it that it's popular to bash Intel at this point and while they have done a lot to deserve this, this issue is really not why. Meltdown also affects Power and ARM core (or a few).
It's telling that it affects only POWER (probably 5-9, definitely 7-9), Intel, and one ARM core. It tells us that Intel and IBM are willing to play fast and loose with the security of your data in order to gain a competitive advantage.
Now, these broken Intel updates are meant for Spectre (variant 2) mitigation. Along with the Linux kernel patches Linus lambasted (reading further into the thread, there do seem to be reasons why patches were written the way they were).
Yes. Intel incompetence. They are in a panic and scrambling t
Re: (Score:2)
More likely nobody cares to with the ability. "Hackers" have been governments and megacorps alone for the last ~decade and a half. They already have a plethora of backdoors at their disposal while Meltdown and Spectre are trickier to exploit. The script kiddies only get what leaks out and usually end up implementing them wrong anyway. The governments and megacorps tend to try to remain covert (e.g. when they're in your system they have reason to make you not believe they are) while the script kiddies ar
Re: (Score:1)
Agreed. I'm sure that there are there exploits out there that are a much greater risk to me which are as yet unknown to the general public (and hence unknown to me). I don't do any banking or engage in an political activities on PC's, and I consider the greatest risk to be someone hacking Amazon and other parties that I engage in retail activities with.
Re:Spectre cannot be even practically exploited. (Score:4, Interesting)
To me this sounds not so much like a PR efforts as much as Yet Another Intel Fuck-Up that would require additional PR efforts to spin.
You'll note that the Dell advisory explicitely mentions that the advisory applies to the Intel patches. It doesn't mention problems with patches for other CPU's.
As I read this story, Intel provided BIOS updates for their own CPU's, and those BIOS updates are causing problems.
It just happens to be that this particular fuck-up involves the lesser of the two previous bugs, but doesn't really seem caused by that bug itself.
So I guess this means that for Intel CPU's, both bugs are dangerous.
AMD and ARM are still left with only a single reasonably harmless bug.
Re: (Score:3)
While it is not clear how dangerous Spectre is on AMD and ARM, it seems to be a lot harder to exploit there and it already is hard on Intel.
What really surprises me though, is that Intel is putting out patches this badly done. It is like they are now mocking the customers that bought their fast, but inferior in every other aspect products. It is also like they are actually technologically incompetent now and do not even understand their own products.
Re:Spectre cannot be even practically exploited. (Score:4, Funny)
fast, but inferior in every other aspect products.
Intel CPU's are fast in the same way that a car goes fast after you drive it off a cliff.
Re: (Score:2)
Indeed.
Re: (Score:2)
People still haven't gotten the point - this is testament to Intel's PR efforts to obfuscate the facts. It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown (affects only Intel CPUs). Un-fucking-believable. We truly live in the epoch of idiocracy.
Well parts of it can be exploited. But mostly it was mainly fixed by fixing browsers. The parts that attack hypervisors and kernels is the speculative stuff.
Re: (Score:2)
The neat thing about computers is a not-practical exploit can be programmed, so the hacker isn't wasting there efforts in all the rigamarole. It really isn't up to the general public to be able to successfully classify how bad a flaw is. Sure Intel would also like to point blame at AMD and ARM too. But Intel is in a loose loose situation here. They had big problem which they had patched, then there is an other one, which they need to show that they are responsive, however it is a complex problem that ne
A concern for VPS providers (Score:3)
In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Citing Forbes [forbes.com], Wikipedia’s article on Spectre [wikipedia.org] says: “Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on t
Re: (Score:2)
Those wikipedia articles are terrible. Give it a few more days and there will be full blown citeogenisis going on with references to some article written by a hipster on mashable or vox.
Exploits details (Score:3)
In spite of it being perhaps more difficult to exploit, I have the impression that large data centres operating virtual private servers (commercial and corporate alike) have good reasons to be seriously concerned about Spectre.
Yes. Basically Spectre "Variant 2" / "Branch Target Injection" would allow to rent a VM on Amazon's cloud and spy on any other VM that runs on the same physical CPU.
“Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, {...} Wikipedia’s article on Meltdown [wikipedia.org] says: “Meltdown attack cannot be used to break out of a virtual machine.” (Of course, Meltdown is nonetheless a critical problem, for other reasons.)
Meltdown / "Rogue Data Cache Load" specifically can access kernel (protected) memory.
It is something specific to Intel CPUs.
In order to make a few micro-improvement for speed, Intel CPU only check for protection at the last moment before committing the results to memory/register.
That means that speculative execution might get pas memory protecti
Where do I send bill for the time/effort to fix? (Score:2)
Can I bill intel?
Often sales fine print tries to limit the liability of the part make to the cost of the part. This isn't unreasonable especially if there's no really malice or incompetence involved. While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent. One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake. Until you make one, you often don't see your own blind spots. One could have hoped for better or more dilligence but
Re: (Score:2)
While my opinion of intel is in the dump now, I can't honestly say it was truly incompetent.
It wasn't incompetent, it was unscrupulous. They did it wrong, and told everyone they were doing it right. They knew what they were doing, and furthermore, they knew it compromised security. It's not that Intel can't do it right. It's that Intel will lie to you and play games with the security of your data.
One reason Boeing makes such good airplanes is that WWII taught them every way to make a mistake.
In computer terms, WWII was way back around the 486 or the Pentium. Now we're into the global terrist threat phase of computer security, and Intel is still acting like it's WWII and cutting some corners t
Re: (Score:3)
It seems the majority of people believe that Spectre (affects Intel, AMD and ARM) is just as dangerous as Meltdown
It is just as dangerous, but it's also harder to exploit. But then we apply security fixes for all manner of unlikely attack vectors all the time. It's just not good practice to leave a known publicised attack vector which has been patched unpatched on your systems.
Very few people have the resources to independently risk assess all patches that they apply.
Re: (Score:1)
It's interesting how Intel managed to downplay the AMT issues, which IMHO are more in-line with Spectre in most cases (a bit worse in effect, easier to patch apparently), but is now playing up Spectre to have it overshadow Meltdown...
Re: (Score:2)
Intel has the best public relations officers that money can buy. This is less expensive than designing secure products and has a larger payoff.
Comment removed (Score:3, Interesting)
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Re: (Score:2)
All certainly true.... except I think for the going under part.... they'd suffer, of course... but I don't think it would be bad enough to kill them off entirely. Intel has survived being behind AMD once before, back in the olden days when almo
Re: (Score:1)
Going under was in the context of also having done a recall. Keep in mind a recall+replacement would effectively be returning the last ~decade of sales revenue in full AND tripling-down on the R&D+production budgets to get everything replaced within a few years, AND not charging for it. They would definitely go under if they fixed the issue as they should simply following a fair deal "e.g. customer paid x for y, they should get y for x" - they have no practical mechanism by which to compensate people
Re: (Score:3)
I'm looking forward to seeing the legal consequences.
There will be none. I'll bet you a dollar.
Re: (Score:1)
Re: (Score:2)
There will be none. I'll bet you a dollar.
I'll take that bet, if you like. I'll bet a further dollar that there will be none in the USA or Israel, but that there will be some in the EU. The EU loves to fine American companies.
Odds are good that there will be no substantial penalty, at least on Intel's scale, but I'm not willing to bet along those lines. It depends on what happens in the EU, and I'm not sufficiently up on their politics.
Re: (Score:2)
Considering how poorly Intel has handled this, I'm looking forward to seeing the legal consequences.
Do you mean like the legal consequences the telecommunications companies faced when it was discovered that they were handing everything over to law enforcement without a court order?
Intel ME/AMT (even a stopped clock...) (Score:3)
Well at least, look on the bright side :
even if you brick the mainboard into an unbootable state with the bad firmware upgrade,
you can still log into the Intel ME / Intel AMT web-interface running on the ARC core in the chipset, and flash another version from there.
Better than needing to physically walk to the bricked machine, open it, remove the firmware EEPROM chip from the socket, put it into your own EEPROM programmer, reflash a different version and put it back together.
A.K.A.: the only time where Inte
So far so good on my Gigabyte motherboard (Score:1, Offtopic)
I have a Gigabyte motherboard and a Skylake Core i5 and installed the new BIOS update (which says "Update CPU Microcode") and so far it seems to be going good. No random reboots or crashes and no noticeable slowdowns.
Re:So far so good on my Gigabyte motherboard (Score:5, Funny)
Meltdown is Intel only (Score:4)
Re: (Score:2, Informative)
Thanks for the scoop! I don't think Meltdown being an Intel only problem has ever been mentioned before.
Re: (Score:2)
ARM isn't affected by Meltdown. IBM is. It's not just an Intel problem, but it is an Intel problem for popular chips on the market. ... Lucky for Apple.
Spectre Variant 2 - CPU specific too. (Score:4, Informative)
Spectre Variant 2 is also heavily CPU specific.
The exploit needs to know how the predictor used for indirect branches works (i.e. jumps where the destination isn't know yet, like jump tables (ways to do a C/C++ switch) or calling overloaded virtual C++ members in an array of object) in order too fool it and force it to guess wrong and jump to a completely wrong destination.
It's been demonstrated on Intel CPU.
ARM reports that the few Cortex cores that do speculative execution are affected.
(But, no ARM-specific exploit code is mentioned).
AMD knows that the Intel-specific code won't work (duh... obviously), but they cannot exclude that there won't be any way to exploit their indirect branch speculation ("near zero", not "zero" chance). Currently they recommend to apply patche, while they try to work out if there are possible viable exploitable to be made against their indirect branch prediction.
PowerPC G3 and G4 are not exploitable, I've read. They *do* speculative execution. But they either don't speculate around indirect jumps, or don't speculate far enough to be actually exploitable in practice.
Re: (Score:2)
PowerPC G3 and G4 are not exploitable, I've read. They *do* speculative execution. But they either don't speculate around indirect jumps, or don't speculate far enough to be actually exploitable in practice.
So we know that POWER7 through POWER9 are affected (patches are already out) and we also know that the latest POWER processor is not. All that leaves are POWER5 and POWER6, and since IBM has stated that more information will be forthcoming on those processors, it's probably safest to assume at this time that they are also vulnerable.
What? Not according to ARM. (Score:2)
The Cortex-A75 [arm.com] is vulnerable according to ARM's own documentation.
ZDNet without an adblocker is hell (Score:1)
I just made the fatal mistake of clicking on a ZDnet article just to get to the source material - the HP link - and I happen to not be running ad block on this machine - well that will never happen again - ad block will be installed here too. I was starting to feel guilty about not supporting sites until I saw the vile state of internet advertising for the first time in a few years...
Note to /. editors - please link to source materials as you did with Dell in the future and not lame ad filled articles th
Intel will have to revise it's deployment % figure (Score:2)
Re: (Score:2)
Nope, they said no such thing. They said that 90% of their systems have patches available. Given it was always left to the vendors to issue these patches that 90% figure is not going to happen, at all, and definitely not on the day the microcode was released.
Re: (Score:2)
Re: (Score:2)
It was never viable to begin with since most vendors would never push it out. Shit the last BIOS update I got was in 2014 and it is marked as Beta.
Also if you want to get realllllllllly technical they never promised a lack of system reboots. Maybe the new patch comes with features that ensure you're always running the latest kernel. You know getting all those Linux sysadmins who insist they don't need to reboot after applying security updates. ;-)
Buy? Sit? Sell? (Score:2)
Re: (Score:2)
Softpaqs?? (Score:1)
It is so fun to see still lingering Compaq branding and terminology popping up in HPs plantation.
Shine on Compaq!
I see a lawsuit on the horizon.... (Score:2)
Re: (Score:2)
no, not the microcode, the very hardware of the chip has flaws. Impossible to fix by microcode changes alone, the purpose of any microcode changes released are to allow patched operating systems the choice to avoid using certain features of the hardware, but the flaws will be there and it is entirely possible for the OS to mistakenly or in ignorance still use those flawed features. And it turns out so far all OS I know of that have attempted to conform to Intel's intentions have failures on certain hardwa
Re: (Score:2)
I think they could probably use microcode to turn off speculative execution. I'm no expert, so I could be wrong, but I think they could. If so, it's not impossible, it would just slow things down a lot.
Re: (Score:2)
I think they could probably use microcode to turn off speculative execution. I'm no expert, so I could be wrong, but I think they could. If so, it's not impossible, it would just slow things down a lot.
They almost certainly could, but replacing an insecure processor with a slow processor is not a fix. All of this flailing around and releasing of garbage patches shows us that Intel is in panic mode, and they are not executing well. They are running in circles like decapitated poultry. As long as the FUD machine operates correctly though, and incompetents continue to tell lies about which processors are vulnerable to MELTDOWN (let alone SPECTRE) the stock price will stay more or less steady. If the EU annou
Re: (Score:2)
Depending on the microarchitecture, things like permissions checks on TLB lookups, page table walks, can all be *implemented* in the actual microcode (DEC Alpha), making such a flaw a flaw in the microcode, not the silicon.
Ubuntu security patch rollback today. (Score:3)
I couldn't help but notice that the package "intel-microcode" was updated today. Given that I already had the 20180801 microcode installed I looked up the version of the package: "intel-microcode 3.20180108.0+really20170707ubuntu16.04.1"
That's an interesting package management technique.
Re: (Score:2)
I just channeled my inner American combining middle endian date formats and converting from big endian to little endian with no regard to standards because I like to watch the world burn :)
Re: (Score:2)
Yeah, I noticed this one the other day. The changelog is fun, too (Debian Sid):
Even more amusing, this update showed up a day or two after Li
Re: (Score:2)
What is strange about this?
The method of reverting involved a new package number with a very strange version name. That's all. The actual thing which was done (removing the buggy releases) is perfectly normal. I just figured there may have been a neater way of versioning recalled releases.
the cure is worse then the illness... (Score:2)
especially when the 'doctor' in this case is known to be a pathological liar.
Maybe you should *READ* submissions from ACs... (Score:2)
So, these BIOS updates cause system stability? Why wouldn't I want to install them?