'This collaboration is absolutely critical going forward'... One positive thing about Meltdown CPU hole? At least it put aside tech rivalries... A panel of eggheads from Intel, the US government, and academia held court this week to figure how they can keep the likes of El Reg from spoiling their next major bug reveal. The group met at the Churchill Club in San Francisco to reflect on 2018's big security story – the Spectre-Meltdown CPU flaws – and ponder how it could …
Forcing your software to circumnavigate the hardware bugs, just so they can keep selling them with a 'cheating' speculative execution engine. Yes, it’s cheating. It’s running all the red lights. That’s why it’s so efficient.
Guess what? You are paying triple by circumventing this in software, which makes the whole thing even slower. Yet, Intel keeps publishing benchmarks WITHOUT mitigations enabled; something that should be illegal to begin with.
They are trying to make this look as if something immensely complicated has a few bugs. Shit happens, right? Wrong. This is a fundamental problem. It’s not that they didn’t know they were ignoring the red lights. They simply chose to do so, because cheating can be lucrative. Remember Volkswagen with their "super clean" cars? How did they manage to get them that clean again? Oh yeah, just like Intel managed to get their crappy processors so fast...
You may throw in "But what about the competitors? Didn’t they cheat as well?" Again, just like Volkswagen. The competitors (not all of them) had to follow. It was either that or make it public that they were cheating.
Here’s some insider information for you: With Volkswagen, they tried to make it public since 2007 without avail! Only when a US secret service thought that it was time to punish the Germans, it made the headlines and went to court.
With Intel, it’s the other way round. German "intelligence" is behind "rendering those bugs public" (revenge) and the US is backing Intel. Hence, no refunds and let’s pretend that those "bugs" are unavoidable.
I wish the (compiler) programmers had the guts to refuse, simply telling them that the hardware needs to be replaced.
What tosh!
1. There's nothing "cheating" about speculative execution. It turns out it has a huge security downside, but nobody realized that at the time.
2. Replacing the hardware is simply not going to happen. Redesigning a chip as complex as an x64 CPU to eliminate the problems is going to take *years*. What was everybody supposed to do in the meantime? Switch off their computers? Yes software has to work round hardware bugs; it sucks, but it's easier to change software than hardware.
3. However, I'll give you the point that Intel publishing benchmarks without mitigations enabled is outrageous.
"What tosh!
1. There's nothing "cheating" about speculative execution. It turns out it has a huge security downside, but nobody realized that at the time."
---
Right, so you believe that nobody noticed that they were ignoring the MMU - thus treating every system as if it were a single user system running DOS during speculative execution?
You are aware that there are plenty of people involved in such a process? Some of them having intimate knowledge of the CPUs... and you believe that they all failed to see this "little detail"?
I, for not a single moment, believe that the Intel security team did not realize that there were security holes. I think that they were, like in most companies, pushed aside. It was a business tradeoff. Most businesses have to make trade-offs based on the projected Loss. Speculative instruction execution, always raises the hackles in most security engineers. I remember quizzing a certain chip vendor about it and they were not surprised by my line of questioning.
Intel will only change if the market pressure is high enough or because of regulations and fines. Maybe GDPR can be used against Intel. The fines are 2-4% of global revenue. The previous CEO sold his stock when these issues were discovered.
Let's look at it in a different market: We all know that cars are extremely hackable. Even the Tesla gets hacked (nowadays with great difficulty). The reasons that Auto companies can skate around cyber security is:
1. No car has been hacked in the field by the bad hackers (white hat hackers not included)
2. No one has died.
3. They have cyber insurance.
4. Market doesn't care enough.
5. There are no NHTSA requirements to do so. Guidelines only.
I totally agree. This form of optimistic speculative execution, with no cache erasure on non-use, is ridiculous. Where was the peer review when this was done?
This is a fundamental flaw in chip design.
If this was a car we would be seeing punitive damages through class action law suites and a massive, world-wide recall. What we got from Intel was the equivalent of "I know we told you the car could do 70mph, but to be legal with emissions you can only do a max of 30mph. OK?"
I said this at the time - we need to look at the chip designs from the ground up. There is a lot of cruft in the X86 design that simply does not need to be there in the 21st century. Only IBM had a real go at this with the Power Series, and proved that low power, high speed chip could be built. Then you can have the performance without all this dicking around in speculative execution horror.
@ I Am Spartacus
" with no cache erasure on non-use, is ridiculous." Cache erasure on non-use would not fix the Spectre issue, you would have to replace all the cache entries you removed on the speculative path. Exploits can figure out information from what entries are no longer in the cache.
Per your X86 cruft comment, Intel did try to push exactly that concept. Get rid of X86 replace it with Itanium. Didn't work so well. I'm sure Itanium wasn't the best but they probably still spent billions of dollars developing it hoping to kill X86. I think it also wasn't the first time Intel wanted to kill X86, didn't they try something much earlier I want to say the i860 or i960 processors or something -- I want to say I remember reading something along the lines of those processors were the first ones that MS built NT on and only ported it to X86 later (and alpha and mips and ppc..)
As for peer review. I find it funny to see comments like this. This obviously isn't a new issue, this stuff has been in the chips for more than a decade. No real stink was made (outside I recall reading OpenBSD folks harping on hyperthreading and other stuff about 10 years ago). Lots of people knew the architecture,it wasn't top secret.
For me personally I am not patching my systems(at least at the firmware level). The risk outweighs the benefit. My laptop(Lenovo P50), and my personal servers(both run recent Intel Xeons) are not getting fixed for this stuff.
I haven't had a known security incident on any of my personal systems hardware or software since literally I think it was something like 1992, when my 486 computer at the time got the [STONED] virus. Though I don't recall it doing any damage. I don't remember if anti virus took care of it or what.
Professionally I haven't had a known security incident hardware or software on any of my equipment since 1997. I was running a small ISP, someone who had a legit shell account on one of my Linux servers decided to hack it. I was involved in software piracy back then so not everyone I knew was super trustworthy. Though they were detected within seconds (as I was logged in at the time, I detected it by them being stupid and firewalling my IPs from contacting that server, system was disconnected from the network within an hour or so and rebuilt).
I have assisted in a few security incidents of things that I had access to (but was not responsible for) though. Presently I manage more than 1,000 virtual servers and server hardware and networking and storage that run under them. So I have a decent amount of experience.
So yeah, my ~22 years of online experience, many of which running internet connected services in both personal and professional capacity makes me believe that the risk of this is far overblown for MOST people (exception is shared environments where you have untrusted workloads,e.g. public cloud providers, or high value targets).
The knee jerk reactions to most of these security things are just crazy. It would be different if there was an active exploit available, something that is networkable and can infect/spread/worm itself etc.
There's far more critical security related things to patch or secure from than this.
I believe the most vocal people talking about this stuff are more so the hard core AMD fans who want Intel to fail so AMD can rise up again. I can certainly understand that angle, though it's not going to happen.
One thing to keep in mind, if someone (say a state actor) really wants in, they will get in. Doesn't matter if you have all the patches, they will find a way in.
"For SPECTRE and Meltdown, there were two levels of mitigation, firmware and software. For Meltdown (IIRC), software mitigations were only partially effective; you needed a firmware update from your hardware vendor for complete prevention."
---
This is misleading. What you call 'firmware' is the microcode. This is CAN be "loaded into the CPU" by the BIOS at each boot, but it's typically done by the operating system (anyhow). For Intel and Linux, for example, the package is called "intel-microcode". Other mitigations are part of the kernel (Linux, Windows, etc.). Others again, get worked into compilers...
That said, if you are using "a typical" operating system, you do not need the fixes for your BIOS.
Your post also misleads. Loading the "spectre" firmware supplied by Intel caused some models of CPU to fail. Therefore, operating systems like Linux could not automatically apply the firmware and it was left to machine owners to do so manually via their machine vendor providing updated BIOS firmaware. See https://www.theregister.co.uk/2018/01/18/red_hat_spectre_firmware_update_woes/
That is from '18 Jan 2018'. It states that:
"Techies are scratching their heads after Red Hat pulled a CPU microcode update ..."
"...stalling on rolling out microcode patches after Intel admitted its firmware caused systems to fall over."
In other words: Intel had release a buggy microcode update, which caused problems. Therefore, some distributions didn't (temporarily) distribute it (until it got fixed).
(The same - buggy - microcode would cause the same problems when installed via BIOS, btw.)
I'm probably being ignorant, but as I understand it, Meltdown and Spectre arise because the processor speculatively executes code that would not be permitted to execute, with observable side effects.
So I don't think that particular issue has any motherboard-level ramifications. And neither did the OpenSSL issue. So likely this story doesn't cover motherboard manufacturers who, for all I know, have never been forced to work together?
I may be failing to think of the proper angle.
"So I don't think that particular issue has any motherboard-level ramifications. ...
I may be failing to think of the proper angle."
---
Yes and no. If you are using a 'modern' up-to-date operating system (Linux, BSD, Windows-10, Mac-OS) the mitigations are applied by the operating system. If, however, you want to run something 'out of the ordinary' (or old), which doesn't come with mitigations (OS/2;-) then loading the mitigations via the BIOS would apply them anyhow. Without the BIOS fixes, such a - Weirdo-OS - would be unprotected.
Then again, it has to be said that the current mitigations are far from perfect and likely don't really close even nearly all the holes...
I have two columns in front of me.
One of them is the time and costs spent across all my customers cleaning up viruses and malware caused by unpatched systems.
One of them is the time and costs spent across all my customers cleaning cleaning up messes caused by broken and misbehaving patches.
Guess which one is bigger.
There's also the manpower and downtime involved in just doing the patches, even if they're effective and functional. With Windows patching, considering it takes a crap about every other session, requiring me to Google obscure error numbers and deal with it, that's a non-trivial level of effort.
Not to mention that many a "urgent security update" seems to come bundled with some obscure "improvement" that turns out to be "enable a new way of monetizing the user".
Of course, the tech industry is just following the lead of legislatures everywhere with their "urgent national defense (and pork for selected districts)" bundling of laws.
That's Novel , Noble and Nobel Worthy, I Am Spartacus.
What Vast Eternal States of Play in Immaculate Bliss Await Late Entries ......with Stellar Surprise Rewards to Live AI BetaTest for Infant Quantum Communication Systems. ..... with Full Access to AIMaster Control Leverage Proofing Systems into All Streams of Realisation for Presentation. ....... Perfect Virgin Creation with New Worlds to Populate with Superb Humanities in Service of and Tendering to Angels and Angles of the Almighty is at least one place and space you gotta put on top of every bucket list of out of this world experiences to master/tempt with absolute command and remote obscured control.
Does anyone else have the semblance of a guaranteed failsafe Universal AIMaster Piloted Plan for Greater IntelAIgent Games Play as Default Security Protocol/Inescapable Immersion/Welcoming Embrace :-)
:-) I'll surely read all that again in the morning just to make doubly sure it made the perfect common sense it was meant to.
All patchable machines can now be patched thanks to
https://support.microsoft.com/en-gb/help/4465065/kb4465065-intel-microcode-updates
version 2 which landed (without fanfare) on 5/2/19 as a standalone. KB4346084 (depending on 1803), KB4100347 (last updated 8/1/19, finally giving Spectre v2 patching to older CPUs). 19H1 will (does if you are an Insider) contain an updated mcupdateGenuineIntel.dll and the Retpoline kernel to deal with performance penalties on pre-Skylake CPUs
OEM responses have been varied between good, lamentable and non-existant.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
