Intel have said they have the bugs mentioned in the following link under control . I hope they will be rolling out security downloads soon . Those who have a keen eye on the share market could do well to look at Intel shares at the moment . Just saying …
I haven’t looked at it in fine detail (too busy laughing) - but the impression I get is that not all CPU’s are affected, but a huge number are, probably ‘most’ - across a number of related architectures - and that the ones that are affected will never be ‘fixed’ as such, until you throw them out - the ‘fix’ as they call it seems more a workaround that will be a combination of kernel changes and firmware. So one point is, you’ll need to look to your hardware vendor for the firmware updates, and your operating system vendor for the kernel changes (Linux, Windows, MacOS, whatever …). Some additional complexity is added where some AV software make unsupported calls into (specifically) Windows kernel memory - so the Windows changes will ‘cause’ BSOD when the software hits the changes (that now block it). So Microsoft are not distributing the relevant Windows Updates to systems that don’t have a registry key set saying the AV software is ok with doing things by the book - so check with your AV vendor. I don’t believe there is any obvious evidence this has happened, you just don’t get the updates.
Linus Torvalds has described the fixes as ‘mitigations’ and has said they will cost at least 5% in performance … and in some cases applications will see performance hit in the double digits …
Intel’s blunder was to allow user programs to be able to gather hints about how the kernel address space is laid out. As discovered by Austria’s university researchers this summer, “Modern operating system kernels employ address space layout randomization (ASLR) to prevent control-flow hijacking attacks and code-injection attacks. While kernel security relies fundamentally on preventing access to address information, recent attacks have shown that the hardware directly leaks this information.”
ASLR is vital to today’s operating systems’ defense against malware. The Intel vulnerability isn’t so much a new hole as it is a way of making all those many existing attack methods against ASLR-defended operating systems much stronger.
The researchers’ solution was KAISER, a system for Linux kernel address isolation. In November, these patches were proposed for the Linux kernel. Realizing just how dangerous these attacks could be, the Linux kernel developers quickly started revising these patches.
Their solution, which amounts to more than 51 patches to date, separates the Linux kernel page tables kernel from the user space tables. Going forward, Linux will have two sets of memory page tables.
Besides making memory management more complicated, this also means many program instructions must keep switching between the two address spaces for every system call and for every hardware interrupt. This is what will slow down many, but not all, operating system functions and applications.
As LWN.net editor and Linux kernel developer Jonathan Corbet explained, “This is a fundamental change to how the kernel’s memory management works and is the sort of thing that one would ordinarily expect to see debated for years, especially given its associated performance impact.”
To say Linux developers were unhappy about this would be a massive understatement. When the set of fixes’ name was changed from KAISER to Kernel Page Table Isolation (KPTI), some of the suggested names were User Address Space Separation, prefix uass_ and Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix XXREMOVEDXX.
Angry they may be, but Linux had to be secured. Torvalds already merged in some early KPTI patches. The fixed code is in 4.14.11, which was released on January 3. Torvalds has also already placed the patched code in Linux 4.15. This new Linux release will be out in a few weeks. All these fixes will be backported to long-term support Linux kernels.
Linux users, especially those who run enterprise software on servers and the cloud, should ready themselves to do performance testing on the new release as soon as possible. Whether you run your application in a server room or any of the clouds – Amazon Web Services (AWS), Google Engine, Azure, and so on – you must adjust the number of server or container instances to maintain the speed and performance you demand from your programs and services.
Interesting stuff … (I removed one of the fix names quoted and replaced with X’s - you can work out the acronym )
The good thing about this vulnerability was it was found by honest types who privately warned the computer makers and intel in advance of releasing their findings to the public, this gave most makers time to write patches and repair the vulnerability before the nefarious types became aware of it.
When I heard about this vulnerability through the media I naturally wanted to check my systems and I found my systems had already been patched at their most recent automatic upgrade a few weeks ago. I haven’t noted any down grade of speed as has been suggested by some media pundits, but I don’t do processor intensive work just general everyday computing.
These bugs when discovered are always portrayed by the media and the industry experts as the ‘end of the world as we know it’ and yet they get patched and life goes on.
The undiscovered computer software/hardware bugs and vulnerabilities the “known unknowns” (as once famously quoted) are the real problem because if they are found by the nefarious types first and exploited for dishonest purposes have greatest risk of doing damage.
… and the lawsuits:
Interesting bits from the article:
Intel, for its part, has said it already has issued updates for the majority of processors introduced in the past five years. The company said by the end of next week it “expects to have issued updates for more than 90 percent of processor products introduced within the past five years”.
Well hopefully, since these exploits affect processors made by Intel since 1995, most people will have upgraded to a platform Intel will patch. Unclear whether Intel will release updates for CPU’s older than that - we’ll probably hear the ‘lifetime’ argument again (as per another Choice thread I saw recently). I still have CPU’s in the 5-10 year old range in daily use. There does appear to be a lot of selective reporting on this topic.
From the same article above:
Furthermore, Intel said that the security issues are not from the processor designs themselves, but in the approach that researchers used to compromise a system.
<cough>. The Titanic was unsinkable by design too, but the iceberg was to blame because of the approach it used (you know, floating, being hard, and being there in the first place, in the ocean, where icebergs are generally …).
“Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively,” the company said in a statement.
What I hear is “our butts are all hanging in the breeze, let’s band together to provide an industry-wide butt protection approach”.
Intel was informed by Google about the vulnerability in June and In November Intel CEO Brian Krzanich cashed out US$24 million worth of stock in the company, according to a report by Business Insider. Intel, for its part, told Business Insider that the sale was part of a standard stock-sale plan and had nothing to do with the disclosed chip vulnerability.
Indeed - selling stock when there’s a risk of it diving is a ‘standard plan’ - there’s other names you could call it as well
A couple of Intel references:
“Facts” … not sure what type of facts they are, but facts none the less.
shhhh - there’s people on this forum who aren’t convinced Google is ‘honest’
FWIW I think the risk to most of us is low if we follow the basics of keeping patched and making sure we have good security (AV, ad blocking, badgers, etc etc) and we pay attention … plenty of other articles about that.
How about this one? There seems some confusion on which AMD Athlons get bricked, but.
The thing is, it’s not a software bug so patching is really just a bandaid. The problem is that this issue has been built into the hardware. That should never have happened unless it was architecturally designed to do so. Makes you wonder why it was built in… a backdoor perhaps. Either way, Intel should be held accountable for this as it has happened in their design.
I also have to wonder why Spectre is thrown in with Meltdown… was that so intel didn’t take the full brunt?
Anyway, it would be good if the news started saying it for what it is… a hardware flaw and not a bug.
Thought would check today and see if the patch has been installed and when.
KB4056892 was installed on our Windows 10 PC on 4 January 2018…didn’t know it had been installed as there has been no discernible change in speed.
Don’t know why Athlon CPU PCs have been receiving this update as I was under the impression that Meltdown and Spectre related to Intel CPUs. Maybe there are some who tried to install the patch on Althon to see that the effect was or Microsoft did a blanket rollout…
AMD, Intel, & ARM all use predictive analysis and side caching to speed up the way code is processed in the CPU, hence why AMD CPUs are in the firing line for this vulnerability.
f you can predict successfully the next operation/s you can gain up to about a 30% speed improvement, not all operations are going to be a successful prediction and so the errant operations are flushed and the run starts from the last success. This patch stops this CPU operation prediction happening by implementing a software fix to this hardware problem and is why you will experience a performance hit that varies between 5% and 30%. Now most home PCs are not taxed by normal human interaction, in fact they are spending a lot of time waiting, so in general use most of us won’t notice an impact or it will be a very small one.
If you really push your CPU eg Video transcoding, Graphic rendering and other CPU intensive tasks you will notice the impact and we all hope that a hardware fix in the next lineup of CPUs will be forthcoming (hmmm maybe a case under ACL to get a new Chip and new Motherboard under consequential damages).
I guess it will all help with the planned obsolescence … probably fair to suggest this might go way further if companies were to care about chips considered obsolete …
But for now, it’s NVidia’s turn …
I can imagine there are probably numerous meetings around the globe with nervous management (flanked by lawyers and HR with additional NDA’s etc) asking whether their chip is vulnerable and ‘how long before they are onto us’
This bug / foobar classifies with the ‘incorrect operations’ that processors have been known to exhibit over time. Intel had a bad divider a few years ago and another manufacturer’s cpu would make a wrong computation if certain values were in specific registers, a specific instruction was issued and that instruction caused a memory access. They do circle their wagons and it can be very costly!
I have always been a RISC proponent. Reality is CISC chips are so complex it is amazing they don’t have more design errors than they do.
… and the F00F bug - linux kernels happily report that on boot if you don’t have ‘i’m soft and need a nice logo’ enabled.
You wonder how they ever get CISC to work. RISC did seem a more stable cpu platform and ‘nicer’ - The flavours of UNIX I’ve worked that sat on RISC always seemed more stable - I have no actual evidence to support that, just my perception. MIPS, AXP, PA-RISC (Of course the main reason HP-UX is so stable is the almost complete lack of change or innovation since the old testament … but there’s a place for dinosaurs, just like there is a place for single system image clustering and advance file system - sadly now both dead … but I digress). Linux changed all that, starting some 24 years ago !!! I feel old. Older when I think of RSTS et al …
I expect we’ll be seeing all sorts of stuff relating to Meltdown and Spectre for quite some time to come …
AMD are releasing fixes, according to this article: https://www.theverge.com/2018/1/11/16880922/amd-spectre-firmware-updates-ryzen-epyc
They seem to have been approving some overtime (so to speak) … easier for our Linux boxes …
When is a performance hit not a performance hit? when it’s not of course …
No need to schedule reboots of those pesky and unreliable windows servers anymore, Intel has the solution !!
That is reassuring. Essentially business as usual.
Quite an entertaining article - it had me with the quote:
After a Saturday night drinking with friends, they got to work the next day, each independently writing code to test a theoretical attack on the suspected vulnerability, sharing their progress via instant message.
But before we blame the new flaw discovery on alcohol consumption, or Austrians for that matter, the article goes on to describe what it calls the “bizarre confluence” …
Yet when Intel responded to the trio’s warning—after a long week of silence—the company gave them a surprising response. Though Intel was indeed working on a fix, the Graz team wasn’t the first to tell the chip giant about the vulnerability. In fact, two other research teams had beaten them to it. Counting another, related technique that would come to be known as Spectre, Intel told the researchers they were actually the fourth to report the new class of attack, all within a period of just months.
Imagine the big chief addressing the board meeting at Intel - “another bl**dy team has found that exploit! we might have to do something! get the lawyers and the marketing guys in here for a meeting this 'arvo - I’ll be back after lunch, need to go sell some stock …”
I wonder when Intel really started working on a fix …
The article goes on with some interesting analysis, some from Mr Security/Schneier himself …
Looks like they’ve got their work cut out for them…
Gee, I’m so pleased we spent all that money on anti-virus software.
yay … or something …