To Fight Spectre-Like Attacks, Intel Suggests a New Kind of Memory (zdnet.com) 77
Intel researchers published a paper last week suggesting a new kind of CPU memory to block side-channel attacks like Meltdown and Spectre, according to ZDNet:
SAPM -- or Speculative-Access Protected Memory -- is the work of Intel STORM (STrategic Offensive Research & Mitigations), a team of elite security researchers that Intel assembled since 2017 to work on creating mitigations for all the speculative-execution attacks that have impacted the CPU maker's products. SAPM is only an idea for the moment, and there are no silicon prototypes. Intel STORM engineers only released "the theory and possible implementation options," to provide "a ground base for other researchers to improve upon and also for the industry to consider...."
Intel STORM researchers say SAPM will implement protections at the hardware level and will work with both physical and virtual memory addresses. "SAPM can be applied to specific memory ranges, with the attribute that any memory access to such memory type will be instruction-level serialized, meaning that any speculative execution beyond the SAPM-accessing instruction will be stopped pending the successful retirement of this SAPM-accessing instruction," Intel STORM developers said in their short description of SAPM's basic principles...
Intel STORM researchers say the second part (backend) of most speculative execution attacks performs the same actions. SAPM was designed to introduce hardware-based protections against the backend part of most attacks. It's because of this concept that Intel's research team believes that SAPM will also future-proof the next generations of Intel CPUs against other -- currently undiscovered -- speculative execution attacks.
"Intel STORM researchers don't deny that there's a performance hit," the article adds. "However, this impact is low and could be mitigated further by dropping other existing protections."
Intel STORM researchers say SAPM will implement protections at the hardware level and will work with both physical and virtual memory addresses. "SAPM can be applied to specific memory ranges, with the attribute that any memory access to such memory type will be instruction-level serialized, meaning that any speculative execution beyond the SAPM-accessing instruction will be stopped pending the successful retirement of this SAPM-accessing instruction," Intel STORM developers said in their short description of SAPM's basic principles...
Intel STORM researchers say the second part (backend) of most speculative execution attacks performs the same actions. SAPM was designed to introduce hardware-based protections against the backend part of most attacks. It's because of this concept that Intel's research team believes that SAPM will also future-proof the next generations of Intel CPUs against other -- currently undiscovered -- speculative execution attacks.
"Intel STORM researchers don't deny that there's a performance hit," the article adds. "However, this impact is low and could be mitigated further by dropping other existing protections."
*Crosses fingers* (Score:2)
I sure hope it's the return of Rambus!
Just call it SPAM (Score:4, Funny)
and be done with it.
Or SPA (Score:2)
Speculative Memory-Access Protection
But actually it's going to be called SPA not SPAM or SPAM in the long run. that is you will refer to this as SPA memory. Otherwsie yo'd be saying something as redundant as ATM Machine.
Yeah, an that never happens...! (Score:2)
I know what we will call it: "That stillbirth thatdied on the drawing board of PR emergency surgery." Or: "Huh? What? Never heard of it."
Re: (Score:1)
how about (Score:5, Interesting)
How about fixing the CPU, I know it is hard work and we all know it will cost real dollars. But large companies would rather do anything rather than spend to fix an issue they caused. God forbid they have to lower the dividen by 10 cents to fix the problem once and for all.
While you are at in why don't you allow people to completely disable ME (Intel Management Engine) and we can have a protected system.
Re: (Score:2)
This is about fixing the CPU, can only be fixed in future processors.
You do know the ones they made for the last 20+ years can't be fixed, impossible. Intel chose at that time to ignore the exposed flaws then and everyone forgot.
Re: (Score:2)
That's right, and it wasn't just Intel. It was the whole goddam box. The best computers in the world are leaky. We need a new machine that incorporates what we've learned so far.
Re: (Score:2)
This is about fixing the CPU, can only be fixed in future processors.
Yes, but current processors can't support this memory that doesn't even exist, even if it did exist, so this won't help with the processors which can't be fixed. The memory controller is the right place to put this functionality, NOT the memory.
Re: (Score:1)
This is about fixing the CPU, can only be fixed in future processors.
You do know the ones they made for the last 20+ years can't be fixed, impossible. Intel chose at that time to ignore the exposed flaws then and everyone forgot.
Well... as long as intel does not develop a new way to preform "Speculative Execution", I will stick to buying AMD processors from now on...
Re: (Score:2)
He means fix the CPU design! (Score:2)
Not the already sold CPUs. Duh!
How is that not obvious to you? Wishful interpreting?
Re: (Score:2)
Re: (Score:2)
Fix the CPU? How do you do that? The attacks rely indirectly on CPU optimizations that keep some memory in the internal cache (indirectly because it tells if a bit is 0 or 1 based on the time it takes the CPU to retrieve some data).
The CPU can be fixed by restoring state after false speculative execution. The existing problem depends on state information leaking through the various caches which is why Meltdown does not affect AMD; they do not speculatively execute loads which violate access permissions while Intel does.
Re:how about (Score:4, Interesting)
How about fixing the CPU, I know it is hard work and we all know it will cost real dollars. But large companies would rather do anything rather than spend to fix an issue they caused. God forbid they have to lower the dividen by 10 cents to fix the problem once and for all.
While you are at in why don't you allow people to completely disable ME (Intel Management Engine) and we can have a protected system.
Uh, just to clarify, this isn't about actually fixing a damn thing other than public perception.
Why do you think they're ignoring the Intel Management Engine?
They're doing the minimal amount of bullshit work on vaporware in order to appease shareholders. That's it.
Re: (Score:2)
They are working on fixing these SE problems in future CPU, they've fixed some already.
They did fix one vulnerability Management Engine had until 2017, in later processors.
There is firmware fix for the INTEL-SA-00125 management engine vulnerability found in 2018.
You mean the one that let us disable it? (Score:2)
No surprise there.
Re: (Score:2)
No, those are firmware fixes that let it run.
Of course, someone with physical access to machine could roll version back. But then they could do all manner of other things regardless of whether ME existed.
Re: (Score:2)
Uh, just to clarify, this isn't about actually fixing a damn thing other than public perception.
Intel is trying to imply that the fault is actually with memory and affects all CPUs rather than a defect in their own design.
Re: (Score:2)
How about fixing the CPU
Because there is no fix, and speculative execution isn't even limited to CPUs. There is one single Speculative Execution but that has been plaguing only Intel CPUs, the other 10-15 that have been discovered since this form of attack became popular (in laboratories anyway), have affected all CPUs, and even some network cards, and the proposed fixes are crippling.
Re: (Score:2)
This is incorrect. Look at the predictor training differences between Intel and AMD.
Re: (Score:3, Interesting)
How about fixing the CPU, I know it is hard work and we all know it will cost real dollars. But large companies would rather do anything rather than spend to fix an issue they caused. God forbid they have to lower the dividen by 10 cents to fix the problem once and for all.
The general problem is extremely hard, in a process with shared resources how do you stop a process from inferring something based on consuming those resources. Like if I know when you leave for work and arrive at work, I can infer the route you take by causing a traffic jam and see if that causes you to be late. Now Intel really goofed by installing a blinker that told you whether you had a car in the lane next to you even though you weren't allowed to use that lane making it much, much easier but fixing t
Re: (Score:2)
A better idea is to simplify the processors and have more of them, and REALLY limit their intercommunication. This means totally abolishing hyperthreading, and replacing it by have a lot more real processes (at one process/CPU). Also, the only memory that a CPU can modify is it's own. Messages are passed, but changing the message doesn't change the original. Etc.
There are types of problem for which this would not be optimal, but those should be addressed with attached processors, similar to the way GPUs
Re: (Score:2)
A better idea is to simplify the processors and have more of them, and REALLY limit their intercommunication. This means totally abolishing hyperthreading, and replacing it by have a lot more real processes (at one process/CPU). Also, the only memory that a CPU can modify is it's own. Messages are passed, but changing the message doesn't change the original. Etc.
The problem of sharing resources allowing memory leaks through cache state applies whether those resources are shared between CPUs or hardware threads. A single core CPU with no hyper-threading still suffers from Specter attacks if it performs speculative execution and only specialized applications are going to give up the performance of speculative execution or caches.
Re: (Score:2)
You don't do speculative execution with a shared cache in this system. Each CPU is separate. You *might* do speculative execution anyway, but it would be at a much higher level...and each "thread" would be a totally independent process.
Re: (Score:2)
It would, indeed, be a huge hit to performance until you redesigned the software to optimize for this system rather than for the current system. Once you do most problems shouldn't have any hit to their performance, though some certainly will, which is why I also proposed an attached processor to handle those cases.
They're developing these fancy new additions because along the evolutionary path their taking simple solutions are bad...but note that they're also near the end of development along this path an
Re: (Score:2)
The general problem is extremely hard, in a process with shared resources how do you stop a process from inferring something based on consuming those resources.
Restore the state of those resources when speculation fails. Or maybe do not change the state by using dedicated resources only for speculation.
Re: (Score:2)
To be sure, this is the fix.
The crux of the issue is that the combination of speculative execution and caching appears to be inherently vulnerable to Spectre-like attacks. With enough effort, it will always be possible to use cache and instruction timings to infer the contents of a piece of memory. At no point is an otherwise hardened CPU doing anything wrong - it's never directly disclosing the data - but a smart attacker can use the state of things to correctly figure out what's go
Re: (Score:2)
Fencing instructions sound like a hassle as you stated from a development perspective. I could easily see lazy developers or greedy corporations cutting corners and not using it when they should.
That said, I could also see government entities wanting to build a whole new type of speculative execution fencing instruction backdoor...YAY!
Re: (Score:2)
Re: (Score:2)
Yah, I'm disappointed it didn't mention "synergy" and "leveraging our lead in technology" and "being forward looking into the future".
Encrypted memory? (Score:2)
Re: (Score:2)
This isn't encrypted memory. It's marking certain memory addresses as sensitive, so that the processor doesn't speculatively execute against them.
Encrypted memory would just mean you have to steal the key first, which is very doable with Spectre. And in fact the slow rate for Spectre means that stealing keys is one of the best uses for it.
Otherwise, encrypted memory is fantastic; but it doesn't solve this specific problem.
The only response to AMD breakthrough ? (Score:1)
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:1)
What AMD breakthrough? Being immune to Meltdown but vulnerable to every other speculative execution vulnerability just like all the other CPU vendors out there?
Re: (Score:2)
AMD's products have not been vulnerable to the following ones that Intel products have been vulnerable to:
It amazes me how many people still don't get how much wors
Nah, the majority of idiots usually believes ... (Score:3)
in anticonspiracy theories.
Like "The NSA leaks never happened. There is no PRISM or XKeyScore. They are the good guys." or "We live in a democracy. The politicians represent us. They are not evil. Just stupid.".
Everything to keep sleeping until it is too late, and then some.
Conspiracy theories take a non-conformist nutjob.
Most people are conformist nutnobs. The accepted kind of nutnob.
Re: (Score:2)
Why, there's so much low hanging fruit dangling off that bozo to go after first.
Dropping Existing Protections (Score:1)
"this impact is low and could be mitigated further by dropping other existing protections"
That's kinda exactly what I don't want. Give me security and performance. Maybe start teaching these fucktards how to actually secure the first three layers of the OSI model so the other fuckton of useless layers are unnecessary.
Why are you talking? You're dumb, after all (Score:2)
So you are saying it takes a car mechanic to recognize that the car door lock is missing? (Maybe for you it does.)
Or that if I can tell such a blatantly obvious fact, then I should also be able to fix it, to get your majesty's nod on being allowed to mention that?
I think you're just very good at walking on your hands and pretending that is your mouth talking.
Re: (Score:3)
Car mechanics say stupid, ignorant things about the engineers who design the cars every day of the week. And they're full of shit and didn't know what they were talking about 100% of the time, too.
Re: (Score:2)
Car mechanics say stupid, ignorant things about the engineers who design the cars every day of the week. And they're full of shit and didn't know what they were talking about 100% of the time, too.
Yea, the engineers who placed the spark plugs such that they could not be changed without removing the engine on certain GMC Cadillacs knew what they were doing. Also the engineers who ground the already hardened camshafts on the Ford Pintos to change the timing knew.
Re: (Score:2)
They decide while designing the car if they want it to be easy for people to fix at home, or easy to fix in a small shop, or if is designed to be easy to fix in a large auto shop with lots of tools. Or in fact if it will be difficult to fix, because they wanted to put a larger engine in, or make the engine compartment a certain shape.
My vehicle was mostly designed in Japan, and to the standard that it should be easy to fix in a small shop with limited technology, but that has a lift. So it is expected to ha
Re: (Score:1)
Yea, like those engineers who though putting the spark plug location around the hottest area of the engine bay, in a BLIND SPOT, was a really good decision (90-degree rotated 4-cylinder engines, anyone?)
Comment removed (Score:4, Interesting)
Re: (Score:2)
I'm not sure why you think this is an Intel vs AMD issue given that AMD is vulnerable to all the same speculative execution attacks save for a single example (Meltdown).
Re: (Score:3)
It is not. Or rather exploiting these vulnerabilities on AMD is so hard it is likely infeasible in practice. It is already very hard on Intel, but not infeasible there. You should read up on things, you seem to be missing a rather important piece of the picture.
Re: (Score:2)
Nope, Intel has these known vulnerabilities that AMD doesn't have:
Spectre-NG: Rogue System Register Read
Foreshadow: L1 Terminal Fault
Spectre-NG: Lazy FP State Restore
Foreshadow-OS: L1 Terminal Fault
Foreshadow-VM: L1 Terminal Fault
Zombieload: Microarchitectural Fill Buffer Data Sampling
RIDL: Microarchitectural Data Sampling / Uncacheable Memory
Fallout: Microarchitectural Store Buffer Data Sampling
Spectre SWAPGS
Moreover, I've heard that there are new ones that we'll hear about within the coming mo
Re: (Score:2)
Intel spent 30 years beating AMD by hook or by crook in the market, and it did this largely by selecting an overwhelmingly risky and underhanded technology called Hyperthreading that let intel claim it always had more cores than AMD.
I am highly confused by this statement. Everyone I talk to was always very aware that 2 hyperthreads is quite different from two cores. Hyperthreading is just Intel's flavor of Simultaneous Multi Threading.
Also, AMD is also using SMT. It is a corner stone of modern processor design. Keeping more execution contexts than available ALUs is a very common strategy that you find SPARC, in POWER, and in x86 chips. Actually that even how GPUs are working, you keep more context on-die than you have execution resourc
Re: (Score:2)
Intel spent 30 years beating AMD by hook or by crook in the market, and it did this largely by selecting an overwhelmingly risky and underhanded technology called Hyperthreading that let intel claim it always had more cores than AMD.
This is almost completely wrong. this is the only part that's correct:
This part is true. But the overwhelmingly risky and underhanded technology was skipping checks to see whether they were supposed to access memory until after they accessed it. That's the reason why Intel is vulnerable to MELTDOWN and AMD isn't, and why Intel is more vulnerable to SPECTRE than AMD.
Intel never advertised HT as increasing core count, only con
Re: (Score:2)
Intel CPUs are vulnerable whether Hyper-threading is supported or used.
SPAM Memory (Score:3)
Câ(TM)mon. It obviously should be Speculative Protected Access Memory (SPAM) not Speculative-access protected memory.
Re: SPAM Memory (Score:2)
God damnt what happened to my câ(TM)mon ?
Re: (Score:2)
God damnt what happened to my câ(TM)mon ?
You posted from your iPhone with defaults, because you are a god damn inconsiderate prick that doesnt care that Apples keyboard by default doesnt emit the real quote character, but instead emits fancy cartoon glyphs designed for infantiles that dont care that their shit aint standard and is broken, only that it looks good.
Re: (Score:2)
There's nothing nonstandard about the character U+2018. It's certainly not ascii, but that's not the same thing as saying it's not standard.
If slashdot insists on blocking non-ascii utf8, I think that the submit button should invoke a quick scan on the subject and body of the post to ensure there are no non-ascii characters, and if there is, it should instead go to a preview message page and inform the user that non-ascii is detected, requiring the user to click submit again on the unmodified text to tr
Or ... just fix your damn CPUs. (Score:2)
Like AMD did. Without any special memory.
Re: (Score:2)
AMD is vulnerable to Spectre just not the Meltdown variant.
Re: (Score:2)
The same AMD that is vulnerable to 14 out of the 15 speculative execution vulnerabilities that have been published to date?
Re: (Score:3)
No. The AMD where it is hard enough to attack these vulnerabilities to make them infeasible in practice. Unlike on Intel.
Re: (Score:2)
Or they could, you know ... (Score:2)
... build stuff without the need to use a goddam chisel to fine-tune it.
"However, this impact is low and could be mitigated further by dropping other existing protections."
A new kind of memory! (Score:2)
Which kind?
I forgot.
And there AMD can do it without (Score:2)
Intel seems to get really desperate to draw attention away from their massive screw-up.
Re: (Score:2)
Intel seems to get really desperate to draw attention away from their massive screw-up.
Public relations is much cheaper than engineering.
Re: (Score:2)
Indeed.
About those performance hits... (Score:2)
Not all computer uses are vulnerable to such attacks? For instance, who is going to care if they are playing a single player game off-line when it would be nice to have the CPU working to full capacity. Perhaps a hardware switch....
Snake-oil ... (Score:2)
You can also slather yourself with snake-oil to mitigate Spectre. Or you can buy Intel's new pre-slathered RAM chips. The choice is yours. Just so long as you buy some snake-oil.
Classic Clueless Hardware Design (Score:2)
The whole premise of this technique assumes that one can somehow identify some tiny subset of memory that needs to be protected and then effectively turn off all caching on it. You can already do that with the MMU in a lot of hardware. The problem is that an OS typically has no idea what memory should be specially protected (and figuring that out is non-trivial -- as in auditing the entire OS).