"new ways to leverage Spectre"
Please. Stop the twaddle
Researchers have unearthed a fresh new set of ways attackers could potentially exploit data-leaking Spectre CPU vulnerabilities in Intel chips. German publication Heise reported that eggheads are preparing to disclose at least eight new CVE-listed vulnerability reports describing side-channel attack flaws in Chipzilla's …
What arrant bu***hit.
Protecting their market share, their relationship with Fort Meade and Redmond are critical priorities.
People pay through the nose to run Windows and the MS stack. If they don't need to do that they don't need Intel.
But the playing field is leveling.With linewidths down to 90 atoms across even Intel's lead in smaller transistors will vanish
Actually, switching to an ARM architecture likely would not fix it. ARM had "no comments " on these vulnerabilities, but it looks like everything with predictive branching is vulnerable. So, looks like pretty much everybody fell into the crapper on these, and they all stink alike.
Arm is pretty much in the clutches of Spectre, which is of course an industrywide misstep in secure processor design.
Here's a table of affected Arm cores. Variant 1 + 2 are Spectre. 3 is Meltdown.
Personally speaking, things like RISC-V can't come soon enough. Perhaps it's because I'm getting old, but I kinda prefer my hardware to be secure rather than fast.
Personally speaking, things like RISC-V can't come soon enough.
RISC-V has its advantages, but immunity to Spectre-class attacks is not one of them.
Of course, it's possible that someone will eventually ship a general-purpose machine which 1) uses RISC-V cores that do not have spec-ex; 2) is suitable for your purposes, including in its performance; and 3) isn't prohibitively expensive (economics of scale still apply, after all). But getting the performance most users (personal and commercial) want without spec-ex is not going to be easy - pipeline stalls are hard to overcome.
"RISC-V has its advantages, but immunity to Spectre-class attacks is not one of them."
Um. "No announced RISC-V silicon is susceptible, and the popular open-source RISC-V Rocket processor is unaffected as it does not perform memory accesses speculatively." [RISC-V Foundation]
No available RISC-V cores right now do spec-ex in a way that can be exploited, Spectre-style. They don't perform the level of out-of-order execution seen in CPUs from Intel et al.
A 64-bit 1GHz RV64G (64-bit RISC-V with IMADF extensions) SoC is available to order from SiFive that runs Linux. Exciting times.
No announced RISC-V silicon is susceptible
Correct. But there's nothing stopping anyone from making a RISC-V CPU that does spec-ex. RISC-V does not prevent Spectre; not using spec-ex prevents Spectre. And you can make a processor for any ISA that doesn't do spec-ex.
There are non-spec-ex ARM CPUs (eg Cortex-M1). If you can find an Intel Atom made before 2013, you'll have a non-spec-ex x86 CPU. You could fab your own non-spec-ex MIPS CPU. Grab some Z80 cores for old-fashioned 8-bt non-spec-ex fun, and so on.
There's nothing special about RISC-V in this regard. It's simply a historical accident that no one's made a spec-ex RISC-V CPU.
Although I'm not sure that a full Window port to ARM would solve all these problems.
I can assure you it would not.
Speculative-execution side-channel vulnerabilities are a large class. They're going to apply to all speculative-execution CPUs used to run multiple processes with different trust domains in general-purpose workloads. Blinding all side channels caused by speculative execution is a prohibitively expensive game of whack-a-mole.
This is not an Intel issue. It's not an AMD issue. It's an issue with superscalar speculatively-executing CPUs, and more generally with the intersection of information and thermodynamics. You want speed within a reasonable power / heat dissipation envelope? Then you're going to leak information.
I'm sorry, but the FAIL you have tendered has been FAILed. Please hang up and dial again.
Apple uses x86. Intel x86 in fact. *nix predominantly uses x86. Intel x86 in fact. MS software also happily runs on AMD CPUs. Which are also affected by Spectre flaw variants. MS software (some versions) run happily(?) on ARM CPUs. Which are also affected by Spectre flaw variants. And for the fun of it, even PowerPC was proven to be vulnerable to Spectre!
So, in short, EVERYONE* is affected in a meaningful way, and have been for a VERY long time. This has absolutely nothing to do with any specific company or product.
*=This was a bright idea for improving performance, used by almost everyone in almost everything, turning out to have a dark consequence that went unnoticed for too long and unraised for even longer.
We wouldn't be in this situation if someone came up with a technology to create RAM with latency lower than 10ns, within sane power budget and fabrication cost. As the things stand, we need multiple levels of caches with very limited capacity and a significant chunk of CPU space and power is used for speculative execution, cache preloading etc. just to ensure we have full instruction pipelines and data at hand when needed. This is where the complexity is coming from.
"We wouldn't be" ... "if" ... "technology" ...
In my view ...
...this is not a point of technology.
We need a culture change in the way we design.
And CPUs or IT are just one sector to look at.
"secure by design" is a good first step.
There is no one guarantee us its the only step we need to do. But every journey starts with the first step. There is definitively no simple solution. If one proclaim one its a lie.
@Dr.Sommer Like most timing attacks, Spectre is more subtle than that. Robust safety principles directly contradict the performance goals, because in order to hide the data that the attacker should not have access to, you would have to add delays to his data accesses. Since obviously, you have no idea if the process being run at the moment is controlled by an attacker or not, this means adding delays to everything. Show me a vendor who will argue that his ware is better than the competitions because it is resistant to a fairly obscure mode of attack even though the security measure applied makes it few percents slower. Do you think they will continue selling such ware for much longer?
@bronek if the computer didnt execute (speculativley) instructions before checking the process was allowed to execute them, then spectre wouldn't work.
This is Intels relentless persuit of Moores law comming back to bite them on the ass, nothing more nothing less. AMD and ARM got caught up because they had to compete, but both have introduced a lot less flaws in their architechture than big Int, AMD even had a lead at one point.
Nope, you confused Metldown with Spectre. The only check the CPU can do and is responsible for is moving the data between the rings, which is what Intel got wrong (and AMD did right). The program logic, on the other hand, is a different story. Most execution branches have nothing to do with security (data access enforcement, authorization etc.), so penalising all speculative executions in the name of robust security checks would have exactly the effect I described - much slower CPU, for little gain. The difficult task of figuring out which execution branches are related to security is (apparently new) job of the programmer, perhaps helped by the compiler, and then securing those (e.g. with a reptoline). Which is why we now have slow, steady and continuous trickle of patches in Linux kernel.
So the first of this next batch, according to downmarket so-called "rivals" to The Mighty Reg, will be released on Monday 7th May. Which, yes, is predicted to be that rarest of things, a warm sunny May bank holiday.
Not to worry, I was already going to be working through the weekend to help fix 30y of accumulated sec debt. Sec debt? It's a bit like dogshit. So picture a cupboard crammed with 30 years worth of barker's eggs.
The key one of this new Spectre-spawn actually does have a lot of potential - for damage, that is. Apparently, targeting this primo variant can allow an attacker to access several, possibly even all VMs running on a server, harvesting user names and passwords along whatever files are to be had. With AWS, Azure &Co. running a lot of government services these days, there is plenty of yummy secrets to be slurped (and for once, not by Facebook or Google) . Intel's statement is remarkable, as it doesn't dispute any of this.
As a question: is current Big Iron immune to any or all of this?
As a question: is current Big Iron immune to any or all of this?
What Big Iron are you thinking of? IBM's z CPUs have speculative execution, and so almost certainly have Spectre-class vulnerabilities.1
To be honest, much of the security of zOS comes from better operational security: more monitoring, more restrictions on outside access, etc. In particular, it's obviously very helpful for security that random users aren't installing software on zOS, running browsers on it, and so forth. The security facilities in zOS (mainly SAF plus RACF, ACF, or Top Secret) are nice, but they're not a silver bullet.
Mainframe hackers like Phillip Young and Dominic White have shown just how very vulnerable many zOS installations are in practice. People leave APF-authorized libraries wide open; they put sensitive data in hidden 3270 fields; they use well-known credentials.
1Meltdown is a subset of Spectre, where the information leakage crosses a privilege boundary and not just a process-isolation one. Meltdown-class attacks have primarily been demonstrated for Intel CPUs, but some others (e.g. some ARM cores, though I think those designs are not yet in production) have been shown to be potentially vulnerable as well. In any case, Spectre is the real story; Meltdown is just a particularly enticing subplot.
I'm going to keep banging on this drum. The performance gains of speculative execution at the processor level are two+ orders of magnitude. This cannot be covered up at the system level. Retpoline and similar efforts will either not be completely effective or will have substantial performance impacts. New processor designs to avoid the cache timing effects basically require that you double the amount of silicone for the same size cache, plus add some quite complicated control logic. Even then, you will get some slowdown because of the time required for the logic to operate and the longer lines to the caches.
OTOH, in trusted computing environments, all of that can be skipped. I'm pretty sure that the trusted computing environment is large enough to sustain the current model. It will grow when the performance/cost advantages become clear.
basically require that you double the amount of silicone
Whoa, now. No need to go all Bulgarian on us.
in trusted computing environments, all of that can be skipped
Citation, please. What sort of TCE are you referring to? None of the ones I'm familiar with are guaranteed to block all side-channel information leakage.
You're correct that discarding spec-ex and blinding side channels are both likely to be prohibitively expensive, and the many people crying for "Spectre fixes" clearly don't understand the problem. But by the same token, holding up any technology or architecture as the solution is suspect. There aren't any silver bullets.
I'm basing my observations on the 10 years of microprocessor validation (at AMD & IBM) that I did ten years ago.
All of the spec-x side channels that I am aware of have to do with cache flushing, for a suitably broad definition of "cache". One may therefore eliminate these attacks by ensuring that speculative fetches don't result in flushed caches. The naive approach would be to use orphan buffers. These orphan buffers would have to have the same response times as the caches that they are replacing. Not a designer, but "good luck with that". Just as high-waycount caches don't use true LRU logic, I think that it is much more likely to use cheaper solutions, like prefetch buffers which are basically a copy of the main cache. Since caches have dominated processor area for generations, I'm saying "doubling". It would be nice to be wrong.
Sorry about not being clear wrt TCE. I'm specifically ruling out consumer processing, or any environment wherein bad applications might be run, such as anything AAS. For instance, if the environment only ran a single application which only made use of the data of a single entity, the environment is trusted because there is simply no one and no thing to distrust. Industrial controls, special-purpose supercomputers, those sorts of things are places where systems might be designed this way. Definitely not a silver bullet, but rather an affirmation of the claims made by some vendors that using a SPECTRE-vulnerable processor does not mean that the appliance in question is thereby insecure.
All of the spec-x side channels that I am aware of have to do with cache flushing, for a suitably broad definition of "cache".
The original Spectre paper suggested some others, such as ALU contention. Whether those leak information at a rate fast enough to be useful to an attacker remains to be demonstrated, as far as I know.
Sorry about not being clear wrt TCE. I'm specifically ruling out consumer processing, or any environment wherein bad applications might be run, such as anything AAS.
Ah, OK. Thanks for the clarification. Agreed, if the system doesn't run code in different privilege domains, then you don't have to worry about intra-system side channels. (You might still have to worry about side-channel leakage outside the system, but that usually requires physical proximity, at least for a sensor to pick up the leaked information.)
This post has been deleted by its author
After the last Spectre reveal I invested in the newest fastest hardware available that was immune, the stunning (hmm) Atom D2700. A screaming 2.1GHz dual core Atom with Hyperthreading - but with in-line execution and no speculation/branch prediction/out of order execution - and no management engine.
On its Zotac motherboard with a GT520 taking over from the awful graphics and an SSD with 4GB RAM to perk it up the thing actually runs 64-bit Windows 10 and is surprisingly fine to use - given that you don't try running anything too heavy to think about. It'll stream 1080p video from the web no problem for example.
Would have been interesting to see if anything could have been done with that core given some development resources. Still nice to try and get the most out of some underpowered kit just to see if it was viable.
ARM Cortex A7 is not affected by Spectre or Meltdown.
and note the statement above the table listing affected processors that
"Only affected cores are listed, all other Arm cores are NOT affected."
No one has mentioned a REALLY simple fix -- just take the CPU off the network!
This would limit the damage for workstations which only need network access some of the time.
Of course, if you are wedded to "the cloud", or are locked into web-based applications, or are using a Cloudbook, I guess you just have to wait for the CPU suppliers to fix their product.
Biting the hand that feeds IT © 1998–2020