Devastating Speculative Execution Intel CPU Bug

[SteelCrysis]

New microcode released by Intel: https://www.techpowerup.com/245653/intel...hitectures

[SteelCrysis]

And another Spectre vulnerability: https://www.techpowerup.com/245910/new-s...de-updates

[SteelCrysis]

Another Spectre vulnerability, although it's impractical: https://www.techpowerup.com/246304/insid...er-network

[SteelCrysis]

Another Spectre vulnerability, Intel released a fix earlier this year: https://www.tomshardware.com/news/intel-...37608.html

[SteelCrysis]

There's concern that this latest vulnerability could be used to get around hardware DRM, but apparently ET hasn't heard that Intel fixed the issue: https://www.extremetech.com/computing/27...rdware-drm

[SteelCrysis]

https://www.techpowerup.com/247028/intel...de-updates

Some of Intel's biggest enterprise customers are cloud computing providers such as AWS, Microsoft, and Google, who have made it their duty to keep their customers informed about the performance impact of microcode updated processors, since it impacts their cost/performance when the scale is big enough. This gag is both unethical, and probably even illegal.

[SteelCrysis]

Intel has replaced this agreement: https://www.tomshardware.com/news/intel-...37684.html

[SteelCrysis]

https://www.tomshardware.com/news/disabl...37690.html

Following the reveal of the Foreshadow (L1TF) Intel CPU flaw, as well as the previous TLBleed flaw, Theo de Raadt, founder of OpenBSD, which makes a free, multi-platform, UNIX-like operating system, recommended everyone completely disable Intel’s Hyper-Threading in BIOS before hackers start taking advantage of it.

In a post this week, de Raadt said that the Foreshadow and TLBleed flaws have made it mandatory to disable the Hyper-Threading technology on all Intel-based machines. He claimed mitigating these flaws requires a new CPU microcode and coding workarounds, but these alone are not sufficient to stop attackers; Hyper-Threading also has to be disabled.

Hyper-Threading, which is Intel’s brand name for the simultaneous multithreading technology, is fundamentally broken, according to the OpenBSD founder. The technology enables the CPU to share resources that lack security differentiators.

The side-channels attacks enabled by this vulnerability are not easy to implement, but he believes that eventually attackers will find a way to make them work reliably in order to leak kernel or cross-VM memory in common usage circumstances, such as using JavaScript in the browser.

[SteelCrysis]

Whiskey Lake CPUs are the first to have hardware fixes for Meltdown and Spectre: https://www.tomshardware.com/news/whiske...37723.html

[SteelCrysis]

https://www.techpowerup.com/247204/intel...iskey-lake

In a statement to AnandTech, Intel explained that the key difference between "Whiskey Lake" and "Coffee Lake" is silicon-level hardening against "Meltdown" variants 3 and 5. This isn't just a software-level mitigation part of the microcode, but a hardware fix that reduces the performance impact of the mitigation, compared to a software fix implemented via patched microcode. "Cascade Lake" will pack the most important hardware-level fixes, including "Spectre" variant 2 (aka branch target injection). Software-level fixes reduce performance by 3-10 percent, but a hardware-level fix is expected to impact performance "a lot less."

[SteelCrysis]

Hardware fixes for Meltdown and Spectre arrive for the Core line, not yet for Core-X: https://www.techpowerup.com/248368/intel...ve-to-wait

[SteelCrysis]

https://www.techpowerup.com/248693/mit-r...ion-is-key

Intel will have to redesign certain features on their future processors to finally forget Meltdown and Spectre, but meanwhile others have jumped to give some options. MIT researchers have developed a way to partition and isolate memory caches with 'protection domains'. Unlike Intel's Cache Allocation Technology (CAT), MIT's technology, called DAWG (Dynamically Allocated Way Guard) disallows hits across those protection domains. This is important, because attackers targeting this vulnerabilities take advantage of 'cache timing attacks' and can get access to sensible, private data.
...
According to MIT researcher's paper (PDF), DAWG requires "minimal modifications to the underlying operating system", and they assure the performance overhead is "reasonable". Although it's not a silver bullet for all known attacks, they hope to expand this project to fix all Meltdown and Spectre variants.

[SteelCrysis]

https://www.tomshardware.com/news/spectr...37950.html

CSAIL warned that DAWG isn't a perfect solution for all side-channel attacks. The researchers believe it will defend against Spectre Variant 1 and 2 as well as other vulnerabilities that rely on similar techniques (they're also planning to continue training DAWG to bark at...erm, defend against other attacks like these). If they're right and their solution is widely adopted, Spectre's impact could be significantly reduced without requiring people to buy new processors or sacrifice too much performance in exchange for security, as many (somewhat incorrectly) feared.

[SteelCrysis]

7 new attacks, some have already been mitigated: https://arstechnica.com/gadgets/2018/11/...n-attacks/

Going forward, we'll likely continue to see improvements to the mitigation techniques, both to improve their performance and make them more effective. It's unlikely that we've seen the last of the speculative execution attacks, but this systematic analysis should at least mean that all the low-hanging fruit has been discovered.

[SteelCrysis]

https://www.tomshardware.com/news/spectr...38627.html

A group of Google security researchers have warned that Spectre speculative execution attacks are here to stay without serious changes to the design of modern CPU architectures, such as eliminating speculation execution in order to prevent all related side-channel attacks.

The team of security researchers, including Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest, work on Google Chrome’s V8 JavaScript engine and came to the conclusion that all processors that perform speculative execution will always remain susceptible to various side-channel attacks, regardless of specific mitigations the cybersecurity community might find along the way.
...
The security researchers leave us with a wake-up call at the end of the paper, calling into question the entire history of trade-offs of performance over security that CPU makers have been making for decades:

"Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it. It is now a painful irony that today, defense requires even more complexity with software mitigations, most of which we know to be incomplete. And complexity makes these three open problems all that much harder. Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time."

[SteelCrysis]

https://www.techpowerup.com/253285/spoil...intel-cpus

A new security vulnerability has been found that only affects Intel CPUs - AMD users need not concern regarding this issue. Dubbed Spoiler, the newfound security vulnerability was discovered by the Worcester Polytechnic Institute in partnership with the University of Lübeck, and affects all Intel CPUs since the introduction of their Core architecture. This vulnerability too affects Intel's speculative execution design, and according to the researchers, works independent of OS, virtual machine, or sandboxed environments.

As the researchers explain, Intel's speculative execution of certain memory workloads requires the full physical address bits for the information in memory to be known, which could allow for the full address to be available in user space - allowing for privilege escalation and other microarchitectural attacks. According to the researchers, a software solution to this problem is impossible, which means this is yet another silicon-level bug that needs to be addressed in future processor designs.

[SteelCrysis]

AMD confirms that Spoiler does not affect their CPUs: https://www.tomshardware.com/news/amd-pr...38841.html

[SteelCrysis]

https://www.tomshardware.com/news/intel-...39047.html

The researchers note that Spoiler can’t be mitigated in software and that new Intel CPUs will need hardware changes to prevent attackers from exploiting this flaw. However, they also said that said hardware mitigation would likely bring a performance penalty to Intel’s CPUs.

Although most CPUs are affected by most Spectre flaws, Spoiler, Meltdown, Foreshadow, and other such Intel CPU-only flaws show the company has been more willing to de-prioritize security to get ahead of the competition in terms of performance.

As far as Spoiler mitigations are concerned, Intel seems to be currently handing over the burden to software developers that the company encourages to use side-channel-safe software development practices.

This would mean that Intel would be off the hook for fixing its memory subsystem, and whatever software changes developers need to make to their software to protect their apps from Spoiler would slow down these apps not just on Intel hardware, but also AMD and Arm hardware.

[SteelCrysis]

https://www.techpowerup.com/255508/yet-a...h-gen-cpus

The issue at hand here, defined by Intel's pretty tame MDS, is that like other side-channel attacks, exploits may allow hackers to obtain information that was otherwise deemed secure, had it not been run through the CPU's speculative execution processes. While Meltdown read sensitive information that was being stored in memory due to the speculative execution functions on Intel's CPUs, MDS attacks read the data on the CPU's various buffers - between threads, along the way to the CPU's cache, and others. The researchers say that this flaw can be used to siphon data from the CPU at a rate that can approach real-time, and can be used to selectively pull what information is deemed important: whether passwords or what websites the user is visiting at the moment of the attack, it's all fair game.

Intel says that significant software changes will be needed to harden systems against this exploit, not only from themselves, but from operating system designers and third party app creators. One of the proposed solutions is that every time a processor would switch from one third-party app to another, from a Windows process to a third-party app, or even from less trusted Windows processes to more trusted ones, the buffers have to be cleared or overwritten. This means a whole new cycle of data gathering and writing every time you call up a different process - and you bet that carries a performance penalty, which Intel is putting at a "minimal" up to 9%.

Intel in its white paper detailing the vulnerability admitted that disbaling HT might be warranted as a protection against MDS attacks - and you can imagine how much the company must have loathed to publish such a thing. Intel's HT has been heavily hit by the repeated speculative executon flaws found on Intel processors, with mititgations usually costing some sort of performance on Intel's concurrent processing technology. Intel says its engineers discovered the MDS vulnerabilities last year, and that it has now released fixes for the flaw in both hardware and software. Although obvisously, the software fixes will have to be deployed either on microcode updates or will have to be implemented by every operating system, virtualization vendor, and other software makers.

Intel also said that its 8th and 9th generation processors already include the hardware mitigations that defeat the exploitaition of MDS, but previous architectures back to Nehalem are vulnerable. But why play it on expectations: you can take a test that has been published by the researchers right here.

[SteelCrysis]

https://www.techpowerup.com/255537/amd-c...rabilities

AMD in a statement confirmed that its processors are unaffected by the RIDL (Rogue In-Flight Data Load) and Fallout vulnerabilities. The company however worded its statement in CYA language, just to be safe. "...we believe our products are not susceptible to 'Fallout' or 'RIDL' because of the hardware protection checks in our architecture. We have not been able to demonstrate these exploits on AMD products and are unaware of others having done so," reads the AMD statement put out late Tuesday (14th May).

https://www.techpowerup.com/255534/intel...mitigation

Intel Tuesday once again shook the IT world by disclosing severe microarchitecture-level security vulnerabilities affecting its processors. The Microarchitectural Data Sampling (MDS) class of vulnerabilities affect Intel CPU architectures older than "Coffee Lake" to a greater extent. Among other forms of mitigation software patches, Intel is recommending that users disable HyperThreading technology (HTT), Intel's simultaneous multithreading (SMT) implementation. This would significantly deplete multi-threaded performance on older processors with lower core-counts, particularly Core i3 2-core/4-thread chips.

On "safer" microarchitectures such as "Coffee Lake," though, Intel is expecting a minimal impact of software patches, and doesn't see any negative impact of disabling HTT. This may have something to do with the 50-100 percent increased core-counts with the 8th and 9th generations. The company put out a selection of benchmarks relevant to client and enterprise (data-center) use-cases. On the client use-case that's we're more interested in, a Core i9-9900K machine with software mitigation and HTT disabled is negligibly slower (within 2 percent) of a machine without mitigation and HTT enabled. Intel's selection of benchmarks include SYSMark 2014 SE, WebXprt 3, SPECInt rate base (1 copy and n copies), and 3DMark "Skydiver" with the chip's integrated UHD 630 graphics. Comparing machines with mitigations applied but toggling HTT presents a slightly different story.

https://www.tomshardware.com/news/disabl...39348.html

Apple has joined Google in advising customers to disable Intel CPUs' Hyper-Threading feature. This drastic measure is supposed to defend against Microarchitectural Data Sampling (MDS) issues that Intel disclosed on Monday. Apple warned, however, that defending against those vulnerabilities by disabling Hyper-Threading "may have a significant impact on the performance" of the system in question.

The MDS security vulnerabilities are present in nearly every modern Intel processor. Intel released updates to help protect affected systems, but those updates might not be enough to protect them, which is why Apple and Google have told customers to disable Hyper-Threading. Intel told us on Tuesday that most people won't have to disable Hyper-Threading; it depends on each individual's security requirements.

So just how significant of a performance impact can Apple customers expect if they disable Hyper-Threading?

"Testing conducted by Apple in May 2019 showed as much as a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks," the company said. That's based on the company's test systems, though, and the actual impact will vary between devices.

Nobody wants their MacBook to be half as fast as it was before these mitigations were revealed. Because there isn't a known exploit involving the MDS flaws, these performance drops could be enough to convince many people not to defend their systems. It's pretty much like Intel said yesterday: everyone will have to decide for themselves if the improved security outweighs the dramatic performance impact.

https://www.techpowerup.com/255545/intel...-on-may-14

Intel released CPU microcode updates to address four new security vulnerabilities disclosed by the company on May 14, 2019. These microcode updates can be encapsulated as motherboard UEFI firmware updates, and for some processors even distributed through Windows Update. In its Microcode Revision Guidance document put out on Tuesday, Intel revealed that all Core and Xeon processors going as far as the 2nd generation Core "Sandy Bridge" architecture are eligible for microcode updates.

[SteelCrysis]

https://www.extremetech.com/computing/29...rabilities

There has been a bit of controversy over just how serious these new attacks are, and I’ll honestly say I’m a bit unhappy with how some of this news has been publicized. Some of you may remember last year, when a supposed security research firm, CTS-Labs, appeared to be collaborating with a short seller firm in a blatant attempt to attack AMD’s stock price by publicizing a set of supposedly critical security flaws that the disclosure literally implied could put lives at risk. Absolutely nothing came of these flaws, which the short seller, Viceroy Research, also literally predicted could reduce the value of AMD’s stock to zero. As we discussed at the time, contaminating security disclosures with hyperbolic marketing claims to paint the issues as far worse than they actually were is an emphatically bad idea, regardless of who is being targeted or for what reason.

The situation with Intel is not nearly this bad, but it shows some of the same troubling trends I discussed last year. The researchers chose to publicize their efforts at a website named “CPU.fail“, with scary looking graphics and an FAQ that seems designed more to frighten than inform. When asked if the issues they highlight have been abused in the wild, for example, they simply state: “We don’t know.” But the question of how serious flaws these flaws are in practice is a genuine one.

Thus far, no attacks actually utilizing Spectre and Meltdown have been spotted in the wild, beyond proof-of-concept work submitted by researchers. Similarly, taking advantage of MDS is trickier than this website implies. Attackers can’t directly control what’s in the buffers they target, for example, which means the exploit may leak old, stale data of no interest. Microcode updates for systems with Sandy Lake through Kaby Lake CPUs have already shipped out to customers. First-generation-and-following Coffee Lake and Whiskey Lake CPUs are immune to this attack already. The impact on performance from the fix is estimated to be ~3 percent.

[SteelCrysis]

https://www.tomshardware.com/news/intel-...39381.html

Intel has published its own set of benchmark results for the mitigations to the latest round of vulnerabilities, but Phoronix, a publication that focuses on Linux-related news and reviews, has conducted its own testing and found a significant impact. Phoronix's recent testing of all mitigations in Linux found the fixes reduce Intel's performance by 16% (on average) with Hyper-Threading enabled, while AMD only suffers a 3% average loss. Phoronix derived these percentages from the geometric mean of test results from its entire test suite.

From a performance perspective, the overhead of the mitigations narrow the gap between Intel and AMD's processors. Intel's chips can suffer even more with Hyper-Threading (HT) disabled, a measure that some companies (such as Apple and Google) say is the only way to make Intel processors completely safe from the latest vulnerabilities. In some of Phoronix's testing, disabling HT reduced performance almost 50%. The difference was not that great in many cases, but the gap did widen in almost every test by at least a few points.

To be clear, this is not just testing with mitigations for MDS (also known as Fallout, Zombieload, and RIDL), but also patches for previous exploits like Spectre and Meltdown. Because of this, AMD also has lost some performance with mitigations enabled (because AMD is vulnerable to some Spectre variants), but only 3%.
...
The performance reduction that correlates with these security patches is a challenge for Intel, coming in at a time when Intel's chips are vulnerable to AMD's upcoming desktop and server CPUs that will arrive with a smaller 7nm manufacturing process. In many cases, the mitigations reduce Intel's performance advantage over the existing Ryzen processors, and there is little doubt the next-gen Ryzen chips will be even faster. That could have an impact on both the desktop PC and server markets.

[SteelCrysis]

https://www.techpowerup.com/258039/swapg...nerability

Yet another CPU vulnerability was discovered today, called SWAPGS, revealed under the code CVE-2019-1125, as it is referred to in the industry. The vulnerability was discovered twelve months ago and got privately reported to Intel by a security researcher. It's supposedly present on both AMD and Intel CPUs, but was only proven to work on Intel platforms by Bitdefender security researchers. Red Hat issued a statement which states that both platforms are affected and that users should upgrade their systems as soon as possible. Microsoft already implemented a fix with its "Patch Tuesday" update for last month, so if you updated your OS recently, you are already protected against SWAPGS.

AMD issued as statement as well, in which it says: "AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1."
...
Update: Performance impact of the SWAPGS mitigation has been tested with the latest Linux kernel. Phoronix benchmarked Intel's Core i9 9900K and they found a 1-5% reduction in performance for synthetic benchmarks with a general reduction of 1% on average when accounting for all benchmarks. You can check out their performance results here.

[SteelCrysis]

https://www.tomshardware.com/news/intel-...40529.html

Intel recently published a paper detailing a proposal for a new type of CPU memory that would mitigate against speculative execution side-channel attacks, including Spectre-class vulnerabilities.

ntel’s STrategic Offensive Research & Mitigations (STORM) team came up with the proposal for the new Speculative-Access Protected Memory (SAPM) feature that Intel is still researching. The idea is that SAPM would replace existing CPU memory with a more secure memory standard that would be resilient against Spectre-class attacks, including security vulnerabilities like Meltdown, Foreshadow, MDS, SpectreRSB and Spoiler.

STORM's research paper, published last week, said that development of SAMP is only at the "theory and possible implementation options" level. In other words, there’s no concrete idea that Intel and other CPU makers can implement right away; there still needs to be a significant amount of testing before it can become a viable CPU feature.
...
According to Intel’s researchers, incorporating SAPM would hurt Intel chips' performance; however, the impact would be less than that of all the software patches implmented so far.

"Although the performance cost for each memory access to SAPM is relatively big, considering such operations shall only be a very small portion of the total software execution, the overall performance overhead is expected to be low and potentially less than the performance impact of current mitigations," the paper says.

[SteelCrysis]

https://www.tomshardware.com/news/intel-...ew-jcc-bug

Intel announced in May a Microarchitectural Data Sampling (MDS) problem that attackers could exploit to extract information from its processors despite their built-in safeguards. Today it revealed that MDS was an even bigger problem than many people realized by announcing a new TSX Asynchronous Abort (TAA) vulnerability. Intel also disclosed a new Jump Conditional Code (JCC) erratum today and released a patch that does have a performance impact (which we'll cover further below).

Only the researchers who discovered both security flaws said there's nothing new about TAA--they claimed to have disclosed the vulnerability to Intel over a year ago, but is just now seeing the light of day to the public.
...
The new TAA vulnerabilities weren't the only security flaw affecting Intel processors revealed today. Phoronix reported on Jump Conditional Code (JCC) erratum affecting CPUs based on the Skylake architecture and its descendants. This is said to be "a bug involving the CPU's Decoded ICache" that meant "unpredictable behavior could happen when jump instructions cross cache lines." Intel released microcode updates to address the flaw, but unsurprisingly, that added security affected performance.

Phoronix said that "Intel's official guidance coming out today states their observed performance effects from this microcode update to be in the range of 0~4%" with some outliers. The outlet's benchmarks showed that the "microcode update does cause a hit of generally up to a couple percent," but with the caveat that in "select real-world workloads the impact is greater." Check out the full report for more info.

https://www.extremetech.com/computing/30...ce-penalty

According to Phoronix’s extensive tests, the average impact hits performance “by a couple of percent,” some of which can be recovered by compiler patches and updates to Linux that will take some time to be merged in updates and to trickle back down to users. It’s not clear what sort of timeline Windows users should expect or what performance losses look like in that operating system.
...
Ultimately, this kind of move is likely the result of Intel cleaning house and conducting security reviews of its own products, then moving to patch errata, even those that might impact perf. That’s going to frustrate users who see performance dips, and the impact of these dips can exceed the 4 percent threshold, but it’s also the right move for the company to make long-term. Hopefully, updates to software toolchains and OS support will minimize the performance impact of these changes, which, again, appear to be unrelated to any of the issues we’ve discussed with Spectre and Meltdown.

[SteelCrysis]

https://www.tomshardware.com/news/intel-...ut-attacks

Researchers at the University of Michigan, VUSec and University of Adelaide revealed a new attack they dubbed CacheOut yesterday. The speculative execution attack "is capable of leaking data from Intel CPUs across many security boundaries," according to the researchers, and it offers better targeting than previous attacks of its type.

CacheOut was purportedly inspired by previous speculative execution attacks like Spectre and Meltdown. Its reach extends further than those attacks, however, because it can bypass the hardware-based safeguards implemented by Intel in response to Meltdown's discovery. It can also be used to extract specific data.

The researchers said they "empirically demonstrate that CacheOut can violate nearly every hardware-based security domain, leaking data from the OS kernel, co-resident virtual machines, and even SGX enclaves" in their paper. Intel released microcode updates, and explained how to mitigate the attack on the OS level, in response.

So who's affected? The researchers said that anyone who owns an Intel processor released before the fourth quarter of 2018 is probably affected by CacheOut. (The company "inadvertently managed to partially mitigate this issue while addressing a previous issue," they said.) Intel published a list of affected processors on its website.
...
The researchers said additional information about this new attack can be found in the final version of their paper (PDF). While the new CacheOut branding might make this attack seem totally new, it seems like ZombieLoad actually copied its namesake in rising from the dead to continue to munch on the sweet, sweet brains of our PCs.

https://www.techpowerup.com/263355/cache...processors

Additionally, it is worth pointing out that AMD CPUs are not affected by this exploit.

[RolloTheGreat]

It's also worth pointing out 9700Ks and 9600Ks are not affect by ANY hyper threading attacks.

They have no hyperthreading.

[SteelCrysis]

https://www.tomshardware.com/news/intel-...rity-flaws

Intel on Thursday released a microcode update for the latest speculative execution flaws, such as the MDS attacks, that have affected its CPUs. The update is now available for both consumer and server versions of Windows 10 build 1903, but users must install it manually.
...
Microcode updates aren’t typically installed via the Windows operating system so it’s up to users to install them. You can find download details below:

[SteelCrysis]

https://techreport.com/news/3469107/unfi...ntel-cpus/

A little over a month ago, we reported on a speculative execution vulnerability found in Intel CPUs, adding to the growing list of similar vulnerabilities. However, yesterday, a team of security researchers revealed a new kind of vulnerability in Intel CPUs. Positive Technologies published a blog post detailing a flaw in Intel’s Converged Security and Management Engine (CSME) firmware.

This flaw is located in the Read-Only-Memory (ROM), which means it is hard-coded and so cannot be fixed. This feature of the vulnerability sets it apart from all the speculative execution vulnerabilities, which can be patched. That said, according to the blog post, when the security group reached out to Intel in order to report the vulnerability, they found that Intel already knew about the vulnerability and was attempting to address it. The vulnerability was registered last year in the Common Vulnerabilities and Exposures system as CVE-2019-0090, and has a vulnerability score of 7.1 (high).

https://www.tomshardware.com/news/load-v...ntel-chips

Intel's chips have faced an onslaught of new vulnerabilities discovered by crafty researchers, and today finds the company facing yet another new flaw, Load Value Injection (LVI), that a press release from Bitdefender describes as "particularly devastating" for servers in the data center. LVI impacts all Core families spanning from the third-generation Ivy Bridge chips to the 10th-generation Comet Lake processors.

According to statements from the researchers to ZDNet, the attack builds upon the Meltdown vulnerabilities that Intel already patched in software, but the LVI still works on systems with the requisite software fixes. As such, Intel will reportedly need to employ hardware fixes to fully block the LVI attack vector.

According to experimental fixes employed by the researchers, performance reductions from potential mitigations could vary from 2x to 19x based upon workload, but that could be offset with hardware-based fixes in new silicon.

[SteelCrysis]

https://www.extremetech.com/computing/30...ridiculous

What they don’t say upfront is that LVI is a theoretical attack. There’s a distinct difference in tone between the messaging in the Bitdefender PDF and the messaging on the Bitdefender blog. The blog states:
...
The “Real-life exploit” section of the Bitdefender whitepaper is rather different. “Creating a real-life exploit,” it says, “poses some significant challenges.” Those challenges are:
...
The Bitdefender whitepaper contains none of the inflammatory language in the company’s blog or used on the LVI disclosure website. It states that the attack only currently exists as a synthetic proof of concept and discusses multiple problems related to actually taking advantage of the flaw. In other words, the papers contain the actual data telling you that this isn’t a current threat, while the public-facing blog posts are amped to deliver maximum scare-city.
...
All such significant issues need to be fixed, and I’m 100 percent in favor of holding vendors accountable. But a recent story on LVI by ZDNet exemplifies how the marketing arm of the security industry and the actual research arm don’t seem to have much to do with each other these days.
...
The PR-friendly tendency to maximize fear around security disclosures must stop, not because companies deserve to have their flaws overlooked, but because using maximalist language in these types of disclosures makes it impossible for anyone to estimate the actual degree of risk. Statements like “This type of attack is much harder to pull off in practice,” need to be made in both the body of the formal report and on the websites where these disclosures are made. We’re starting to hear about ‘theoretical’ risks to both Intel and AMD and threats that could emerge someday, but, you know, don’t actually exist right now. There’s nothing wrong with planning ahead, but given the long development cycles that CPUs See Amazon ET commerce go through, there’s no practical way for Intel to build a 2020 CPU to handle every possible security flaw that might be found in software, hardware, or both by 2025. The nature of security flaws is that after you patch one, people go out and find another.

I’m increasingly convinced that Intel isn’t being treated fairly by these reports, and it’s not just Intel. Earlier this week we covered another instance where the PR verbiage around an AMD flaw didn’t match what the actual security researchers said in public. I don’t want to impugn the good work that security researchers do, especially since I don’t know if the people writing the public-facing website copy are the same people actually performing the work, but the disconnect between PR blasts and whitepaper reports is becoming untenable.

You don’t see many journalists write stories downplaying security issues for a simple reason: Nobody wants to be the guy who swore that a security problem wasn’t an issue right before it explodes into a major problem. Frankly, I don’t either. At the same time, the way these reports are being sold to the public is making it actively harder to do my job. If Intel has an obvious interest in downplaying any security report and the company who found the flaw is doing everything it can to paint that flaw in the most apocalyptic language possible, it’s much harder for us journalists to know what to tell people.

I’m not going to say that LVI isn’t an issue or that Intel shouldn’t fix it. Intel has, in fact, already released some software updates intended to correct the problem. With that said, Meltdown and Spectre have now existed for over two years and no malware has yet been found to use them. What I will say is that when the head of a company’s threat-analysis division doesn’t believe an issue is worth patching, it also may not deserve to be front-page news declaring that yet another flaw has been found in Intel chips. There’s giving readers good information about pressing threats and there’s being used by PR teams to pump up a company in the news under the guise of security reporting. I’m always interested in the former and completely disinterested in the latter.