New Spectre 1.1 and Spectre 1.2 CPU Flaws Disclosed (bleepingcomputer.com)

Two security researchers have revealed details about two new Spectre-class vulnerabilities, which they've named Spectre 1.1 and Spectre 1.2. From a report: Just like all the previous Meltdown and Spectre CPU bugs variations, these two take advantage of the process of speculative execution -- a feature found in all modern CPUs that has the role of improving performance by computing operations in advance and later discarding unneeded data. According to researchers, a Spectre 1.1 attack uses speculative execution to deliver code that overflows CPU store cache buffers in order to write and run malicious code that retrieves data from previously-secured CPU memory sections. Spectre 1.1 is very similar to the Spectre variant 1 and 4, but the two researchers who discovered the bug say that "currently, no effective static analysis or compiler instrumentation is available to generically detect or mitigate Spectre 1.1." As for Spectre 1.2, researchers say this bug can be exploited to write to CPU memory sectors that are normally protected by read-only flags.

Comments

Not many CPU designs are

[AHuxley]

as safe as expected anymore. So many thought some designs would be. That their fav brand would be ok.
Lets create a software layer over the CPU to make it all safe. Get that fast speed way down.

Re:Not many CPU designs are

[Anonymous Coward]

Lets create a software layer over the CPU to make it all safe. Get that fast speed way down.

If you haven't run the PPC copy of some linux distro in QEMU, well its almost amusing for about 30 seconds.

After that you hope you never have to actually use something that slow. Abstracting a secure CPU on top of an insecure one is bound to be pretty slow. It would probably be better to just disable speculative execution, if you can, though again, likely very slow...

Re:Not many CPU designs are

[Eravnrekaree]

a software layer like a VM can make things worse because it creates more "gadgets" that can be exploited, due to the way the flaws work. What they should have really done is simply had a switch in the CPU where the OS can turn off all of this speculative stuff, would have been simple to implement. *facepalm*

Re:Not many CPU designs are

[AHuxley]

Someone is actually going to have to design a new CPU then? The quick OS software fix wont work and save existing CPU brands and designs?
Got some experts ready for years of testing and hard work? Experts who can design an entire new way of thinking about a CPU and can think about past security flaws?
Make a CPU go faster is not going to be the only skill needed.

Re:Not many CPU designs are

[Eravnrekaree]

There have been mitigation being implemented for the bugs to reduce the severity of the problem, so that hopefully will keep current CPUs out of too much trouble. There are too many CPUs around of course to replace them all right away, so the software fixes have to suffice. Eventually new CPU generations will have more fixes built into the CPU. Many spectre variants are a long shot to exploit anyway.

From what I understand is that the flaws result from being able to tell what another process is doing through how fast some code runs. If another process is running the same code as your process, the behaviour of the other process can be gleaned by watching how fast code runs in your process. The CPU learns by watching code execute what code paths are most likely to be taken. So the learning from watching another process can affect other processes.

One solution for a CPU fix is to isolate processes so the CPU isolates its learning and predictions to within each process, one process will not affect the performance of other processes. Processes can not benefit from each other, thats the downside, but no more leaking of state between processes.

It could also be made so the Operating System can configure all of this in more detail about how much should be shared between process, if it all, what kind of optimizations should be done , or none at all, etc, so the user can make their own decisions about security/performance trade offs.

Perhaps the Operating System could be allowed to turn off hardware based optimizations and control the speculative execution scheduling itself which would make it easier to address bugs and security concerns with software updates.

It all requires some changes to the CPU, but from what I understand, its not all that of a big deal to add to CPUs.

Re:Not many CPU designs are

[Anonymous Coward]

It shouldn't take that novel of an approach to address Meltdown and Spectre variants but probably a lot of grunt work and quite a few gates. Just quarantine everything into "per speculation" sandboxes, including every level of cache and the TLB, that is the result of a "miss" on a speculative path. When the path is determined to be the actual code path, all the quarantined items are promoted to the shared caches etc. as part of retiring the instructions (mostly so they will be cached when the same code runs again in a few cycles). Certainly non-trivial effort though.

Re:Not many CPU designs are

[viperidaenz]

ARM Cortex A8, 9, 12, 15, 17, 57, 72, 73, 75... all of those implement speculative execution are are all vulnerable to Spectre v1 and v2. Some also v3, v3a and v4
The A76 is only vulnerable to v1 and v4
https://developer.arm.com/supp...

IBM Power CPUs do speculative execution. IBM aren't fixing Power 6 and earlier.
Power 7, 8 and 9 have been patched apparently (requires both firmware and OS updates to mitigate)

I'm sure there's more.

Re:Not many CPU designs are

[drinkypoo]

Do you know anything about the cost of mitigation on POWER? We've known for a long time that those architectures were vulnerable, but I haven't heard anything about the performance impact of ibm's fix.

Re: Not many CPU designs are

[Anonymous Coward]

Just disable caching, prefetch and speculation! I mean you could just run a mips core at that point.

Re:Not many CPU designs are

[Anonymous Coward]

PPC "secure"? Guess my 6502 is secure then as well.

Re:Not many CPU designs are

[Anonymous Coward]

Power6 is very high frequency, but essentially in order. It does not speculate very far and is likely very hard to exploit. Power4 and 5 are really old now, although G5 are essentially a Power4 with Altivec.

Re:Not many CPU designs are

[Anonymous Coward]

There is one repeating pattern which is not architecture specific: all performance optimizations are based on avoiding redundancy, and that inevitably results in coupling between otherwise independent threads. So basically, you will always have to trade off security for high performance optimization, or limit optimization just within each separated world, where trust already exists among actors, but that means taking a utilization and performance hit. Intel is most vulnerable exactly because they had put too much effort into achieving high benchmarking scores.

Re:Not many CPU designs are

[Anonymous Coward]

Actually, on many CPUs you can turn it off since they boot with a bootrom in the SRAM that is later to be the L1 cache. Then when the initial loading is done and the main memory is operational all these things are turned on. The performance hit is insane though.

Re:Not many CPU designs are

[Anonymous Coward]

as safe as expected anymore. So many thought some designs would be. That their fav brand would be ok.

Lets create a software layer over the CPU to make it all safe. Get that fast speed way down.

Like TIMI in IBM i?

Re:Not many CPU designs are

[Anonymous Coward]

IBM's Power Architecture is vastly more secure than X86 or amd64. Security has always been a priority for the Power Architecture since the beginning about 1985. Now Intel and x86 on the other didn't start implementing security features until about 2010. And lets not forget it was Hewlett-Packard engineers who tought Intel how to attempt to make and implement security features. Intel has always made shity insecure heaters. So you got extremely classified document well lets hope there on {Power or Sparc} because once on x86 it gets leaked to the world.

Re:Not many CPU designs are

[Anonymous Coward]

No..... Not even close. How about this; the G5 is essentially a Power4 thats been stripped of mission critical ras features, cache sizes reduced. Generally just a PPC core for the general idiotic computer user.

Re:Not many CPU designs are

[OneHundredAndTen]

The much-maligned Itanium remains impervious to all these attacks. Just saying.

Re:Not many CPU designs are

[psergiu]

WAS more secure.
For example Power 8 CPUs are affected badly by Specter & Meltdown variants.
IBM put out a mandatory* update for firmware, microcode, PowerVM & AIX to fix this. Problem is that it introduces a huge slowdown in Java & Oracle DB workloads - We've seen things running up to 30% slower in our tests.

* = mandatory as in all future AIX updates have a dependency on those being installed.

Re:Not many CPU designs are

[psergiu]

We did tests on a Power 8 frame with real-life Java application and Oracle DB workloads.
- up to ~30% slower for Java
- up to ~15% slower for Oracle DB

It's ... bad ...

Re:Not many CPU designs are

[imgod2u]

Cross-process isolation can be somewhat simpler. The problem with Spectre specifically is that many programs (your browser opening /. for example) are within the same process running external -- interpreted -- code).

Re:Not many CPU designs are

[Anonymous Coward]

Sounds like a boon to CPU sales--all current stock being flawed.
Intel can take a page out of MS marketing playbook and sell their 9th gen chips as "New, more secure!, previous gen chips are all crap! Upgrade now!"

Re:Not many CPU designs are

[Anonymous Coward]

Or something more modern, that addresses Itanium's (many) issues. The Mill is impervious to speculative exploits, and also others owing to hardware security mechanisms.

Securing conventional OoO hardware is a fool's errand. Patching one hole after another will not restore the confidence lost in awful hardware where security was a distant afterthought. Many if not most exploits can be traced to the lack of adequate hardware protection mechanisms, and the solution won't be a downloadable update. There are also RISC-V efforts aimed at securing hardware, but it remains to be seen if even a new OoO can avoid all speculation pitfalls, and the impervious in-order designs lack performance.

On the bright side, the Mill is expected to be at least an order of magnitude more power efficient than out of order, while using considerably less area. Along with the death of Moore's Law, at least there is now increasing motivation to reconsider architecture from the foundation. Sadly, the systems of intellectual monopoly in place will likely retard deployment.

Re:Not many CPU designs are

[Anonymous Coward]

The much-maligned Itanium remains impervious to all these attacks. Just saying.

Yes, sometimes there is a silver lining when you are trapped in a failed technology.

Re: Not many CPU designs are

[Anonymous Coward]

I disable superfetch on all my windows 7 boxes.

Re:Not many CPU designs are

[Anonymous Coward]

Let's not forget that Intel taught the entire world about microprocessors when they invented them.

Haven't seen HP or IBM do anything to revolutionise the world like that.

Re:Not many CPU designs are

[Anonymous Coward]

on POWER 3%-5%

We have been waiting to see what impact on performance the Spectre and Meltdown speculative execution patches, which plug some security vulnerability holes that search engine giant Google discovered last summer and made public in early January, would have on Power Systems iron running the IBM i operating system.

Now that Big Blue has published the first edition of the Power Systems Performance Report that includes the new “ZZ” Power 9-based systems, we not only get a sense of the relative performance of the “Nimbus” Power9 chip for entry servers. We also can figure out the performance impact of the Spectre and Meltdown patches as companies apply them. With some caveats.

Let’s start with the good news. Based on some very early renditions of the Spectre and Meltdown patches that were applied to Red Hat Enterprise Linux 7 during the first week that the vulnerabilities were exposed to the general public, we had been expecting that the performance impact on systems running online transaction processing (OLTP) workloads and heavily virtualized environments – like those commonly run on IBM i platforms – could take anywhere from an 8 percent to 19 percent performance hit. Google and Red Hat cautioned that these results were based on so-called microbenchmarks, meaning they were tests that did not necessarily stress the system in precisely the same way as real-world applications and that extrapolating from these tests to your own code was not precisely valid. But, it was all we had at the time to make some contingency plans for dealing with the impact from the Spectre and Meltdown patches. You do what you can with what you got.

We are an empirical lot here at IT Jungle, so we took the March 2018 edition of the performance report and lined it up against the February 2017 version of the document and did some before-after analysis. IBM did not provide any documentation specifically addressing the performance impacts of the Spectre and Meltdown patches, so we had to do the before-after math on every Power8 system in the lineup to see what the impact was, based on IBM’s own Commercial Workload Performance (CPW) test. It didn’t take long for us to see a pattern. Here is what it looks like for entry machines:

We worked backward and estimated what the performance of the Power9 ZZ machines would be if they did not have the Spectre and Meltdown patches applied. And here is what it looks like for bigger NUMA machines based on Power8 processors:

As you can see, the performance hit for the Spectre and Meltdown patches is 5.2 percent of peak raw CPW capacity, except for the Power S812 with a single Power8 cores, which is 5.3 percent. This is a hell of a lot better than taking an 8 percent to 19 percent performance hit.

A few thoughts. First of all, I am immediately suspicious of anything that is this mathematically clean, and although I do not know it, I suspect that IBM may have tested a few machines, got consistent results on them, and then applied an algorithm to the old CPW data to come up with the new post-Spectre/Meltdown CPW data. I don’t have a problem with that so long as it reflects reality, and the whole point of the CPW tests is that IBM is standing behind the relative performance of different processors in the Power Systems line by the very act of publishing these results. IBM never guarantees the absolute performance of any system, although for machines running AIX and Linux Big Blue does have a guarantee that they can be run at a higher sustained utilization than an X86 server of roughly the same raw performance.

Here is another thing to consider. The Spectre/Meltdown patch performance impact on Java virtual machines and database analytics and decision support systems had a more moderate performance hit after the fixes – on the order of 3 percent to 7 percent – in the Red Hat tests, and that is because this software often aggregates requests between the kernel and user spaces instead of streami

So

[Anonymous Coward]

In summary, we're all screwed?

Re:So

[Anonymous Coward]

Nope, just Intel fangirls.

Re:So

[Anonymous Coward]

False. AMD already affected by 4 other variants of Spectre.

Don't be a fucking idiot.

Re:So

[Eravnrekaree]

The variants AMD are affected by are the low risk hard to exploit ones that are a long shot. The intel only one is more trivial to exploit.

Re:So

[gweihir]

We will see whether this holds up, but at the moment Intel is the one that played it fast and loose in order to have a few percent more performance, while AMD was far more careful and conservative and is now far less at risk and maybe not at all due to massively higher effort to exploit the subset of these vulnerabilities where they are affected. It is still possible that an easy to exploit variant will eventually be found for AMD too, but at the moment there is none.

Given that AMD has already done some additional things against this class of exploits in Zen 2, it may be that Intel CPUs will be a continued problem for the next years, while the same things may be more of an annoyance on AMD or not even present. Well, market dominance is never a good thing. Quality almost always suffers and prices get inflated. It would be a good thing if Intel got cut down quite a bit in size.

Of course, many people now have do defend their bad decision to not even have looked at AMD and they are intent to muddy the waters.

Re:So

[Anonymous Coward]

But, was AMD's reduced exposure due to plan or just lack of engineering resources to squeeze the last bit out of their CPUs? It is sometimes hard to distinguish between luck, laziness, and ethics.

Re:So

[Anonymous Coward]

nobody ever got fired for buying intel, versus amd or via for x86 architecture servers /s

Re:So

[AHuxley]

1. Find a university that graduates CPU experts who pass on merit.
2. Get them to focus on security this time, not just how fast.
3. Set up production line.
4. Sell a well designed CPU thats safe and fast.

Re: So

[houghi]

Just before this shotstorm started, i build a new PC an thought: after all these years of AMD, let us go for Intel once. What could go wrong. With my luck, the wholeworld is fucked. Sorry.

Re:So

[Anonymous Coward]

As far as I can say, it is Intel procrastinating all security checks until the retirement stage, at least for Meltdown and some of the Spectre variants. And yes, even when there is a TLB miss and you have to walk the page tables and load a TLB entry, perhaps even displacing a valid one which will be reused soon.
On Power for example the processors do not procrastinate through L1 cache misses, but still through matches, that's why the Meltdown mitigation is a L1 (data side only I believe) cache flush. It is expensive, but no quite as much as a complete TLB invalidation (TLB and L2/L3/L4 caches are still intact).
For AMD, I don't know, but maybe they mark the instruction as not being ready for execution when the protection checks indicate an access violation. After all there is no point in executing an instruction which is guaranteed to terminate in an exception.
Note that the case is complex, there are may be races with other processors updating the page tables (relaxing protection, for example from RO to RW) so you may want to transform this violation into a page table walk, just in case the TLB entry does not (yet) match the updated PTE. On the other hand, when modifying a PTE to more restrictive access rights, the processor doing the update has to signal this fact to the other processors to avoid performing accesses through stale TLB entries, which would be a security hole (on x86 this is an IPI, inter processor interrupt, some other architectures have special machine instructions to signal
TLB invalidations to other processors).

Re:So

[Anonymous Coward]

1. Find a university that graduates CPU experts who pass on merit.

2. Get them to focus on security this time, not just how fast.

3. Set up production line.

4. Sell a well designed CPU thats safe and fast.

1. Unicorn
2. Easter Bunny
3. Leprachaun
4. University that graduates CPU experts who pass on merit.
5. 1 through 4 all have one thing in common.

Re:So

[gweihir]

Does it matter? Their product is superior in a critical aspect.

Re:So

[CanadianMacFan]

It doesn't matter how good the engineer designing the CPU is. They are given the specs for the CPU. During the design they have to make choices to achieve the requirements and any choices that they feel uncomfortable about will be sent up to management to be signed off on. You can be certain that any design choices that trade speed for security in order to make the requirements will have had management made aware and sign off. Upper management at Intel, in this case but at all chip designing companies, have a roadmap for their processors and the engineers made the best trade-offs they thought to meet their goals. Management was more concerned on meeting their goals than putting out secure chips.

I hope everyone in the lower ranks kept their emails with the sign-offs.

We're all doomed

[Anonymous Coward]

Intel should replace all our processors. Even if they're AMD.

Re:We're all doomed

[Anonymous Coward]

No i think the solution would be to never buy Intel again. Think about the hundreds of billion of dollars worth of trade secrets lost because "geek squad" recommended Intel. I want security and performance i choose IBM's POWER architecture. With x86 you get adequate performance now which you can upgrade in three years to reach the performance of the last generation of POWER, and to hell with security did you not say you wanted performance.

Advanced Micro Devices IMMUNE

[Anonymous Coward]

To these Intel abominations of safe computing. One thing to do: DUMP Intel and BUY AMD! Do it now, before it's too late for you, yours, ours!

Re:Advanced Micro Devices IMMUNE

[MachineShedFred]

In big fucking bold print in TFA:

Bug affects Intel and ARM, most likely AMD too

Also from TFA, a table documenting how AMD is affected by other Spectre variants.

Don't be a fucking fanboy, spreading lies.

Re:Advanced Micro Devices IMMUNE

[Eravnrekaree]

Do you work for Intel? AMD is not vulnerable to the newly announced exploits. Also the ones AMD is vulnerable too are low risk and hard to exploit, far lower risk than Intel only ones, which are trivial to exploit. Bottom line: AMD is VASTLY safer.

Re:Advanced Micro Devices IMMUNE

[jittles]

Do you work for Intel? AMD is not vulnerable to the newly announced exploits. Also the ones AMD is vulnerable too are low risk and hard to exploit, far lower risk than Intel only ones, which are trivial to exploit. Bottom line: AMD is VASTLY safer.

AMD has already admitted to being vulnerable to certain variants. Intel has mitigations for the most serious variants in place. The latest round of vulnerabilities have been mitigated through OS fixes. As long as you've been consuming these updates, there is no reason to think that Intel or AMD are in any different position at this point. AMD's pipeline definitely prevented meltdown from affecting them, and most likely makes it easier for them to provide future resiliency through silicon, but I don't see a huge difference between either one as far as the silicon that has already been shipped.

Re:Advanced Micro Devices IMMUNE

[drinkypoo]

Mitigation of prior SPECTRE attacks is cheaper on AMD than on intel. I would be surprised to learn that was not the case again. In addition, it's more difficult to exploit on AMD, and further, AMD was NOT vulnerable to all the classes of SPECTRE attack which affected intel processors. So while you're technically correct, there are also caveats.

Re:Advanced Micro Devices IMMUNE

[Anonymous Coward]

most likely

Meaning there's no proof and the author is just guessing.

Considering that AMD was vulnerable to only a subset of the various exploits and even then usually to lesser variants, that assumption is worthless.

Re:Advanced Micro Devices IMMUNE

[AHuxley]

Thats why its 1.1 and 1.2 with a new list of brands and their CPU's.

Re:Advanced Micro Devices IMMUNE

[jittles]

Mitigation of prior SPECTRE attacks is cheaper on AMD than on intel. I would be surprised to learn that was not the case again. In addition, it's more difficult to exploit on AMD, and further, AMD was NOT vulnerable to all the classes of SPECTRE attack which affected intel processors. So while you're technically correct, there are also caveats.

Based on metrics I’ve seen from Intel, as well as tests performed by my own company, I do not believe that Intel is running any slower than AMD with these mitigations in place. And Intel has given us microcode updates for these fixes long before AMD provided any microcode fixes for their platforms. AMD and Intel have been notified of these issues at the same time. Intel has consistently provided us with fixes prior to the publication of these vulnerabilities and AMD has averaged a 2-3 month delay after notification. AMD is definitely better protected against this type of attack but Intel has been far more responsive to all hardware or firmware vulnerabilities that I’ve seen that affect both platforms.

The caveat to those updates from Intel before the publication is that they have always been beta fixes, though at least 50% of the betas they’ve given us ended up going to production unmodified.

Re:Advanced Micro Devices IMMUNE

[Anonymous Coward]

...though at least 50% of the betas theyâ(TM)ve given us ended up going to production unmodified

And There, my dear, lies the problem that put us unfortunate ones in the crosshairs of greasy russian bums sitting on park benches watching the panties run.

Re:Advanced Micro Devices IMMUNE

[drinkypoo]

And Intel has given us microcode updates for these fixes long before AMD provided any microcode fixes for their platforms.

Many of those microcode fixes were garbage, leading to boot loops, boot hang... Intel does not deserve a reward for pushing out garbage to customers.

AMD and Intel have been notified of these issues at the same time. Intel has consistently provided us with fixes prior to the publication of these vulnerabilities

That is completely false. Intel lagged behind the initial announcement, then started pushing out buggy fixes.

AMD is definitely better protected against this type of attack but Intel has been far more responsive to all hardware or firmware vulnerabilities that Iâ(TM)ve seen that affect both platforms.

AMD did the right thing in the first place, so they are less affected by AFAICT all variants. They can afford to take a couple more days to get it right. They can't afford to push out buggy firmware fixes like Intel can, since they don't have the massive market inertia that Intel does. Thus, they don't have the benefit of as many customers with cognitive dissonance who will justify their purchasing decisions by being Intel's parrot.

The caveat to those updates from Intel before the publication is that they have always been beta fixes, though at least 50% of the betas theyâ(TM)ve given us ended up going to production unmodified.

It's nice you mention that, but it belongs at the top of your comment, not the bottom.

Re:Advanced Micro Devices IMMUNE

[jittles]

And Intel has given us microcode updates for these fixes long before AMD provided any microcode fixes for their platforms.

Many of those microcode fixes were garbage, leading to boot loops, boot hang... Intel does not deserve a reward for pushing out garbage to customers.

They did rollback their Spectre V2 mitigation because it caused problems for some users and an OS mitigation was sufficient.

AMD and Intel have been notified of these issues at the same time. Intel has consistently provided us with fixes prior to the publication of these vulnerabilities

That is completely false. Intel lagged behind the initial announcement, then started pushing out buggy fixes.

I know for a fact that is not true because I receive access to both NDA advisories and NDA microcode updates. Intel did not release a production version of certain server platforms at the time of release because they do several months of testing server microcode before calling it production but the client microcode updates were all tested for at least a month and were made available to OEMs withing a week of the date of publication for the newest variants and prior to publication for the original meltdown mitigation.

AMD is definitely better protected against this type of attack but Intel has been far more responsive to all hardware or firmware vulnerabilities that Iâ(TM)ve seen that affect both platforms.

AMD did the right thing in the first place, so they are less affected by AFAICT all variants. They can afford to take a couple more days to get it right. They can't afford to push out buggy firmware fixes like Intel can, since they don't have the massive market inertia that Intel does. Thus, they don't have the benefit of as many customers with cognitive dissonance who will justify their purchasing decisions by being Intel's parrot.

I have acknowledged that AMD did a better job to prevent this specific type of attack. The only practical attack has been a problem strictly for Intel. But they have been just as slow to push fixes for Ryzenfall, etc as they have been for Spectre. And it’s not just a matter of development. It’s a complete lack of communication. It takes me months to get information out of AMD and Intel proactively meets with me almost monthly. I know that they were not given a fair shake with the disclosure of Ryzenfall and I don’t really have a preference for Intel or AMD in my personal life. But I can tell you which company is a lot easier to deal with in my professional life and it’s not AMD.

The caveat to those updates from Intel before the publication is that they have always been beta fixes, though at least 50% of the betas theyâ(TM)ve given us ended up going to production unmodified.

It's nice you mention that, but it belongs at the top of your comment, not the bottom.

Why does that really matter? Did I say that the publication date fixes were beta? No. I said that the pre-publication fixes that Intel provides me for validation have been betas. That’s normal. But over half of those beta fixes also end up being the production fix. I can do a binary comparison between them and see they’re identical. This is how I can assert to you that Intel pretty much has a fix ready before publication.

That's it, I quit

[Anonymous Coward]

I'm done with this bullshit. I can't take the truckload of fail that all of this Spectre stuff is. I'm done with modern society. I'm moving to the middle of fucking nowhere. I'm done. We're pretty much all fucked here.

Re:That's it, I quit

[Anonymous Coward]

I'll pass on the Berthold Ray's kthx.

Quick - Panic!

[GerryGilmore]

Can we be real for one moment, please?
In the realm of software vulnerabilities, these are:
1) Ridiculously difficult to implement. At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache. Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?
2)Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.
3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.
4) Derived from 3), for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus. Meantime, everyone is running around wanting to burn their CPUs because they are "vulnerable".
FFS!! Does NO ONE have ANY perspective left anymore?!? /rant

Re:Quick - Panic!

[Anonymous Coward]

1) Ridiculously difficult to implement.

It only has to be implemented once and copied. Re: Life.

2)Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.

Until viruses use it. Viruses were original POC.

3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

Re: Javascript

4) Derived from 3), for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus.

And one based on Meltdown and/or Spectre could potentially bypass all security without any possible generic fix. So, obviously it'd be nice to know about it.

Meantime, everyone is running around wanting to burn their CPUs because they are "vulnerable". FFS!! Does NO ONE have ANY perspective left anymore?!? /rant

Yes, /rant. Who's going around burning their CPUs? The point is to find out as many of the vulnerabilities now to start introducing fixes in hardware. And knowing there are more varied variants means the fix needs to be more generic. It also means that we have to start honestly considering the possibility that javascript can be an attack vector against CPU bugs, so that's something to mitigate against where reasonable.

But, yea, let's not point out the potential scope of this or light an impetus to change CPUs to mitigate these risk! We should just not really cover it. Then if/when the attacks do come because people find out how to make them more doable, we're then really boned. I mean, it's not like it takes years for CPU designs to be developed and deployed to replace current CPUs.

Re:Quick - Panic!

[Anonymous Coward]

Re: Javascript

Not just Javascript.... Think Docker, VMware, Azure, AWS....
Anything running "untrusted" code.

Re:Quick - Panic!

[Anonymous Coward]

3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

Please tell that to all of my friends and family who insist on running mobile apps from god knows where, and browsing with Javascript enabled.

As to the rest of your arguments, I'd just remind you that attacks only ever get better. And the attacks that are known to the bad guys are by definition a superset of the attacks known to the public.

Re:Quick - Panic!

[Anonymous Coward]

Please tell that to all of my friends and family who insist on running mobile apps from god knows where, and browsing with Javascript enabled.

Would it make sense to have OS and higher security processes use cores that are segregated from what your typical web browser uses? Then maybe we can run critical sites on a dedicated processor core?

Of course, some cache is shared, so if this affects that then it wouldn't work, unless you segregated the cache. Also throwing cores at the problem is hardly efficient, but I could see it being done in certain cases.

Re:Quick - Panic!

[nuckfuts]

3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

You're not thinking about the countless virtual machines running on someone else's hardware (i.e. "The Cloud"). It's not "your" computer that must be compromised. It's the hypervisor that it's running on, or possibly someone else's VM running on the same hypervisor.

Re:Quick - Panic!

[GerryGilmore]

OK, show me a WORKING implementation where a guest OS can read anything useful out of a hypervisor's cache. Does anyone have ANY idea of how hard it must be to grab a (roughly) 16KB of cache data (presuming that it is 100% accurate, of which I am yet to be convinced) and determine exactly what that chunk represents?
I'm still calling Shenanigans on this vulnerability being useful in any real context, until/unless someone can demonstrate: reading cache data via this vulnerability and THEN knowing just WTF that data was!

Re:Quick - Panic!

[complete loony]

Ridiculously difficult to implement.

Once.

At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache.

Correct.

Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?

By using the value you read to trigger another read somewhere else and tickle even more cache timing. You want to trick the CPU into doing something like;

var x = big_array[ (*pointer_to_sensitive_byte) * cache_block_size ];

Then you measure the cache timing of each block of your big_array. And repeat the process for every pointer you want to read.

Beyond trial code that is ALL based on the original POC distributed by virus vendors, etc. there is NO known implementation in the wild.

The original Spectre / Meltdown flaws were separately discovered by multiple researchers at the same time. Do you still feel safe?

This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

Javascript, Cloud VM's, Untrustworthy phone apps. Do you personally audit all the code that's running on "your" computer?

for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus

Quite likely, since a patched machine should be less vulnerable, and if you are un-patched there are lots of other vulnerabilities that are easier to exploit. Security is like playing whack-a-mole, if there's just one flaw that you don't fix, you've failed.

Re:Quick - Panic!

[GerryGilmore]

You failed, fundamentally, do answer my largest question: Presuming that you can read a blob of data from cache (which, yes, can be done...), show me how you make sense of that data?!?
Is it code? Is it data? How Da Hell do you know? I've heard Peter on Ars go on and on about how your passwords are leaked. Bullshit! Show me how (other than, say, running 'strings' or 'grep') on a small pile of cache data and make fucking sense out of it!
Regular viruses KNOW what they want and grab it. This is cache-tickling looking for a needle in a tremendously large haystack!

Re:Quick - Panic!

[complete loony]

If I received a dump of memory from a process there's probably a lot I could work out just from a hexdump as well as running strings or grep. I've personally reverse engineered a few proprietary binary file formats by making small changes in an application, then staring at hex dumps of the saved files.

It's not a huge leap to do the same with the RAM of a target program. Run it in a debugger, make small changes and watch where those changes are written. Once you work out what to look for, then you automate the search in the virus.

Re:Quick - Panic!

[Anonymous Coward]

There's a very simple solution to this: use microcode to add ring0 instruction that disables the cache. Then let the OS expose a way to mark a process as trusted. Any process not explicitly flagged as trusted gets to run without cache, and on top of that, even if the browsers were marked trusted, they'd all still fork themselves and run their JS in un-trusted child processes.

Re:Quick - Panic!

[Anonymous Coward]

You can already do that on nearly all x86 and ARM cores. The performance hit of disabling the cache subsystem depends on the type of main memory and type of code you run but will easily lead to a 10-40 times slowdown.

Re:Quick - Panic!

[phantomfive]

Most of us run Javascript on our machines all the time, so in that sense, we're vulnerable.

If you want to see how far exploiters will go to take advantage of these things, check out heap spraying. It took a few years to invent heap spraying, but now it's considered a basic technique. We don't see exploits in the wild yet because it's still new, but soon we will.

Re:Quick - Panic!

[Anonymous Coward]

I presume you'd want explosions as proof that you're standing in a minefield if someone told you'd wandered into one before you consider backtracking back to safety too?

Surely you had to burn yourself pretty badly before believing that stoves are hot.

Re:Quick - Panic!

[Anonymous Coward]

You failed, fundamentally, do answer my largest question: Presuming that you can read a blob of data from cache (which, yes, can be done...), show me how you make sense of that data?!?

You do it with a monoculture.

You aren't getting a random blob of data that you are trying to make sense of.
Instead you have a program that you know that a lot of people are running, for example a password manager.
You can run this manager on your own computer and figure out how it works and what its cache footprint looks like.
Now, once you know that, you are trying to find a match in the blob of data. Once you have it you can extract cached data from the manager.

The one trying to exploit the system knows what they are looking for and are using automated tools to find it.
It is basically the same thing as the access logs you see when some script kiddie tries to access a list of known wordpress files because they know about a common exploit.
Sure, you might not have it installed and even if you do you might have fixed the issues, but that doesn't matter because they will find a match sooner or later, not just on your computer.

So, what they will do is hide some javascript crap in an ad that is served to thousands of websites.
It doesn't matter who they get from it, they are just running a fishing expedition and are satisfied with anything they can make sense of.
They will probable just match with a dozen or so different programs that may contain sensitive data.
On most computers they won't find anything, but it doesn't matter because they get to test millions of computers.
They aren't trying to get to your computer specifically, anyone will do. Maybe the stars will have to align and the processes executed in the right order for the exploit to work, but it doesn't matter because they get a lot of tries.

Most exploits work like this.
People breaking into cars doesn't single you out first and look for your car later. They just pass down the street and scouts for cars that looks vulnerable.

Re:Quick - Panic!

[thegarbz]

It only has to be implemented once and copied. Re: Life.

Actually no it doesn't. This isn't exploiting specific software, it's exploiting the CPU to read specific registers. The exploits are specific to both timing and system configuration at runtime and you have to have an incredible amount of access to a machine to make a meaningful exploit (reads: maybe you're running a VM owned on someone else's metal, or you've already 0wned the machine).

Until viruses use it.

Translation: Everything is safe until it's not. Analysis: An incredibly dumb arguement.

Re: Javascript

See 1. There's no generic fly-by implimentation that you need to be worried about and given the ability to specifically sandbox the exploit in the browser by playing with Javascript execution this is the least likely attack vectory

Re:Quick - Panic!

[Anonymous Coward]

Look at the heartbleed exploit. Here it was possible to grab a random 64KB chunk from the process using OpenSSL. At first it was said to be unexploitable in practice for the same reason: it is not possible to make sense of the data. Quickly POCs were developed that could obtain the server private key etc.

Re:Quick - Panic!

[freeze128]

So why should *I* run out and get an AMD processor if it's AWS and Azure that's vulnerable?

Re:Quick - Panic!

[Anonymous Coward]

ASLR bypasses aren't real. Cryptomining in the browser isn't a thing. MD5 hash collisions are only hypothetical. Yea, I'm going to go with you're underplaying the risk with assertions based upon current implementations. Repeatedly it's been demonstrated that attacks can be optimized greatly. Perhaps Spectre and Meltdown will be eventually shown to be impossible outside of long control flow control so executing time block sandboxing will be effective. I think it dangerous to presume this, though.

Re:Quick - Panic!

[rahvin112]

If you use a browser and visit websites you are running random code you didn't purchase and probably have no idea what it does. The average website these days executes around 30 scripts from at least 8 different sources but possibly as many as 20 different sources. I've seen websites that had as many as 50 scripts running from upwards of 20 different sources.

There's a reason people use NoScript in Firefox, all those scripts are potential exploits. Even running in a sandbox they are capable of exploiting Spectre/Meltdown. That should scare the daylights out of you.

Re:Quick - Panic!

[imgod2u]

1) Ridiculously difficult to implement. At the end of the day, you are fundamentally tickling the cache and timing the resultant reads to try to determine the content of that cache. Is there ANY reasonable way to "read" the contents of said cache and determine what context a blob of data means?!?

Not that difficult. It just takes a long time as you're relying on certain processor timings. And you also have to target it to the specific microarchitecture you want to attack. So in that respect, it's difficult in that you can't just release one set of code and expect it to work with everything. But if you were to target, say, a device with Snapdragon 845 or an Apple A11...

3) This requires the virus to be running ON your fucking computer!! If you are running ANY virus on your computer, you're hosed.

Every time you visit a website, you're running external Javascript code on your computer that you haven't vetted. Even scarier, if you rent an AWS session, you get a VM that you have all sorts of permissions to run whatever code you want on it.

4) Derived from 3), for the forseeable future ANY virus on your system is about 28Giga-times more likely to be a standard, run-of-the-mill virus. Meantime, everyone is running around wanting to burn their CPUs because they are "vulnerable".

The issue isn't so much your dad with his Windows ME machine being hacked. I mean, we all know that's going to happen. The issue is that previously thought to be super-secure computing domains (AWS, Azure, bank servers, The Pentagon, iOS walled garden) now has a flaw that no one really quite knows how to fully fix yet.

Re:Quick - Panic!

[imgod2u]

The Meltdown demos (from the original researcher) was able to read secure passwords stored in the OS that were supposed to be secured. This wasn't some elaborate setup. This was the guy (the researcher's) personal computer that he just happened to run the code on.

meh

[DulcetTone]

These flaws are confined to test cases and proofs of concept. I'm going to wait for Spectre 2.0 (or 2.1, for the bugfixes)

They tested ARM and Intel not AMD

[Anonymous Coward]

Why?
from TFPdf

Thanks to Intel for their partial sponsorship of this re-
search conducted in February 2018.

Sorry AMD, you have to conduct your own study to see if you're vulnerable! (Or pay us to do it)

Solution to ALL such problems: Physical Isolation

[Anonymous Coward]

Hardware is getting quite cheap. How about running sensitive code and untrusted code on separate pieces of silicon? (memory and processor at least) -- Let the untrusted code run fast and efficient on one component (depending on the setup, it could even reasonably be native code), and the secure or sensitive code run on a separate component which is secured against as many side-channel attacks as is practical.

some architecture not on list

[iggymanz]

Don't see Ultrasparc on list of vulnerable CPU. Of course, I don't see it in any of the three locations of systems I admin either though 8D

Re:some architecture not on list

[drinkypoo]

I thought everyone had got rid of all their SPARCs by now? The sun machines are now antiques, and anyone who gives ORACLE money deserves the fornicating they're getting.

Re:some architecture not on list

[rahvin112]

It's probably not listed because it's unknown because no one bothered to look due to the size of the market.

Re:some architecture not on list

[psergiu]

It seems that Oracle fired ALL the Sparc CPU engineers.
The Sparc CPUs might as well be vulnerable as Oracle has not released ANY statement since the beginning of the Specter/Meltdown fiasco to say whether their CPUs are vulnerable or not.

Re:For some of us it was not a bad decision

[Anonymous Coward]

1. You bought cheap components. You will get the same lockups on intel if you buy a $50 USD motherboard and $100 USD CPU. I don't know of anyone who got 'random lockups' on an FX processor.

2. Basically what you're saying is you'd rather leave your front door unlocked entirely than have a door that sticks shut on rare occassions and you have to wait 1 minute for it to open?

In other words, your comment is not even insightful. Its not even whining. Its just plain dumb

Re:For some of us it was not a bad decision

[drinkypoo]

You have been doing things wrong, then. I have been using AMD processors literally since the K6, and that was literally the last processor to give me any kind of trouble. And the last K6 I owned was in a laptop and gave me literally zero trouble (although the garbage ATI rage pro lt sure did.) My current PC has an FX-8350 and a pair of Zotac GTX 950 AMP! cards in, and has literally been my most trouble-free hardware ever - and I've owned SGI, DEC, Sun, IBM, Apollo, Amiga, Macs... You name it.

The K6 that caused me problems had a VIA chipset. Yep, there's the problem, it says VIA on it.

Re:For some of us it was not a bad decision

[Anonymous Coward]

system so unstable as to be nigh unusable

Yea ... no, I call bullshit. Having used AMD for about two decades on multiple OS, whatever caused your issues isn't their fault.

Think of the children

[ElizabethGreene]

Can we please call these something other than Spectre and Meltdown? We're well on our way to Baskin Robin's 31 flavors of S&M.

Re:Think of the children

[rahvin112]

Meltdown is a specific attack, none of these new ones are Meltdown. Spectre is an entire class of attacks and it's going to have a ton of variants. There was a report about a month in a German magazine that they've already numbered Spectre out to 11 variants and counting that will eventually be divulged.

There were broad warnings when Spectre was revealed that this would be the exploit that would keep on giving because it used a new line of attack that's been known about for years but was finally shown with a working exploit for the first time with the Spectre release. As this line of attacks is central to how modern processors are built there could be 30 or 40 variants by the time this all sorted out.

The only thing going for us in this case is that these timing attacks are difficult to execute, but it won't be long before a clever coder has found a way to automate them and put them into a drive by exploit like Javascript attached to a advertisement.

watch Spcetre

[reviewcartz]

watch it on terrarium tv terrarium tv

This hits SPECIFICALLY INTEL cpus

[Kartu]

This hits SPECIFICALLY INTEL CPUs yet is presented as "AMD too".

Re:This hits SPECIFICALLY INTEL cpus

[Anonymous Coward]

The vulnerability has been observed on Intel CPUs because Intel is the one offering the huge bug bounty.There's no proof this new vulnerability can be exploited on AMD, but you'd be an idiot to claim AMD is immune to this one. It's been vulnerable to all the other variants so far detected, as has ARM. The flaw is there due to speculative execution, not to the specifics of any one geometry, so exploiting it on AMD is expected to be just be a matter of putting forth the effort.

Re:This hits SPECIFICALLY INTEL cpus

[drinkypoo]

There's no proof this new vulnerability can be exploited on AMD, but you'd be an idiot to claim AMD is immune to this one. It's been vulnerable to all the other variants so far detected, as has ARM.

That is a lie. AMD is not vulnerable to all the other classes of SPECTRE exploit, nor are their CPUs vulnerable to MELTDOWN.

Further, mitigation is cheaper (nearly free) in the cases where AMD is vulnerable.

FPGA CPU is the solution maybe?

[Anonymous Coward]

If all computer CPUs were FPGA-based, then any CPU hardware bugs could be fixed by just downloading an updated CPU-design (just like downloading updates for software bugs today)!

FPGA-based CPUs would also allow CPU design upgrades, and also would allow quickly switching between different CPU types/designs (depending on what kind of software application user runs)!

Re:FPGA CPU is the solution maybe?

[Anonymous Coward]

Sure, it's actually very easy to do, you just need to:

-scale back the L1 and I/D caches to about 8k, since FPGAs have limited memory
-get rid of the L2 cache, since most FPGAs don't have the bits for it.
-get rid of the L3 cache, since most of the FPGAs don't have the bits for it.

-dial back the frequency, to about 500Mhz , probably slower, since FPGAs don't have the tightly interconnected resources for it.
-get rid of the intergrated memory controller, since this requires lots of small cache rams and linestores
-get rid of multi-core
-get rid of hyperthreading

so, you would have something like an overclocked pentium at best. and it still wouldn't be secure, because things can go in and change the bitstream, reconfiguring the "CPU".

Re:FPGA CPU is the solution maybe?

[Anonymous Coward]

Rarely do I see a "clever" post so thoroughly pwned by an actually-clever post. Bravo.

Re:For some of us it was not a bad decision

[Carewolf]

I too had stability issues with the K6... It turned out it was related to the VIA chipset, and more specifically the drivers.. Not that they were buggy, no no, they failed to handle buggy 3Dfx, buggy NVidia and buggy Soundblaster hardware that were all violating the PCI standard, and when you had two of them (which most gamers had), there were small but non-zero chance they would step on eachothers toes due to their abuse of the PCI standard and fuck the system state up.

The non-VIA drivers and Intel BIOS all had work-arounds to keep those buggy hardware in check. After the issue was fixed in a VIA-driver update, there were no more crashes.

But as often is the case. The blame lied nowhere close to whom most people blamed.

Re:creimer is fat and a gay!! Everyone say 'Yay!'

[Anonymous Coward]

It's not creimer's obesity that bothers me, it's the smell.

Re:For some of us it was not a bad decision

[gweihir]

Same here, although I started with the K5.

Re:For some of us it was not a bad decision

[samwichse]

My AMD k6 was great!

I had trouble with my slot-A Athlon 750 back in the day.

I bought the cheapest, trash motherboard with the even more trash Via KX133 chipset on it. The KT133/KT266 went on to be a pretty much legendary value, but that KX133 was basically beta-quality. Should have spent the extra $20 on the AMD-750 chipset instead, but you live, you learn.

My next one was a socket A with a KT133A, ran like a top with a heavily overvolted/overclocked Duron, haven't had any trouble since (Athlon XP, Athlon64).

Got my eye on a Ryzen 2400G for my next machine. Well, for home.

For work, I'm looking at dual 24 core Epycs...

Re: For some of us it was not a bad decision

[Anonymous Coward]

You had bad hardware. You should have done proper troubleshooting and fixed it or just had someone who knew what they were doing build your PC.

U R spoiled

[Anonymous Coward]

Do you know what all the scientists in the world, 100 years... shit, 50 years ago, would do to you to get their hands on a TENTH of the processing speed and power you are whining about being left with, if ONLY they could? People dont know how good they have it.

Hrm

[drinkypoo]

30% Informative
    40% Flamebait
    30% Interesting

So the question is, did I get modded down by employees of Intel for saying nice things about AMD, by employees of AMD for saying mean things about ATI, or employees of VIA? No, wait, couldn't be that last one, their computer would have crashed before they got there.