Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Intel Hardware

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."
This discussion has been archived. No new comments can be posted.

To Fight Spectre-Like Attacks, Intel Suggests a New Kind of Memory

Comments Filter:
  • I sure hope it's the return of Rambus!

  • by RotateLeftByte ( 797477 ) on Sunday October 06, 2019 @10:45AM (#59275338)

    and be done with it.

    • 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.

  • how about (Score:5, Interesting)

    by jmccue ( 834797 ) on Sunday October 06, 2019 @10:51AM (#59275362) Homepage

    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.

    • 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.

      • 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.

      • 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.

      • 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...

    • 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).
      • Not the already sold CPUs. Duh!

        How is that not obvious to you? Wishful interpreting?

        • What is not obvious is how to keep optimizing the CPU through a different method ; a "new" CPU would require a new optimization strategy which is definitely not obvious to implement. Duh :-)
      • by Agripa ( 139780 )

        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)

      by geekmux ( 1040042 ) on Sunday October 06, 2019 @11:40AM (#59275508)

      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.

      • 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.

      • by Agripa ( 139780 )

        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.

    • 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:3, Interesting)

      by Kjella ( 173770 )

      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

      • by HiThere ( 15173 )

        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

        • by Agripa ( 139780 )

          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.

          • by HiThere ( 15173 )

            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.

      • by Agripa ( 139780 )

        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.

    • How about fixing the CPU

      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

      • 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!

  • Hem, AMD does that already.
    • 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.

  • Let's design a RAM that only Intel CPUs will be able to use
    • Comment removed based on user account deletion
    • What AMD breakthrough? Being immune to Meltdown but vulnerable to every other speculative execution vulnerability just like all the other CPU vendors out there?

      • by fintux ( 798480 )

        AMD's products have not been vulnerable to the following ones that Intel products have been vulnerable to:

        • 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

        It amazes me how many people still don't get how much wors

  • "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.

  • Comment removed (Score:4, Interesting)

    by account_deleted ( 4530225 ) on Sunday October 06, 2019 @11:34AM (#59275490)
    Comment removed based on user account deletion
    • 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).

      • by gweihir ( 88907 )

        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.

      • by fintux ( 798480 )

        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

    • by godrik ( 1287354 )

      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

    • 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:

      it did this largely by selecting an overwhelmingly risky and underhanded technology

      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

    • by Agripa ( 139780 )

      Intel CPUs are vulnerable whether Hyper-threading is supported or used.

  • by logicnazi ( 169418 ) <gerdes@NosPAM.invariant.org> on Sunday October 06, 2019 @12:01PM (#59275574) Homepage

    Câ(TM)mon. It obviously should be Speculative Protected Access Memory (SPAM) not Speculative-access protected memory.

    • God damnt what happened to my câ(TM)mon ?

      • 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.

        • by mark-t ( 151149 )

          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

  • Like AMD did. Without any special memory.

    • by Megol ( 3135005 )

      AMD is vulnerable to Spectre just not the Meltdown variant.

    • The same AMD that is vulnerable to 14 out of the 15 speculative execution vulnerabilities that have been published to date?

      • by gweihir ( 88907 )

        No. The AMD where it is hard enough to attack these vulnerabilities to make them infeasible in practice. Unlike on Intel.

      • by fintux ( 798480 )
        You mean 2 out of 16, plus 4 that may be be possible but nobody has been able to demonstrate on AMD, right? (https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerabilities)
  • ... 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."

  • Which kind?
    I forgot.

  • Intel seems to get really desperate to draw attention away from their massive screw-up.

  • 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....

  • 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.

  • 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).

"You know, we've won awards for this crap." -- David Letterman

Working...