The Elite Intel Team Still Fighting Meltdown and Spectre (wired.com) 100
Throughout 2018, researchers inside and outside Intel continued to find exploitable weaknesses related to Meltdown and Spectre class of "speculative execution" vulnerabilities. Fixing many of them takes not just software patches, but conceptually rethinking how processors are made. From a report: At the center of these efforts for Intel is STORM, the company's strategic offensive research and mitigation group, a team of hackers from around the world tasked with heading off next-generation security threats. Reacting to speculative execution vulnerabilities in particular has taken extensive collaboration among product development teams, legacy architecture groups, outreach and communications departments to coordinate response, and security-focused research groups at Intel. STORM has been at the heart of the technical side. "With Meltdown and Spectre we were very aggressive with how we approached this problem," says Dhinesh Manoharan, who heads Intel's offensive security research division, which includes STORM. "The amount of products that we needed to deal with and address and the pace in which we did this -- we set a really high bar."
Intel's offensive security research team comprises about 60 people who focus on proactive security testing and in-depth investigations. STORM is a subset, about a dozen people who specifically work on prototyping exploits to show their practical impact. They help shed light on how far a vulnerability really extends, while also pointing to potential mitigations. The strategy helped them catch as many variants as possible of the speculative execution vulnerabilities that emerged in a slow trickle throughout 2018. "Every time a new state of the art capability or attack is discovered we need to keep tracking it, doing work on it, and making sure that our technologies are still resilient," says Rodrigo Branco, who heads STORM. "It was no different for Spectre and Meltdown. The only difference in that case is the size, because it also affected other companies and the industry as a whole."
Intel's offensive security research team comprises about 60 people who focus on proactive security testing and in-depth investigations. STORM is a subset, about a dozen people who specifically work on prototyping exploits to show their practical impact. They help shed light on how far a vulnerability really extends, while also pointing to potential mitigations. The strategy helped them catch as many variants as possible of the speculative execution vulnerabilities that emerged in a slow trickle throughout 2018. "Every time a new state of the art capability or attack is discovered we need to keep tracking it, doing work on it, and making sure that our technologies are still resilient," says Rodrigo Branco, who heads STORM. "It was no different for Spectre and Meltdown. The only difference in that case is the size, because it also affected other companies and the industry as a whole."
Intel shits bed massively, hires cleaning crew (Score:2, Insightful)
To clean their massive shitty bed.
Re: (Score:1)
Job creators at work here, amirite?
Re: (Score:1)
I'm pretty sure they wouldn't have to look further than their own team.
Re: (Score:2)
Meltdown affect POWER and some ARM processors too.
Re: (Score:2)
Re: (Score:1, Informative)
Wrong. [ibm.com]
Potential Impact on Processors in the POWER Family
the third vulnerability, CVE-2017-5754, is known as Meltdown, and allows user-level code to infer the contents of kernel memory.
The Firmware and OS patches released by IBM in February and March 2018 to address the original Meltdown vulnerability (CVE-2017-5754) also address the L1TF/Foreshadow vulnerability, except for Power 9 Systems running with KVM Hypervisor. OS patch for Power 9 KVM Systems will be made available soon. The Firmware and OS patches for all other Power Systems are available in this blog below.
We are committed to helping our clients address these vulnerabilities and have introduced an offer for pre-POWER7 clients to upgrade their security profile and protect against Spectre and Meltdown through the purchase of POWER8 or POWER9 systems and available migration services, security support, and financing offers.
Re: (Score:2)
Re: (Score:2)
It's OK. You still have my permission to feel superior to me. Just have a nice day.
Re: (Score:1)
It's OK. You still have my permission to feel superior to me. Just have a nice day.
What Related this articles?
Re: (Score:2)
Do they hire Fortran developers? (Score:2)
Re: (Score:2)
Going down the glowy blue CGI mess, you mean.
Those movies were so fucking awful.
Better solution: less Intel (Score:3)
Re: (Score:2)
It's great to see ARM chips take off in popularity. In ten years, Intel will be like Sun is now. ("Intel, like the old chipmaker gramps?")
I would like to see more ARM, RISC-V, and MIPS chips out there to loosen this unnaturally bad dependence upon two vendors: AMD and Intel. Both make shitty processors but AMDs are just less so.
Re: (Score:1, Insightful)
While Intel has its issues as a company, the real issue here is the dominance on x86. Its a closed architecture so only Intel and anyone with an x86 license, only AMD and Via at this point, can actually make x86 compatible chips. ARM is also closed so if I had my choice it wouldn't be as popular either. Ideally something truly open like RISCV is best because then anyone could design a chip and we would have real competition. They have Linux running natively on RISCV now but there still remains much work to
Re: (Score:2)
Jon Masters, one of the people who has been involved in the ongoing Spectre/Meltdown research and mitigation, is from Red Hat and is pushing ARM extensively and doing a great job of advocating for its use beyond low-power mobile devices. He played a huge role in getting Amazon to start offering ARM-based hosts on their cloud platform. If you are looking for interesting presentations about these vulnerabilities, check out some of his talks on YouTube:
Stanford Seminar - Exploiting modern microarchitectures: M
Re: (Score:2)
I would like to see more ARM, RISC-V, and MIPS chips out there to loosen this unnaturally bad dependence upon two vendors: AMD and Intel. Both make shitty processors but AMDs are just less so.
The architectures vulnerable to MELTDOWN are Intel Core, some variants of IBM POWER/PowerPC, and... arm64 [debian.org]. Now tell us again how wonderful ARM is.
If someone can figure out how to get MIPS to scale up to reasonable clock rates, then maybe it has a future outside of embedded. But nobody has managed it yet. It's left down in low-performance limbo with SuperH. ARM made it out of that hole, but it's the only one of that ilk which has.
Re: (Score:2)
Re: (Score:2)
Intel can still make games work their magic at the new 5K plus resolutions.
elite! (Score:1)
if they were elite they would have fixed this BEFORE selling it to millions of people.
Re: (Score:2)
2030, maybe?
Homer Simpson (Score:2)
If they're so smart, home come they're dead^w still flailing around trying to patch this shit?
Why Intel has this issue and AMD does not (Score:4, Interesting)
Go back many years to the putrid Intel Netburst architecture. Single core, very long pipeline, massive caches and the goal of 10GHz. It was the post Pentium 3 design and it was DREADFUL. But Intel paid all major tech outlets, including this one, to sing its praises.
Then AMD invented AMD64 (now called x64) and true mutli-core x64 chips. AMD's tech lead over Intel was massive- even if sites like this one still shilled Intel Netburst.
But AMDand Intel had a cross patent agreement. Intel took the best of AMD's new tech, crossed it with the older Pentium 3 design, and invented Core 2 - which was then used for Intel's much later true dual core parts. And here arose the issue.
For the first time an Intel chip would have TWO threads running on the same chip at the same time, sharing many on-chip and off-chip memory resources. The ONLY way to do this properly is called 'lock and key'. Every thread has a 'key' (unique id) and each access of shared memory must use that 'key' to 'unlock' access to a resourse intended for that thread alone. But 'lock and key' is complex to design. Uses a LOT of transistors. Uses power. And introduces sinificant memory latencies. And makes it harder for the NSA to hack into the chip. So Intel NEVER implemented 'lock and key'. Instead Intel worked with another NSA partner, Microsoft, to use an OS 'solution' that the NSA could easily bypass.
For 10+ years all tech sites conspired to lie and state the OS thread system could provide thread security. It could not. Then the bubble burst, and Spectre and Meltdown finally revealed the atrocious state of ALL Intel CPUs.
Meanwhile AMD had always implemented 'lock and key' in CPU hardware. As a result AMD's current fantastic Ryzen Zen parts cannot hit Intel speeds and have higher memory latencies than Intel- leading to worse gaming performance for gamers wanting >120 Hz refresh. But Intel's clock and memory latency win is only possible cos Intel chips all fail to implement thread security. So intel CHEATS and pays sites like this one to hide this fact.
Zen 2- announced in a few days time, uses superior engineering and TSMC's leading 7nm process to finally close the gap with Intel. A gap already made irrelevant when using decently coded programs that are properly multi-threaded because of AMD's core advantage (at any given price point).
Intel is curently paying tech sites to benchmark using decades old CAD programs that are single threaded and use the long obsolete x87 FPU instructions cos Intel shows a big win here. Intel pays sites like this one to spread the FUD that Intel is fixing their problem (they cannot) and that anyway AMD has the same issue (totally untrue). Intel's real fix happens when they totally redesign their CPU (which will take at least FIVE years) and even then the redesign will massively crater Intel's performance.
Today the ONLY way to safely use an Intel CPU is to only run one thread at a time on the chip, and do a complete state flush on the CPU between multi-tasking thread swaps. A modern coffee-lake six core Intel CPU would see its performance drop by 90%+ if this fix were implemented tho- so you can see why Intel is desperate to pay for lies suggesting the fix is not needed.
Anyone using Intel CPUs today is a complete fool.
Re:Why Intel has this issue and AMD does not (Score:5, Interesting)
Anyone using Intel CPUs today is a complete fool.
This kind of blanket statement show a complete lack of pragmatism. You are clearly an AMD fanboi in the same vein as anti-MS fanbois who would chant "anyone using a Windows operating system today is a complete fool".
The world of computing is not so black and white, and there are myriad reasons why one might choose a particular architecture or OS over another one. Don't presume to know everyone's usage cases better than they know them themselves.
More to the point, however, is the fact that in your entire rant against Intel, you only talk about "lock and key". You don't even mention the topic of speculative execution [wikipedia.org], which is the basis of these vulnerabilities.
Speculative execution is a class of vulnerabilities, not a specific implementation flaw, which is what makes it difficult to mitigate. If you stop using any speculative execution, you will take performance hit. So it becomes a question of risk vs benefit. Again, it's not simply black and white. The team at Intel is trying to figure out how to retain some of the benefits while mitigating the risks. Nobody wants to throw out the baby with the bathwater.
Perhaps in your world it's as simple as "just use only AMD", but I can assure you if everyone actually followed that advice, it would simply require the bad guys to focus all their attention on new targets, and inevitably, new vulnerabilities would be found. There is no perfect technology that can't be exploited, and probably never will be.
Re: (Score:1)
Also, Intel's AVX-512 instruction set gives it some serious number crunching power. Until AMD implements it they will struggle to compete in benchmarks that take advantage of it.
Re: (Score:2)
But Intel chips turn into an oven when using it, and downclock.
Re:Why Intel has this issue and AMD does not (Score:4, Interesting)
While speculative execution could create a new class of vulnerabilities, Intel's problem is /solely/ Intel's problem. You see, Intel released a processor architecture called the pentium (i586) in 1993. It supported the same privilege system as 386/486, but done using super-scalar design, improved cache, and improved addressing. It was a huge leap in performance. It also is not vulnerable to Meltdown/Spectre. Why? It's not because it simply lacked the execution attacks caused by speculative execution. It's that there are no way to blow holes into the privilege system. Why is this known to be true? Because the Atom architecture is a modernized form of the pentium, and is completely immune.
So then come 1995. There was a company called Cyrix. Note this isn't a matter of being and AMD fanboi as Cyrix was a completely separate non-licensee of Intel x86 that was very successful at doing x86 very well, arguably better, before AMD even adopted that strategy. They were already eating into Intel market share massively during around time the pentium was launched. Rumor has it they were faster at executing x86, and also providing higher clock speeds on common socket architecture, keeping things like the 386 and 486 class hardware alive when Intel wanted to get people to upgrade. They were insanely less expensive than Intel. So Intel was getting a little worried about them, even thinking about litigation because how dare they clean room reverse engineer and then optimize the x86 architecture without paying them! So one of Intel's project was to beat them on the performance punch by rapidly releasing another next gen architecture - pentium pro (i686), with speculative execution. But you see, it wasn't enough just to beat them on implementation done the right way. They decided to break the privilege layers when executing to go FASTER. This might have made sense in 1994-95 before the Internet really took off, but it certainly was pretty foolish.
So Cyrix in 95 was readying their pentium clone, which not too bad, then they had to respond to the i686 platform, which took them by surprise, and they had probably a harder time duplicating the super-scalar methods, because most likely they were trying to do it the right way, and Intel's performance was because they took as many short cuts as possible. Evidence that Cyrix and AMD were struggling getting it "right" is with how long Cyrix took on their i686 clone, and how much they were hammered by poor benchmarks. Cloning i686 literally did Cyrix in. AMD's version of i686 is not vulnerable to meltdown, which clearly shows that the designers knew the right method, but of course even AMD performs badly on unprotected execution of a benchmarked Intel.
But the kicker today, is that with the fix, Intel's chips are much slower since speculative execution has to be disabled. It was fundamentally broken. Compare that with AMD where speculative execution does work, now AMD is and was always the performance king.
So Intel lied to everyone and put out a broken product for years. It is totally in their implementation, and you can see the difference from various competitors to this day. So you can try to say that this was just pros or cons in different offerings, but pragmatism really does show when you know what happened is that Intel cheated to kill their competitor, and now they are reaping what they sowed.
Re:Why Intel has this issue and AMD does not (Score:4, Informative)
Rumor has it they were faster at executing x86, and also providing higher clock speeds on common socket architecture,
Rumor is false. As a cheap bastard, I tried the cheapass architectures, which sucked until the k7 came out. Cyrix chips were stunningly cheap, but also staggeringly slow. AMD chips were in the middle in both regards, with Intel by far fastest and most expensive. But then Athlon showed up and knocked Intel's socks directly off for a time, especially in multiprocessor systems where Hypertransport was a drastic improvement.
However, what is often missed in the analysis is that until recently, Intel was the world leader in process technology for years. Even without failing at security design, that gave them a part of their performance advantage. But those days are now gone, so what's Intel got over AMD? Answer, nothing.
Re:Slow Cyrix (Score:1)
Keep in mind that you were probably running MS WIndows, which at that time disabled all caches if it detected a Cyrix chip to deliberately hurt performance.
Re: (Score:2)
Keep in mind that you were probably running MS WIndows, which at that time disabled all caches if it detected a Cyrix chip to deliberately hurt performance.
Keep in mind that my first Linux PC was a 386.
Re: (Score:2)
That's exactly it. I had a 6x86-"200" (which was really a 166MHz part). It was fine in Windows. It was fine for about anything that didn't require any heavy lifting from the FPU. Admittedly back then that wasn't a big deal when I bought the PC. Windows didn't use FPU math much, and even a lot of games still used mostly integer math.
But that soon changed. The Cyrix chip struggled to play a MP3 file - 50% CPU or more. You could play a MP3 file but don't try to do anything else if you valued smooth play
Re: (Score:2)
The 450 MHz K6 AMD chip that replaced the Cyrix was a revelation - you could play your music in the background with no noticeable impact on system performance, about 3-4% CPU usage.
Was that a K6/3? Those were the bee's knees, what with their onboard L2 cache — since most machines of the day had motherboard-mounted L2, they would actually use that redundant cache as L3. Even at its best the K6 was still pretty bad at pretending to be a Pentium, but if you were in a position to compile for it natively, the performance was easily up into the low end of Pentium 2 levels. I used to run Gentoo on a laptop with a K6/2 400 and it was really quite impressive for what it was (dirt cheap.)
Re: (Score:2)
Anyone using Intel CPUs today is a complete fool.
This kind of blanket statement show a complete lack of pragmatism. You are clearly an AMD fanboi in the same vein as anti-MS fanbois who would chant "anyone using a Windows operating system today is a complete fool".
The world of computing is not so black and white,
It's only slightly more complicated. Anyone who has a choice who chooses Windows is a fool, and anyone who has a choice who chooses Intel is a fool. If Intel has done this, what else have they done? They have proven that they are untrustworthy. If you trust them, you are a fool.
Re: (Score:2)
Re: (Score:2)
But Intel paid all major tech outlets, including this one, to sing its praises.
Err look. Just because you don't like something doesn't mean everyone is shilling. The reality is Netburst was horrible, but it was also the best thing on the market.
AMD's tech lead over Intel was massive- even if sites like this one still shilled Intel Netburst.
AMD's tech lead was irrelevant at a time when a chip supported 64bits without any OS, apps, and for the large part of the world without any use case. AMD can have all the tech in the world. It didn't matter, Netburst was faster. It took a long time for AMD to actually provide a decent contended from when they first created their "tech lead".
For 10+ years all tech sites conspired to lie and state the OS thread system could provide thread security.
I t
Need security? Don't use JIT! (Score:5, Informative)
Meltdown is an Intel problem. Spectre is only a problem if you use Just-In-Time compilation on your system. The obviously solution is to simply not use JIT in the first place. Nothing fundamentally needs it, it simply makes the execution of unverified code faster. Nobody writing applications needs to worry about Spectre... unless you are writing a JIT compiler. This is a very small number of applications and they can still run unverified code using an interpreter engine, it's just a bit slower.
The solution is simple: dump JIT.
Re: (Score:1)
It is a bit like cutting off fingers to be protected from frostbites, but it is somewhat true. JITed JS is realistically the only "remote execution" that can affect your PC. Look at: https://abiondo.me/2019/01/02/exploiting-math-expm1-v8/ .It is not Spectre related but shows how complicated JS engines are already.
Re: (Score:2)
It is a bit like cutting off fingers to be protected from frostbites, but it is somewhat true. JITed JS is realistically the only "remote execution" that can affect your PC.
What? Who told you that? There are holes in daemons which permit remote execution all the time. Most of the time these are not root-level (or in the case of NT, system-level) exploits and the damage that can be done is thus limited. That's why these processor exploits that permit looking into other processes are a security concern. Most attacks on systems require combinations of vulnerabilities.
Re: (Score:2)
Huh, Spectre was an issue with speculation and branch prediction, not with JIT.
Yes but the issue is that JIT code could be executed to read memory of the process from within the JIT environment. Basically, JIT compiled javascript could read your browser passwords because it's part of the same process. The reason it can do this is because the JIT compiler is translating the javascript into native instructions which if ordered correctly can exploit the spectre flaw. Were it to use a javascript interpreter engine then it would be completely unable to invoke the spectre flaw at all.
Re: (Score:1)
The solution is simple: dump JIT.
HA! I'm sure you're being sarcastic, right?
JAVA is primarily JIT and .NETs core CLR is pretty much in the same boat, although one can use Ahead Of Time if they so choose to do. But simple? not really. There really is no slowing down or moving away from this iceberg.
Re: (Score:2)
The solution is simple: dump JIT.
HA! I'm sure you're being sarcastic, right?
Half-serious because I know it's an entrenched technology.
JAVA is primarily JIT and .NETs core CLR is pretty much in the same boat, although one can use Ahead Of Time if they so choose to do. But simple? not really.
If you are use .NET then you aren't serious about security to start with. If you use Java then you have chosen poorly.
There really is no slowing down or moving away from this iceberg.
I'm not trying to stop anything, I'm saying some people are serious about security and others are only pretending.
Re: (Score:2)
Mixing security domains in a single process, like a JIT in the kernel or browser, is a big problem with most spectre variants. Program wide CPU and compiler mitigations for these problems suck.
But there are other spectre variants that can be triggered between processes on the same core.
Heck there are variants that can be triggered remotely, just by sending well crafted data to some vulnerable parsing routine.
In response to spectre, the truly paranoid would be well served by keeping their secrets as far a
The root cause of Meltdown and Spectre (Score:2)
STORM? More like "we sat on our thumbs" (Score:1)
What a complete crock of shit the entire article is.
Intel and its "STORM" essentially sat on their thumbs for half a year, coming up with basically zero real-world implementable solutions.
When Google and Linux kernel devs found out about it, they developed retpolines and other workarounds. Google devs came up with retpolines, which is the Spectre mitigation strategy in use in all OSes now -- Google, and not Intel's STORM.
The STORM guys apparently were too busy storming their thumbs in their butt. They just