Slashdot Mirror
The Elite Intel Team Still Fighting Meltdown and Spectre (wired.com)
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."
To clean their massive shitty bed.
Do they hire Fortran developers? Because this is how old this type of flaws is.
Intel has been outsourcing since the 70s.
"First they came for the slanderers and i said nothing."
PR. Put some foreign sounding names in positions that sound like they are important. It makes the diversity cheerleaders happy.
So much hard work with no results
There are no nazi faggots in the clean room nor the board room. Sorry, you're unemployable deplorable faggots of no value, aww. Maybe you can work at Amazon, until they find out what a useless cunt you are. Good luck.
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?")
if they were elite they would have fixed this BEFORE selling it to millions of people.
I would much rather most of the effort be spent tracking down:
1. The authors these "exploits".
2. Those deploying these "exploits".
Once found. Simply kill them.
So you have to admit that there is no such thing as user security anymore.
When should we expect new breed of secure processors?
If they're so smart, home come they're dead^w still flailing around trying to patch this shit?
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.
Nope, it's real. Intel focuses on hiring diversity, to an extreme. It is reportedly quite a heavy policy there, and HR is the policeman.
This article only exists, because Intel told Wired that they need to look good and like they are caring and responsible.
Not for the purpose of actually being good.
Wanna bet?
This is the difference between a healthy mind and a psychopath, by the way.
A psychopath is not interested in preventing harm to others. He's only interested in not being caught doing harm to others, to prevent harm to himself.
A great example of that could be seen, whenever Exxon's CEO talked about the massive oil spillage his company had caused. It all amounted to something along the lines of: "I am very sorry... that we were caught.”.
Everyone is on that bandwagon, now. I'm on the far-end of my building, and over 70% of the cubes I pass on the way to the restroom have 10+ syllable nameplates. If I have to accomplish something that requires anyone from Ops, I simply have to accept that I'm not getting a call-back until 10PM at the earliest, because that's when the sun's up over there.
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.
Anons need not reply. Questions end with a question mark.
Dinesh? No wonder Intel sucks now
Huh, Spectre was an issue with speculation and branch prediction, not with JIT. Non-JIT code still uses both of those processor features.
Sometimes the attacks = delivered via script & have been demonstrated to be so (you may have a point though that it's NOT the JIT interpreter engine @ fault in & of itself).
APK
P.S.=> That's my take on it @ least... apk
See subject: AMD's subject to it but less forms of it. Correct me if I'm off. I protect myself https://yro.slashdot.org/comme... vs. this via hosts files BLOCKING sources of this type of attack in malscript/malwares + I disabled HyperThreading (per reading Linus Torvalds saying it was a WISE IDEA in the meantime/interim period as I noted in that post).
* For now, works for me & many others out there...
APK
P.S.=> Good INFORMATIVE post on your part (especially the "lock & key" points you noted) - IF I had modpoints? I'd hit you w/ some but I don't as an AC poster... apk
After they've hunkered down and shit out a puddle of last night's curry.
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.
In the meantime hosts block sources of attack used in Intel Meltdown/Spectre etc. attacks as they do other malwares/botnets/phishmail/coinminers/malscript etc. malicious links!
* Accept NO substitute (& IF you're smart? You disable HyperThreading in Intel CPUs, in the meantime @ least, until new CPUs are issued that are PROOFED vs this exploit!).
P.S.=> For the best hosts file:
APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between chars & download)
APK Hosts File Engine 10++ SR-1 32/64-bit for Windows https://hosts-file.net/?s=Down... (DL link @ bottom)
Soon for MacOS (I just got a NEW Mac-Mini to port it there too)... apk
I block malscript sources via hosts files (which do so faster vs. NoScript parsing HTML scriptsrc tags & before a browser OR a script engine even BEGINS to operate in slower usermode by blocking access to said malscript sources albeit in FASTER kernelmode).
APK
P.S.=> Via https://yro.slashdot.org/comme...
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.
Anons need not reply. Questions end with a question mark.
In a rush to get it to market they never tested the processor for such side-channel attacks.
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 sat on the data and talked with Microsoft, and some other proprietary software houses, and looking at their results, didn't actually achieve much in way of mitigation.
For Meltdown, Linux kernel devs use kernel page table mitigation. Again, no help from Intel STORM "elite team".
Such puffery and blatant appropriation of mitigation techniques; typical for a company that tries to throw money at publications for them to hide how utterly inept they were at mitigating a problem they caused.
Editors should be ashamed. I guess the money was just too good to pass.
Obviously diversity is working out great for Intel with their superb products they produce. Wonder what the old CEO is doing now.
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.
See subject: "... You live long enough to see yourself become the villain" (which I'm sure a FEW here would love, lol)
* Per Christian Bale (one of my all-time fav. actors no less, the modern day equivalent of Lon Chaney Sr.) as The Batman/Bruce Wayne.
APK
P.S.=> "I'm whatever Gotham needs me to be..." - "But he didn't do anything wrong..." apk
Or if you use virtualization like pretty much every single data center (aka cloud computing).
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.
too feeble to learn a name?
See subject: Nothing YOU say or think, matters. It's from NOBODY. UNIDENTIFIABLE do-NOTHING "ne'er-do-well" NOBODY you.
* :)
(You're just SUCH a 'winner')
APK
P.S.=> You WISH you were me... apk
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 away from other programs and users as possible.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
When they can pronounce mine, I'll maybe feel bad about not remembering theirs.
I remember the Cyrix chips quite well, as I was in the business and building lots of machines regularly. It wasn't the 686 or anything that killed them - it was the atrociously slow floating point math functions, right as the gaming market started to see the first true 3D cards show up. For non-math heavy tasks they were still awesome, but when you lose the gamer market, you lose a lot. The early 3D cards were nothing like what we have today and relied heavily on the CPU.
I can't speak to the Windows claim, I never used them together.
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.
Anons need not reply. Questions end with a question mark.
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 playback. The "equivalent" 200 MHz Pentium didn't struggle nearly as hard. 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.
In may ways the Cyrix 6x86 really was more closely related to the 486 than Intel's 6th generation chips.
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.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"