Problems? See this thread at archive.org.)
How to Check if Your PC Is Protected Against Meltdown and Spectre
https://www.howtogeek.com/338801/how-to-check-if-your-pc-is-protected-against-meltdown-and-spectre/
EDIT: Here are my results, but i dont know what it means, can anybody interpret.
https://i.imgur.com/KakCwpU.png
John.
-
-
-
actually it may be this
http://www.zdnet.com/article/window...-if-you-havent-got-them-blame-your-antivirus/
but...my antivirus (ESET NOD32) is updated and should fully support latest windows 10 update, wth are they smoking?
Eset shows me only optional updates, if i put the notification of updates on critical it shows nothing.
![[IMG]](images/storyImages/Z8OII9S.png)
Last edited: Jan 9, 2018 -
-
No cheating this time...i found out why it wasn't working as i expected. Since i like to check here what new updates are coming without having windows download them first, i have set my "active hours" in windows update on an insane timeframe, guess what? It was blocking it
, hopefully i'll receive the update...only two received till now.
Now i can go back to my angle in shame for not thinking about it till now.
Edit:
No trace of microsoft patch for these vulnerabilities, lmao.Last edited: Jan 9, 2018 -
-
Smart move from Intel. Wouldn't be good advertising with launch of 8700K and the new flaws same time early Q1 2018
Btw.
Microsoft Says Windows 10 PCs Running Haswell Or Older Intel CPUs Can Expect Significant Slowdowns Post-Spectre Patch-hothardware.com
Now for some good news and bad news. We'll get the good news out of the way first and tell you that Variant 1 and Variant 3 will have "minimal performance impact" for users. However, bad news comes with the revelation that the mitigation protocols put in place with Variant 2 can have a profound effect on system performance, especially for users running Haswell (or older) processors on Windows 10 and Windows Server customers (regardless of what processor being used).
- Windows 10 PCs with Skylake, Kaby Lake or anything newer may see "single-digit slowdowns", but for most users the impact will be minimal.
- Windows 10 PCs with Haswell or older processors will see "more significant slowdowns" and Microsoft notes that a segment of customers may "notice a decrease in system performance”.
- Windows 7 and Windows 8 PCs powered by Haswell or older processors will see a "decrease in system performance" for "most users".
Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.
-
Meltdown, Spectre bug patch slowdown gets real – and what you can do about it
Chip flaw fixes not so insignificant after all
By Thomas Claburn in San Francisco 9 Jan 2018 at 00:45
" Analysis Having shot itself in the foot by prioritizing processor speed over security, the chip industry's fix involves doing the same to customers.
The patches being put in place to address the Meltdown and Spectre bugs that affect most modern CPUs were supposed be airy little things of no consequence. Instead, for some unlucky people, they're anchors.
Having helped find the flaws, Google insisted the software fixes that have begun to appear "introduce minimal performance impact," and insisted the performance hit will diminish over time.
Intel said as much in its statement, claiming "any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time."
That may be true eventually, thanks in part to a processor feature called Processor-Context ID, or PCID. But more on that later.
At the moment, the speed consequences of patching these bugs is significant enough to elicit attention and complaints. To be clear: we here at El Reg highly recommend you install the CPU security bug patches as soon as possible. We just want folks – particularly cloud subscribers and IT admins – to be aware of the effects.
In other words, if you're seeing crap performance after applying these fixes, look at your kernel configuration and get PCID enabled – if the hardware feature is present in your chipset. Windows should, for what it's worth, use PCID if it's provided by the processor."While most casual desktop users and gamers won't notice any prolonged slowdown, or any performance hit at all, people running IO or system-call intensive software, such as databases on backend servers, may notice the difference.
Red Hat has clocked the patch performance impact as ranging from one to 20 per cent.
Epic Games on Friday explained the cause of recent login and stability issues experienced by its players, noting: "All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability."
The company, which relies on AWS servers, posted a screenshot of a graph depicting a spike in CPU utilization after a host was patched. The Register asked Epic to elaborate on its findings, but a spokesperson said the developer had nothing further to add at the moment.
Discussions on the mailing list for Lustre, a parallel distributed filesystem, described slowdowns ranging from 10 per cent to as high as 45 per cent for certain IO intensive applications.
"We found terrible performance on the test system with zfs+compression+lustre," wrote Arman Khalatyan of the Leibniz Institute for Astrophysics Potsdam in a memo on Monday.
On Reddit, a Monero coin miner reported a slowdown of about 45 per cent after applying the Meltdown patch. On that thread, another person cited a hash rate decrease of 10 to 15 per cent.
Quora, which relies on AWS, on Saturday said it is "facing a slowdown due to the patch applied by AWS for Intel's Meltdown and Spectre issues."
Via Twitter, Francis Wolinski, a data scientist with Paris-based Blueprint Strategy, noted that Python slowed significantly (about 37 per cent) after applying the Meltdown patch for Windows 7.
Also via Twitter, Ian Chan, director of engineering for analytics firm Branch Metrics, described CPU utilization increases of five to 20 per cent after the Meltdown patch was applied to the AWS EC2 hypervisor handling its Kafka instances.
Amazon customers have sent The Register several screenshots of CPU utilization showing spikes similar to those that have been publicly discussed. Before the weekend, Amazon confirmed the updates will ding AWS virtual-machine performance to some degree, albeit with no "meaningful performance impact for most customer workloads" expected, apparently.
![[IMG]](images/storyImages/aws_cpu.jpg)
Soar ... An example AWS CPU utilization spike after installing CPU flaw security patches (Click to enlarge)
These figures are in keeping with the estimates first reported by The Register, a performance hit of roughly five to 30 per cent, with the caveat that any such results are highly variable and depend on a number of factors such as the workload in question and the technology involved.
El Reg's sister site The Next Platform estimated that the amount of computing value lost to the slowdown amounts to $6 billion annually.
These delays are largely the consequence of Meltdown patches, which on Linux enforce separation between the kernel and user virtual memory address spaces through Kernel Page Table Isolation, or KPTI.
Beyond Linux, Microsoft has patched Windows Server 2008 R2, 2012 R2, and 2016, among other flavors of its operating system. Apple has also mitigated Meltdown and Spectre in iOS and macOS.
Spectre mitigations – which involve recompiling software with countermeasures such as Google's retpoline as well as microcode updates depending on the processor model – have just begun to appear. Though considered only partial fixes for a problem that will take some time to sort out, they're nonetheless expected to affect performance, too (beyond knackering some AMD PCs if you're using Windows).
PCID
If there's a bright side to all this, it's that the PCID feature in Intel's x86-64 chips since 2010 can reduce the performance hit from patching Meltdown. (If you have a 32-bit system, you're on your own.)
Remediating Meltdown – which is present in modern Intel processors – involves enforcing complete separation between user processes' virtual memory spaces and the kernel's virtual memory areas. Rather than map the kernel into the top portion of every process's virtual memory space where it remains invisible unless required to handle an interrupt or system call, the kernel is moved to a separate virtual address space and context. This fix prevents malware from exploiting the Meltdown CPU bug to read kernel memory from user mode, and is referred to as Kernel Page Table Isolation.
Switching back and forth between these contexts – from the user process context to the kernel context and back to the user process – involves reloading page tables, one set describing the user process and another describing the kernel. These tables map the process or kernel's virtual memory to physical blocks of RAM or swap space.
These context switches from user process to kernel to process not only takes time, it also flushes any cached virtual-to-physical memory translations, all in all causing a performance hit, particularly on workloads that involve a lot of IO or system calls. But with PCID, there's no need to flush the entire translation lookaside buffer (TLB) cache on every context switch as selected TLB entries can be retained in the processor.
PCID first saw Linux support in the 4.14 kernel released in November 2017, and thus it's not necessarily available by default with every Linux instance, particularly on virtual machines.
In a Google Groups post on Sunday, Gil Tene, CTO and cofounder of enterprise Java biz Azul Systems, said PCID has become critical both for security and performance on Intel's x86 platform. But he observed that it isn't present on many of the virtualized Linux instances he's looked at.
Most KVM guests – kernel-based virtual machines – don't include PCID, according to Tene, while most VMware guests do. And about half of the AWS instances he looked at don't have it.
"You REALLY want PCID in your processor," wrote Tene. "Without it, you may be running insecurely (Meltdown fixes turned off by default), or you may run so slow you'll be wishing for a security intrusion to put you out of your misery."
It gets worse: Microsoft’s Spectre-fixer wrecks some AMD (Athlon) PCs
KB4056892 is not your friend if you run an Athlon
By Simon Sharwood, APAC Editor 8 Jan 2018 at 06:30
https://www.theregister.co.uk/2018/01/08/microsofts_spectre_fixer_bricks_some_amd_powered_pcs/
" UPDATE Microsoft’s fix for the Meltdown and Spectre bugs may be crocking AMD-(Athlon) powered PCs.
A lengthy thread on answers.microsoft.com records numerous instances in which Security Update for Windows KB4056892, Redmond’s Meltdown/Spectre patch, leaves some AMD-(Athlon-)powered PCs with the Windows 7 or 10 startup logo and not much more.
Users report Athlon-powered machines in perfect working order before the patch just don’t work after it. The patch doesn’t create a recovery point, so rollback is little use and the machines emerge from a patch in a state from which rollback is sometimes not accessible. Some say that even re-installing Windows 10 doesn’t help matters. Others have been able to do so, only to have their machines quickly download and install the problematic patch all over again …
Those who have suffered from the putrid patch will therefore need to disable Windows Update as just about the first thing they do. Keeping the machine off networks seems a helpful precaution.
The Register cannot find a Microsoft response in the thread, a reasonable lack-of-reaction given many of the complaints accrued over the weekend.
AMD CPUs are immune to Meltdown but susceptible to Spectre, but the silver lining in that cloud has been dirtied by the patch problem. ®
UPDATE, January 10th: AMD's been in touch to say it is "... aware of an issue with some older generation processors following installation of a Microsoft security update that was published over the weekend. AMD and Microsoft have been working on an update to resolve the issue and expect it to begin rolling out again for those impacted shortly."Last edited: Jan 10, 2018 -
-
-
OK, POC... made myself an escape route in case I don't like it and prefer to go back to an "insecure" system that runs better. Applied the Redmond Mafia's latest patch and updated to new ASUS BIOS with old BIOS and Macrium image on standby to undo the damage as necessary. So far, so good... no basis for the drama. Yes, 4K NVMe is a tiny bit slower, but not enough to even care as far as I can tell. Certainly will not affect my perception of performance or any of the benchmarks I care about with a tiny bit slower 4K performance. Jury is still out on wPrime, Cinebench and 3DMark stuff. If I'm not happy with those things, it's gone and everyone will be aware of my displeasure, LOL. Haven't done anything on the P870DM-G in terms of the OS, but Brother @Prema has me testing the BIOS security fixes for that one. I am not benching it, so nothing to report on that until the GTX 1080 mod is done.
Worry warts that don't bench, have at it. Nothing to lose any sleep over.Attached Files:
alexhawker, Robbo99999, jclausius and 5 others like this. -
-
-
I'm not sure. I will have to check tomorrow. I just got through setting it up. Time for Mr. Fox to go night-night.
Probably right... those losers are snakes and I trust them about as far as I can throw them. They've always got a shenanigan in their back pocket to try to manipulate Windoze OS X adoption. Doing right by customers is just not part of their moral fabric.Last edited: Jan 10, 2018 -
-
Triple Meltdown: How so Many Researchers Found a 20-year-old Chip Flaw at the Same Time...
The vulnerabilities behind the devastating Meltdown and Spectre attacks have existed for decades. Four groups of researchers independently found them within mere months of each other.
https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/
"There’s no reason someone couldn’t have found this years ago instead of today." - Paul Kocher, Cryptography Research
"ON A COLD Sunday early last month in the small Austrian city of Graz, three young researchers sat down in front of the computers in their homes and tried to break their most fundamental security protections.
Two days earlier, in their lab at Graz's University of Technology, Moritz Lipp, Daniel Gruss, and Michael Schwarz had determined to tease out an idea that had nagged at them for weeks, a loose thread in the safeguards underpinning how processors defend the most sensitive memory of billions of computers. 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.
That evening, Gruss informed the other two researchers that he'd succeeded. His code, designed to steal information from the deepest, most protected part of a computer's operating system, known as the kernel, no longer spat out random characters but what appeared to be real data siphoned from the sensitive guts of his machine: snippets from his web browsing history, text from private email conversations. More than a sense of achievement, he felt shock and dismay.
"It was really, really scary," Gruss says. "You don’t expect your private conversations to come out of a program with no permissions at all to access that data."
From their computers across the city, Lipp and Schwarz soon tested proof-of-concept code they'd written themselves, and could see the same results: Lipp remembers seeing URLs and file names materializing out of the digital noise. "Suddenly I could see strings that shouldn't belong there," he says. "I thought, 'Oh God, this is really working.'
Graz University of Technology researchers (from left) Daniel Grüss, Moritz Lipp, and Michael Schwarz represent just one team of four that independently discovered the same two-decade-old critical security flaw in processors within months of one another.
That night, none of the three Graz researchers slept more than a few hours. The next day, they sent a message to Intel warning them of a potentially industry-shaking flaw in their chips. They'd found a gap in one of the most basic security defenses computers offer: that they isolate untrusted programs from accessing other processes on the computer or the deepest layers of the computer's operating system where its most sensitive secrets are kept. With their attack, any hacker who could run code on a target computer could break the isolation around that low-privilege program to access secrets buried in the computer's kernel like private files, passwords, or cryptographic keys.
On cloud computing services like Amazon Web Services, where multiple virtual machines coexist in the same physical server, one malicious virtual machine could peer deeply into the secrets of its neighbors. The Graz team's discovery, an attack that would come to be known as Meltdown, proved a critical crack in one of computing's most basic safeguards. And perhaps most troubling of all, the feature they had exploited was introduced into Intel chips in the mid-1990s. The attack had somehow remained possible, without any apparent public discovery, for decades.
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.
"As far as I can tell it’s a crazy coincidence," says Paul Kocher, a well-known security researcher and one of the two people who independently reported the distinct but related Spectre attack to chipmakers. "The two threads have no commonality," he adds. "There’s no reason someone couldn’t have found this years ago instead of today."
Quadruple Collision
In fact, the bizarre confluence of so many disparate researchers making the same discovery of two-decade-old vulnerabilities raises the question of who else might have found the attacks before them—and who might have secretly used them for spying, potentially for years, before this week's revelations and the flood of software fixes from practically every major tech firm that have rushed to contain the threat.
The synchronicity of those processor attack findings, argues security researcher and Harvard Belfer Center fellow Bruce Schneier, represents not just an isolated mystery but a policy lesson: When intelligence agencies like the NSA discover hackable vulnerabilities and exploit them in secret, they can't assume those bugs won't be rediscovered by other hackers in what the security industry calls a "bug collision."
The Meltdown and Spectre incident isn't, after all, the first time major bugs have been found concurrently. Something—and even Schneier admits it's not clear what—leads the world's best security researchers to make near-simultaneous discoveries, just as Leibniz and Newton simultaneously invented calculus in the late 17th century, and five different engineers independently invented the television within years of one another in the 1920s.
"It's weird, right? It’s like there’s something in the water," says Schneier, who last summer co-authored a paper on vulnerability discovery. "Something happens in the community and it leads people to think, let’s look over here. And then they do. And it definitely occurs way more often than chance."
So when the NSA finds a so-called zero-day vulnerability—a previously unknown hackable flaw in software or hardware—Schneier argues that tendency for rediscovery needs to factor into whether the agency stealthily exploits the bug for espionage, or instead reports it to whatever party can fix it. Schneier argues bug collisions like Spectre and Meltdown mean they should err on the side of disclosure: According to rough estimates in the Harvard study he co-authored , as many as one third of all zero-days used in a given year may have first been discovered by the NSA.
"If I discover something lying dormant for 10 years, something made me discover it, and something more than randomly will make someone else discover it too," Schneier says. "If the NSA discovered it, it’s likely some other intelligence agency likely discovered it, too—or at least more likely than random chance."
Speculative Speculation
While some elements of Meltdown and Spectre's four-way bug collision—a bug pile-up may be a better description—remain inexplicable, some of the researchers followed the same public breadcrumbs to their discoveries. Most prominently, security researcher Anders Fogh, a malware analyst for German firm GData, in July wrote on his blogthat he had been exploring a curious feature of modern microprocessors called speculative execution. In their insatiable hunger for faster performance, chipmakers have long designed processors to skip ahead in their execution of code, computing results out of order to save time rather than wait at a certain bottleneck in a process.
Perhaps, Fogh suggested, that out-of-order flexibility could allow malicious code to manipulate a processor to access a portion of memory it shouldn't have access to—like the kernel—before the chip actually checked whether the code should have permission. And even after the processor realized its mistake and erased the results of that illicit access, the malicious code could trick the processor again into checking its cache, the small part of memory allotted to the processor to keep recently used data easily accessible. By watching the timing of those checks, the program could find traces of the kernel's secrets.
Fogh failed to build a working attack, due to what other researchers now say were quirks of his testing setup. But Fogh nonetheless warned that speculative execution was likely a "Pandora's box" for future security research.
Still, Fogh's post hardly sounded alarms for the broader hardware security research community. It was only months later that the researchers at the Graz University of Technology started to closely consider his warnings. Their first real clue came instead from the Linux kernel mailing list: In October, they noticed that developers from major companies including Intel, Amazon, and Google were all suddenly interested in a new defensive redesign of operating systems, called KAISER, that the Graz researchers had created, with the goal of better isolating the memory of programs from the memory of the operating system.
The Graz researchers had intended KAISER to solve a far less serious issue than Meltdown or Spectre; their focus was on hiding the location of a computer's memory from malicious, not necessarily blocking access to it. "We felt happy," Lipp remembers. "People were interested in deploying our countermeasures."
Soon, however, developers on the mailing list began to note that the KAISER patch could slow down some Intel chips by as much as five to 30 percent for some processes—a far more serious side effect than the Graz researchers had found. And yet, Intel and other tech giants were still pushing for the fix.
"There must be something bigger here," Lipp remembers thinking. Were the tech firms using KAISER to patch a secret, more severe chip-level flaw? Only then did he and the other Graz researchers think back to Fogh's failed speculative execution attack. When they decided to try it themselves, they were shocked when their slightly tweaked implementation of Fogh's technique worked.
They also weren't alone. Just weeks earlier, by chance, researcher Thomas Prescher at Dresden, Germany security firm Cyberus had finally gotten around to testing Fogh's method. "I had looked at it half a year ago and found the ideas very interesting, but at some point I just forgot about it." Prescher says. "In November, I came across it again by chance and just decided to try it. I got it to work very, very quickly."
In the end, the Cyberus and Graz researchers reported their work to Intel within days of each other in early December. Only after Intel responded to each of the researchers' bug reports in the middle of that month did they learn that someone had independently discovered and reported their Meltdown attack months prior—as well as the distinct speculative execution attack known as Spectre. That warning came from Project Zero, Google's elite team of bug-hunting hackers. In fact, Project Zero researcher Jann Horn had found the attack in June—weeks before Anders Fogh's blog post.
Starting From Zero
How did Horn independently stumble on the notion of attacking speculative execution in Intel's chips? As he tells it, by reading the manual.
In late April of last year, the 22-year-old hacker—whose job at Project Zero was his first out of college—was working in Zurich, Switzerland, alongside a coworker, to write a piece of processor-intensive software, one whose behavior they knew would be very sensitive to the performance of Intel's chips. So Horn dived into Intel's documentation to understand how much of the program Intel's processors could run out-of-order to speed it up.
He soon saw that for one spot in the code he was working on, the speculative execution quirks Intel used to supercharge its chip speed could lead to what Horn describes as a "secret" value being accidentally accessed, and then stored in the processor's cache. "In other words, [it would] make it possible for an attacker to figure out the secret," Horn writes in an email to WIRED. "I then realized that this could—at least in theory—affect more than just the code snippet we were working on, and decided to look into it."
By early May, Horn had developed that technique into the attack that would come to be known as Spectre. Unlike Meltdown's more straightforward abuse of the processor, Spectre leverages speculative execution to trick innocent programs or system processes on a computer into planting their secrets in the processor's cache, where they could then be leaked out to a hacker performing a Meltdown-like timing attack. A web browser, for instance, could be manipulated into leaking a user's browsing history or passwords.
Spectre is harder for attackers to exploit than Meltdown, but also far more complex to fix. It also works not only in Intel chips, but across ARM and AMD chips too, an even thornier and longer-term problem for the industry. Horn reported his findings to the chipmakers on June 1. And as he continued to explore speculative execution's other possibilities, he found and reported the Meltdown attack to Intel three weeks later.
Finally, there would be one more coincidence in the storm of bug collisions around Meltdown and Spectre. Just around the time that Horn was beginning to test his attacks, Paul Kocher was starting a sabbatical from the San Francisco-based company he'd founded, Cryptography Research. He wanted time, in part, to explore a broad issue he saw in computer security: the increasingly desperate drive to squeeze ever-greater performance out of microchips at all costs—including, perhaps, the cost of their fundamental security.
At a cryptography and hardware conference in Taipei last September, Kocher's former colleague Mike Hamburg raised suspicions about speculative execution. Kocher was immediately determined to prove the problem. "It wasn't so much of an 'aha' moment as an an 'eww' moment," Kocher says of the realization that led him to the same attack method. "As soon as I started to look at speculative execution, it was pretty clear to me as a security person that this as a really bad idea."
Not long after he'd returned from Taipei, Kocher had coded a working exploit of his own—with no knowledge that Google's Horn had found exactly the same decades-old issue just months earlier.
Outlier or Telling Anecdote?
For Kocher, the key question isn't how so many researchers stumbled onto the same class of attack at roughly the same time. It's how the attacks remained undiscovered for so long—or whether they were in fact discovered, and used to hack unwitting targets in secret.
"If you asked me whether intelligence agencies found this years ago, I would guess certainly yes," Kocher says. "They have some of the world’s best efforts at these sorts of things. It would be quite likely they would have noticed. And if they found something like this, as long it's yielding good intelligence, they don’t tell anyone."
"It's not just the NSA," he adds. Other state-sponsored hackers likely have the skills—and had the time—to have potentially found the Spectre and Meltdown attacks, too.
On Friday, White House cybersecurity coordinator Rob Joyce, a former senior NSA official, told The Washington Post that the NSA didn't know about Spectre and Meltdown and had never exploited the flaws. Joyce has also touted a move to reveal more about the NSA's rules for disclosing vulnerabilities it finds, a policy known known as the Vulnerabilities Equities Process.
Despite the almost uncanny anecdotal evidence for bug rediscovery that Spectre and Meltdown represent, it's far from clear just how common that phenomenon has become. The Harvard Study co-authored by Bruce Schneier, for one, examined a trove of bug report data containing 4,300 vulnerabilities. Fourteen percent of Android vulnerabilities were reported again within just 60 days of their initial discovery, and around 13 percent of Chrome bugs. "For the NSA, holding onto vulnerabilities is way more dangerous than you’d think, given the raw numbers," Schneier says.
But another study released last year by the RAND corporation, which looked at bugs from an unnamed research organization, found only a 5.7 percent chance that a given bug would be found again and reported within a year—although the study didn't account for other, secret bug discoveries.
Lillian Ablon, one of the RAND study's authors, sees the Spectre and Meltdown rediscoveries not as a broad sign that all bugs are found several times over, but that trends in computer security can suddenly focus many eyes on a single, narrow field. "There may be bug collisions in one area, but we can’t make the grand statement that bug collisions happen all the time," she says. "There will be codebases and classes of bugs where no attention exists."
Paul Kocher argues the real lesson, then, is for the security research community not to follow in each others' footsteps but to find and fix bugs in the obscure code that rarely attracts widespread attention.
"Throughout my career, whenever I've looked somewhere there isn’t a security person looking, I find something nasty and unpleasant there," Kocher says. "The shocker for me is that these attacks weren't discovered long ago. And the question that I struggle with and fear is, how many other things like this have been sitting around for 10 or 15 years?"
More Meltdown
- Meltdown and Spectre are as devastating as they are complicated. Here's how they work, and why they're such a menace.
- Fortunately, some important steps have already been taken to fix the problem—but a full solution is still years away.
- This is also the latest in a string of rough security lapses for Intel, including a recent, critical vulnerability in its Management Engine.
"Something happens in the community and it leads people to think, let’s look over here. And then they do." - Bruce Schneier, Harvard Belfer Center
"If you asked me whether intelligence agencies found this years ago, I would guess certainly yes." - Paul KocherLast edited: Jan 10, 2018 - Meltdown and Spectre are as devastating as they are complicated. Here's how they work, and why they're such a menace.
-
Don't forget that 8700K or last gen Intel i7 chips have less slowdowns than older chips included 6700K/7700K. I expect Intel improved with M$ before the launch of Coffee. But not enough to avoid it total.
Edit. 4K read = 5% slower - 4K Write = 28% slower on DiskMark. Disgusting!!
From my older post #44
Last edited: Jan 10, 2018 -
-
-
Intel, Microsoft confess: Meltdown, Spectre may slow your servers
It's getting hard to deny all the new and sluggish benchmarks
By Thomas Claburn in San Francisco 10 Jan 2018 at 05:02
https://www.theregister.co.uk/2018/...t_meltdown_and_spectre_may_slow_servers_down/
"After spending last week insisting that the performance impact of fixing the Meltdown and Spectre CPU vulnerabilities "should not be significant," Intel on Tuesday tried to maintain that stance even as it acknowledged SYSmark tests assessing post-patch slowdowns ranging from two per cent to 14 per cent.
Reiterating that typical consumer and business usage – reading email, opening documents, and accessing digital photos – should not exhibit any performance hit from remediation, Intel said, "8th Generation Core platforms with solid state storage will see a performance impact of six per cent or less."
That's a dubious carve-out because so much consumer and business computing relies on cloud-based servers, which, as The Register reported on Monday, have exhibited slower response times and increased CPU utilization arising from the fixes rolled out by affected vendors.
Intel's effort to minimize the consequences of the two flaws looks a lot like a preemptive defense against litigation.
It's too late for that. At least eight lawsuits against Intel have been filed since The Register first reported the flaws on January 2."
"Chipzilla may also be concerned about scrutiny from the Securities and Exchange Commission: CEO Brian Krzanich sold of most of his company stock in November, several months after Intel was made aware of the Meltdown and Spectre vulnerabilities. Even if the sale was made as part of a pre-established plan, the timing of the sale looks terrible.
There you have it: security or performance. Choose one."Too blunt, time to punt
Also hard on the eye is the decision by Carnegie Mellon University's (CMU) Software Engineering Institute to water down CERT/CC's initial Meltdown/Spectre vulnerability notice, as it is easily interpreted as an attempt to dampen concerns.
CMU's initial advice, issued on January 3, advised replacing CPUs because the "underlying vulnerability is primarily caused by CPU architecture design choices."
A revision that appeared the following day removed that recommendation even though others have said as much. For instance, Daniel Genkin, a postdoctoral researcher who helped uncover the flaws, told The Registerthat a lasting fix requires hardware redesign.
In a phone interview, The Register asked Art Manion, vulnerability analysis technical manager at the CERT division of CMU's Software Engineering Institute and the author of Vulnerability Note VU#584653, whether Intel had pressured CERT to revise its language.
Manion acknowledged that vendors including Intel had been in contact as part of the disclosure process, but he insisted the initial wording and the revision came from the CERT Coordination Center rather than elsewhere.
In this particular instance, he said, CERT was not involved in the pre-public coordination of the disclosure. And once the story broke, "we were scrambling," he said.
Initially, he said, it looked like a problem tied to hardware. Upon further analysis and communication with vendors, he said, "We decided the language was too blunt."
Hardware plays a role, he said, "but one of the tenets of our advice is to provide actionable information."
In other words, telling the world to toss the bulk of the processors produced in the past decade just wasn't a realistic response.
The Register asked Intel whether it had requested more moderate language.
In an email, an Intel spokesperson said, "I can confirm that we were in touch with CERT. I don’t have anything to add to that."
Chipzilla's terrifying response: a new branch on the org chart
While Intel would have the outside world overlook the whole affair, the chipmaker has reportedly reorganized internally to focus more on security. On Monday, The Oregonian reported that Krzanich has shuffled top executives to create a new internal security group called Intel Product Assurance and Security, headed by human resources head Leslie Culbertson.
In a related, belated recognition of the value of security, Intel introduced its first bug bounty program for its own products in March last year.
In any event, Intel's downplaying of meaningful consequences from Meltdown and Spectre appears to have become unsustainable after Red Hat last week said the impact of patches ranged from 1 to 20 per cent in its benchmarks and Microsoft on Tuesday said something similar.
Microsoft did not release specific benchmark numbers and declined to provide them to The Register, through it said it would release results once the tests are complete.
However, in a blog post Tuesday, Terry Myerson, president of Microsoft's Windows and device group, did confirm varied degrees of delay, depending on the hardware and software involved.
On Windows 10 PCs with Skylake, Kabylake or newer CPUs, the effect of vulnerability mitigation is minimal. But with Windows 10 running on older hardware, Myerson said, "we expect that some users will notice a decrease in system performance."
For users of Windows 8 and Windows 7, Myerson said, "we expect most users to notice a decrease in system performance."
For Windows Server, Myerson suggested, it could be worse still, with IO-intensive applications showing "a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance."
In fact, the impact is significant enough in Windows Server customers that Myerson suggests dropping shields for speed. He advises those running Windows Server "to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment."
How are the shares, Bry? Intel chief cops to CPU fix slowdowns
Don't worry, Chipzilla is 'working tirelessly' to resolve the issue
https://www.theregister.co.uk/2018/01/09/intel_boss_ces_keynote_spectre/
IBM’s complete Meltdown fix won’t land until mid-February
POWER CPU patches available now or next week, AIX and i OS fixes are more than a month off
By Simon Sharwood, APAC Editor 10 Jan 2018 at 05:58
https://www.theregister.co.uk/2018/...ctre_patches_not_arriving_until_mid_february/
IBM melts down fixing Meltdown as processes and patches stutter
RHEL servers croaking, reporting in Excel, customer docs in signoff limbo
https://www.theregister.co.uk/2018/01/09/ibm_melts_down/
CPU bug patch saga: Antivirus tools caught with their hands in the Windows cookie jar
You're fondling our kernel wrong, grumbles Microsoft
https://www.theregister.co.uk/2018/01/09/meltdown_patch_anti_malware_conflict/
Amazon: Intel Meltdown patch will slow down your AWS EC2 server
Sysadmins notice performance dip amid security fix rollout. Not everyone hit hard. YMMV etc
https://www.theregister.co.uk/2018/01/04/amazon_ec2_intel_meltdown_performance_hit/Last edited: Jan 10, 2018 -
-
Just ran the Ashampoo Spectre Meltdown CPU Checker and it says my CPU is vulnerable even though I installed the latest ME Firmware a while back. so is MSI going to release a new BIOS to fix this or what?
![[IMG]](images/storyImages/Ashampoo_Spectre_Meltdown_CPU_Checker.png)
What is the difference between Spectre and Meltdown? -
-
-
It's a painful mess pretty much everywhere, earlier I am sure it was for those with earlier notice and already pushed through, it's going to continue like this for a while, with more "fixes" arriving over time.
Intel CPU Bug - Meltdown and Spectre - KernelCare and CloudLinux
https://www.cloudlinux.com/cloudlinux-os-blog/entry/intel-cpu-bug-kernelcare-and-cloudlinux
Here's the saga at CloudLinux - a nice summary from initial thoughts upon discovery to now, to be read from bottom to top - oldest to newest.
"Update [Jan 10, 2018 5:21am PT]
Original Story:KernelCare Update -- Sometimes optimizm is a good thing. Sometimes it drives you into attempting something "nearly" imposible, and you spend much more time than you expect, and still don't see the end of the road.
We are still working on the patches, still fighting bugs. A lot of them are quite elusive. It seems that it might be one of those projects where last 10% of the job takes 90% of the work. We made virtually no progress since yesterday. Only few bugs were fixed, and several new bugs were detected. Given that we have one shot at this, and if we get it wrong, the server will crash -- it might take us long time.
I was hopeful that we will be able to pass this stage much quicker - but now it is obvious it is not going to happen. We will continue working, and trying to solve these problems asap. Yet, realistically -- as of now Friday is the best case ETA, and it can easily spill over to the next week
I appologize for wrong ETA, major delays with this patch and any inconvenience it might have caused.
Update [Jan 9, 2018 5:40pm PT]
KernelCare update -- We are very close, and now we are hitting small(er) bugs. Yet, realistically -- it will take us at least another day before we release. There is just too much code/to many places where bugs appear.
CloudLinux update -- We will release new CL6 & CL7 kernels either today or tomorrow that should fix some of the issues people are having
Update [Jan 8, 2018 6:20pm PT]
KernelCare update - we still don't have a build that doesn't crash right away, but we believe we are getting close. Yet, we have to shift most likely release to tomorrow, with possibility it will shift even further to Wednesday. Sorry about all the delays. We are doing the best we can.
Update [Jan 7, 2018 4:45pm PT]
Last update for the day. We still don't have a KernelCare patchset build, but most components needed are there. Re-addressing of existing processes seems to work (that was our main worry). We are hopeful to have KC patches tomorrow, but given that we still don't have a build, tells me that it might be pushed to Tue before we will start releasing them.
I am very sorry about the delays. We are working full force, and my team who I am very proud off, is doing excellent job. Yet, the complexity of the problem is so high that it is very hard to predict exact timeline.
Update [Jan 7, 2018 9:35am PT]
We received a number of complains about CloudLinux 6 kernels. Most of them are related to Xen, but some are not. We traced some of them to upstream patches (CentOS kernels having similar issues).
We don't have solution for it right now. I would recommend people experiencing this issues to move to hybrid kernel: https://docs.cloudlinux.com/index.html?hybrid_kernel.html
It allows to run CloudLinux 7 kernel on CloudLinux 6 servers, and we haven't had any reports regarding it.
We don't have any KernelCare updates yet. We are still trying to do first build of patches today, but yet to be ready for that so far.
Update [Jan 6, 2018 7:55am PT]
KernelCare updates:
As we are starting to piece the code together, we are are starting to hit first snags. So far nothing major, but today is no longer probable. We are still shooting for Sunday/Monday for first releases for EL7 (RedHat/CentOS/CloudLinux 7) releases.
Note: This is still maybe Few major things are yet to be merged (like pgd_realloc responsible for moving exisitng processes to new addressing scheme)
Update [Jan 6, 2018 7:10am PT]
CloudLinux 6 kernels are moved to production.
# yum clean all && yum update kernel-firmware && yum install kernel-2.6.32-896.16.1.lve1.4.49.el6
It is the same kernel as was in beta yesterday.
Update [Jan 5, 2018 10:10am PT]
CloudLinux 7 Beta kernels with Resellers limits has been patched now as well. We are planning to release this kernels (together with reseller limits) to production on 15th. We will not be bringing in reseller limits update via KC, so you might want to take this time and make a jump into resellers limits anyway if you are planning to reboot.
Update instructions:
CL7:
yum clean all --enablerepo=cloudlinux-updates-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.5.8.el7 --enablerepo=cloudlinux-updates-testing
CL6h:
yum clean all --enablerepo=cloudlinux-updates-testing,cloudlinux-hybrid-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.5.8.el6h --enablerepo=cloudlinux-updates-testing,cloudlinux-hybrid-testing
Changelog:
- Added patches for Meltdown and Spectre attacks (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
- KMODLVE-142: resync stats before returning IO usage
- KMODLVE-140: fix panic with module loading
- KMODLVE-139: add ability to set debug level in load time
- KMODLVE-138: properly check lve_cgroup_kernel_open return value
- KMODLVE-134: code cleanup for better test coverage
- KMODLVE-131: improve failure IDs handling
- KMODLVE-127: lvp_lve_move implementation
More info on resellers limits: https://docs.cloudlinux.com/index.html?reseller_limits.html
Update [Jan 5, 2018 7:45am PT]
KernelCare update
I just had update on where we are on individual tasks that people are working on for KernelCare. Here is the summary of what we know, what we expect, and suggestions:
1. Fixes available should prevent 2 out of 3 possible attack vectors. Intel promises microcode updates next week to close all known attack vectors. Applying microcode typically requires reboot (but we will try to allow doing it via KC)
2. Exploit for meltdown is very simple, as long as attacker can execute arbitrary code, they can read everything in RAM
3. The patchset is big & complex. We also need to augment it with a lot of our own code to make it patchable with KernelCare, as we need to change the way existing / running processes access kernel space.
Even though we didn't hit any roadblocks today, I think our initial projection of Saturday was very optimistic. We need to continue not hitting any roadblocks to make it.
More realistic projection is Monday, due to complexity & number of components we need to bring together & make sure they all working.
My recommendation as of now would be:
* If you are a service provider where it is easy for an attacker to run arbitrary code, don't wait
* If you are in full control of your servers / enterprise / corp customer with no imediate access for hackers to run any code on your servers, and your risk tolerance is high enough, you might be able to hold off until we have a patch.
Note: We are still going to continue working through weekend/full force to get this patch out. This is just my suggestions best of the information available to me at this moment
Update [Jan 5, 2018 7:00am PT]
CloudLinux 7 and CloudLinux 6hybrid kernels are in production now. It is the same kernels that were pushed to beta, so if you upgraded earlier, you don't need to upgrade again.
Upgrade Instructions:
CL7:
# yum clean all && yum install linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el7
CL6h:
# yum clean all && yum install linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el6h
What to expect next:
We will move CloudLinux 6 kernels to production tomorrow morning if no new issues will be found.
KernelCare update:
So far we are progressing as expected for tomorrow release. We didn't hit any lucky breaks, nor we hit any walls. Yet, we are still far away to be confident on Tomorrow's release.
There is still a posibility that it will be delayed until Sunday, Monday, or we hit something that we didn't realize to be a blocker, and we might have to delay even further
I will try to make another (single) update on KC today, but there is really not much information at this stage beyond: We are writting code/testing what we have.
Update [Jan 5, 2018 5:23am PT]
CL6 kernel released to beta. Update command:
# yum clean all --enablerepo=cloudlinux-updates-testing && yum update kernel-firmware --enablerepo=cloudlinux-updates-testing && yum install kernel-2.6.32-896.16.1.lve1.4.49.el6 --enablerepo=cloudlinux-updates-testing
Changelog:
CKSIX-143: fixed deadlock when disk quota is enabled
Update [Jan 4, 2018 5:50pm PT]
Some people are experiencing issues iwth CloudLinux 6 kernel. We will push a new kernel early tomorrow morning. Please, hold off install CloudLinux 6 kernel for now. CloudLinux 7 and CloudLinux 6hybrid kernels should be fine.
Update [Jan 4, 2018 3:50pm PT]
CloudLinux 6 kernel is now available. Please, note that unlike CloudLinux 7 kernel, we didn't have time to fully tested. We will complete our tests early tomorrow morning (probably before 7am PT). So, try testing it first, and post if your tests were successful here.
Changelog:
- Added patches for Meltdown and Spectre attacks (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
Upgrade instructions
# yum clean all --enablerepo=cloudlinux-updates-testing && yum update microcode_ctl && yum install kernel-2.6.32-896.16.1.lve1.4.48.el6 --enablerepo=cloudlinux-updates-testing
Don't forget to reboot.
Update [Jan 4, 2018 3:37pm PT]
Corrected upgrade instructions
Upgrade instructions
CL7:
# yum clean all --enablerepo=cloudlinux-updates-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el7 --enablerepo=cloudlinux-updates-testing
CL6h:
# yum clean all --enablerepo=cloudlinux-updates-testing,cloudlinux-hybrid-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el6h --enablerepo=cloudlinux-updates-testing,cloudlinux-hybrid-testing
Update [Jan 4, 2018 1:45pm PT]
CloudLinux 7 and CloudLinux 7 hybrid kernels are out. Please, try them, post how it works for you/what overhead you are seeing. Our tests show single digits overhead on with our syntetic / hosting related workloads.
Changelog:
- Added patches for Meltdown and Spectre attacks (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)
Upgrade instructions
CL7:
# yum clean all --cloudlinux-updates-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el7 --enablerepo=cloudlinux-updates-testing
CL6h:
# yum clean all --cloudlinux-updates-testing,cloudlinux-hybrid-testing && yum update linux-firmware microcode_ctl && yum install kernel-3.10.0-714.10.2.lve1.4.79.el6h --enablerepo=cloudlinux-updates-testing,cloudlinux-hybrid-testing
Don't forget to reboot.
CloudLinux 6 kernel should follow within an hour, stand by for more info.
There will be no more KC status updates until tomorrow.
Update [Jan 4, 2018 10:25am PT]
We need to make one more iteration for CloudLinux 7 kernels - this should be the last one. Another ~3 hours.
We also got patches for CloudLinux 6 (thanks to the great team at our upstream kernel at virtuozzo.com). Hopefully it will be ready in another 4 hours.
Update [Jan 4, 2018 7:37am PT]
Some setback on CloudLinux 7 kernels. We need to make some changes and restart the build/test cycles. Another ~3 hours.
Update [Jan 4, 2018 4:50am PT]
Good News: We have CloudLinux 7 and CloudLinux 7 hybrid kernels being built right now. We hope to have them for you in the next 3 hours. CloudLinux 6 kernels will follow shortly after that.
Bad News: We will not have KernelCare patches until Saturday, and even that is considered optimistic at best. We will also have to release three sets of patches, and it might take us a week to cover it all.
The first set of patches should cover KPTI patchset that fixes a meltdown attack (that is the one we optimistically plan for Saturday). There are multiple complexities with the patch, one of which is to change how addressing works for existing processes, and the other one is how to deal with unpatch (and changing addressing again). This code would have to be written from scratch, as this condition doesn't happen.
The second patch will be focused on speculation control that wasn't part of mainstream, but part of RHEL kernel, and tries to address one of the Spektre attack.
The third patchset will try to load microcode used to protect against second Spectre attack on the fly. Typically microcode is loaded on OS boot, but we will try to safely apply it using KernelCare.
Why is it so bad: There is a chance that we don't understand "everything" yet, and there is something that will prevent us from delivering this patches altogether, or will delay them even more. We are trying to hot patch six months of work of a fairly big group of kernel developers in a very short time and will be working non stop as long as we can. Yet, this is really complex problems and we foresee that we will hit a few brick walls that we would have to smash before we will have patches.
Update [Jan 3, 2018 8:03pm PT]
There will be no more updates until Jan 4th. Please, expect more updates around 5 am PT. We are trying to solve it as fast as we can, but the changes are big, intrusive, and we had little prior warning.
Update [Jan 3, 2018 6:54pm PT]
PoC for Spectre attack is publicly available. This is the attack that has no patches yet from any vendor, and might not be even possible to protect against.
https://pastebin.com/A58h8N7y
Update [Jan 3, 2018 6:10pm PT]
We are mostly done with CloudLinux 7 patches (full kernel, not KernelCare), but there are still several hours of work left before we can start testing them.
We also identified the areas that need to be modified for patches to be applicable by KernelCare and started to work on those areas.
We hope to release some CloudLinux kernels into beta tomorrow. We are yet to have ETA for KernelCare patches due to the large size of the needed patch, and some critical areas that the patch affects.
Update [Jan 3, 2018 3:40pm PT]
We have succesfully downloaded the sources for the patch for RHEL7, and started to work on them. Yet, please, don't expect any KC patches today. The patchset is complex, and it will take time to adopt it.
Update [Jan 3, 2018 3:40pm PT]
RedHat code cannot be downloaded for now (for whatever reason, we are dealing with it)
Xen released Xen Security Advisory - Intel and AMD CPUs affected, no mitigation/solution for now for two out of three ways of attacking the system.
Update [Jan 3, 2018 3:25pm PT]
RedHat released security advisory/fixes for RHEL 6.4. This gives us something to work with.
Update [Jan 3, 2018 3:15pm PT]
The vulnerabilities were finally disclosed: https://spectreattack.com/
Our initial attempt to port mainline patches to CloudLinux 7 & EL 7 kernels is not succesful due to lack of PCID support. Without PCID, the performance drop will be 30%+. We are working on workarounds, and waiting for an update from the upstream.
We don't have all the information yet. We don't know much beyond what has already been reported by The Register and by Intel.
What we assume as of now:
- There is a bug in Intel CPUs that allows user space software to read kernel's memory;
- There is a patch that fixes the issue (presumably) committed in mainline kernel;
- The patch results in 5% to 30% performance penalty;
- The patch is complex and needs to be reworked to be applied by KernelCare.
- We don't know just how pervasive the problem is, and how it can be exploited;
- We don't know if the patch accepted by mainline kernel fixes the vulnerability completely;
- We don't know if the patch will crash servers under some workloads;
- We don't know what information about vulnerability becomes public and which details will be revealed.
- We are adopting existing mainline kernel for CloudLinux 7 and CentOS 7;
- We are working on adopting the patch for patching by KernelCare. Yet, due to the complexity of the patch, we don't have an ETA yet.
- Prepare KernelCare patches in order: CentOS/RHEL/CloudLinux 7, CentOS/RHEL/CloudLinux 6/Virtuozzo, Ubuntu, Debian, other…;
- Wait until upstream provides info on their patches, to make sure that our adopted patches work;
- Potentially -- release our KernelCare patches as 'experimental' once they are ready;
- Deliver patched CloudLinux 7, and then CloudLinux 6 kernel into beta, as soon as it is ready.
We cannot provide you with an ETA yet, but we know that we will not be delivering anything today, January 3rd. We will provide you with more information tomorrow, or sooner if we have more information." -
CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more
Discussion in 'Hardware Components and Aftermarket Upgrades' started by hmscott, Jan 2, 2018.
