Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
AMD Intel Security Hardware

Spectre Flaws Still Haunt Intel, AMD as Researchers Found Fresh Attack Method (theregister.com) 33

Posted by EditorDavid from the in-the-chips dept.
"Six years after the Spectre transient execution processor design flaws were disclosed, efforts to patch the problem continue to fall short," writes the Register: Johannes Wikner and Kaveh Razavi of Swiss University ETH Zurich on Friday published details about a cross-process Spectre attack that derandomizes Address Space Layout Randomization and leaks the hash of the root password from the Set User ID (suid) process on recent Intel processors. The researchers claim they successfully conducted such an attack.... [Read their upcomong paper here.] The indirect branch predictor barrier (IBPB) was intended as a defense against Spectre v2 (CVE-2017-5715) attacks on x86 Intel and AMD chips. IBPB is designed to prevent forwarding of previously learned indirect branch target predictions for speculative execution. Evidently, the barrier wasn't implemented properly.

"We found a microcode bug in the recent Intel microarchitectures — like Golden Cove and Raptor Cove, found in the 12th, 13th and 14th generations of Intel Core processors, and the 5th and 6th generations of Xeon processors — which retains branch predictions such that they may still be used after IBPB should have invalidated them," explained Wikner. "Such post-barrier speculation allows an attacker to bypass security boundaries imposed by process contexts and virtual machines." Wikner and Razavi also managed to leak arbitrary kernel memory from an unprivileged process on AMD silicon built with its Zen 2 architecture.

Videos of the Intel and AMD attacks have been posted, with all the cinematic dynamism one might expect from command line interaction.

Intel chips — including Intel Core 12th, 13th, and 14th generation and Xeon 5th and 6th — may be vulnerable. On AMD Zen 1(+) and Zen 2 hardware, the issue potentially affects Linux users. The relevant details were disclosed in June 2024, but Intel and AMD found the problem independently. Intel fixed the issue in a microcode patch (INTEL-SA-00982) released in March, 2024. Nonetheless, some Intel hardware may not have received that microcode update. In their technical summary, Wikner and Razavi observe: "This microcode update was, however, not available in Ubuntu repositories at the time of writing this paper." It appears Ubuntu has subsequently dealt with the issue.

AMD issued its own advisory in November 2022, in security bulletin AMD-SB-1040. The firm notes that hypervisor and/or operating system vendors have work to do on their own mitigations. "Because AMD's issue was previously known and tracked under AMD-SB-1040, AMD considers the issue a software bug," the researchers explain. "We are currently working with the Linux kernel maintainers to merge our proposed software patch."
BleepingComputer adds that the ETH Zurich team "is working with Linux kernel maintainers to develop a patch for AMD processors, which will be available here when ready."
This discussion has been archived. No new comments can be posted.

Spectre Flaws Still Haunt Intel, AMD as Researchers Found Fresh Attack Method More

Spectre Flaws Still Haunt Intel, AMD as Researchers Found Fresh Attack Method

Comments Filter:
  • Aside from the extra nonsense introduced by some of the fixes being in microcode(which drags motherboard vendors and PC OEMs into it; which is rarely helpful) is it even accurate to speak of "spectre" as a specific flaw with a specific solution? My (admittedly layman's) understanding was that 'spectre' was the name that stuck thanks to it being assigned to an early and dramatic demo; but that it refers to an entire family of more and less subtle quirks and potential side channels that affects basically any

    • Re:Is there even a "solution" as such? (Score:4, Informative)

      by gweihir ( 88907 ) on Saturday October 19, 2024 @11:57AM (#64877565)

      There is. In some cases speculative execution must not be used. This is unfortunate, as kernel-entry almost universally qualifies and hence this will always come at a performance penalty. These days, I think the world will eventually move to microkernels and then containing such a problem becomes a lot easier.

      • These days, I think the world will eventually move to microkernels and then containing such a problem becomes a lot easier.

        How do you figure?
        In microkernels, the "kernel" memory boundary is universal- per process- even kernel process.
        Do you perhaps mean hybrids like Darwin? (microkernels that have had all of the micro ripped out of them)
        In a microkernel that focuses on some kind of MPI vs syscalls, the MPI interface still requires a syscall.

        • Re: (Score:2)

          by gweihir ( 88907 )

          I mean microkernels designed with this vulnerability in mind, obviously. What else could I reasonably mean?

          • You didn't answer my question.

            How do you figure?
            Microkernels make the problem space larger, not smaller.
            There's no inherent difference between a micro and monolithic kernel with regard to speculative execution, except instead of 2 domains, you have many.
            The problem doesn't become easier, it becomes harder and more expensive.
      • Microkernels just wind up pushing the responsibility for security to user space. (Or what ever CPU privilege level the apps are running in.) In addition to making additional library requirements to make up for the lack of guaranteed support from the kernel. (Which also means that code is less battle tested due to lack of consistent deployment.)

        At best it's just giving up on the hardware security builtin to the CPU (Privilege Levels A.K.A. "Rings" in x86 speak.) in favor of software development policies ma
      • Has anyone ever been hacking using a Spectre or rowhammer vuln? I haven't heard of it.

        • Re: (Score:2)

          by gweihir ( 88907 )

          The paper claims to have done so for the Spectre-type vulnerability. Would not surprise me if they created a non-realistic situation though.

          As to Rowhammer, I have noticed early on that these papers always test on laptops and many laptops reduce RAM refresh rate to conserve energy, sometimes dramatically. I have run the Rowhammer test on a number of regular computers overnight (all with non-ECC memory) with exactly zero results. I think Rowhammer is mostly a hallucination except on some really badly configu

    • Side channels are incredibly hard to close, partly because they can be very very slow. Even leaking one bit per hour will put a massive massive dent into any cryptographic algorithms in short order.

      One solution is to avoid superscalar, out of order architectures, which have speculative execution. Simpler architectures aren't vulnerable, but they are very very slow by comparison.

  • Does that include Granite Rapids? If so that's pretty bad. In fact most of Intel's datacentre AND consumer lineup will be affected. Only Lunar Lake would be immune at a hardware level, along with Arrow Lake once they launch it. Intel won't have a datacentre product for potentially another two years that doesn't require some sort of further mitigation, unless you count Clearwater Forest (which hopefully won't be affected).

  • OpenBSD's solution was to disable SMT and take the hit. The project that is the only real option. Even a Linux Kernel developer agreed (forgot who). Seems that may me the only real solution instead of forcing Intel/AMD for recalls.

    https://www.tomshardware.com/news/openbsd-disables-intel-hyper-threading-spectre,37332.html

    • Re: (Score:1)

      by Anonymous Coward
      Seems to me there will always be problems where you have potentially hostile code sharing stuff and speculative execution where you have shared resources (e.g. cpus, caches, memory).

      Many of these attacks involve the the hostile process trying to access stuff and figuring out stuff based on whether the access is faster or not.

      The thing is when the process is NOT hostile you often want the access to be faster.

      • Seems to me there will always be problems where you have potentially hostile code sharing stuff and speculative execution where you have shared resources (e.g. cpus, caches, memory).

        Many of these attacks involve the the hostile process trying to access stuff and figuring out stuff based on whether the access is faster or not.

        The thing is when the process is NOT hostile you often want the access to be faster.

        I would mod this up if I had points. The issue is any cpu made in the past 30 years or so does speculative execution and branch prediction. I know there are bits from DEC that have been ported to Intel/AMD to mark certain registers as data and not execution. Maybe there should be registers and cache that are not readable outside the cpu that are used internally.

    • Re: (Score:2)

      by Briareos ( 21163 )

      How about just having only threads from the same process share a core, with a way for processes to opt out of that?

      If I'm crunching numbers locally or playing a game having threads share a core shouldn't be a problem (I mean, why would the process even try shenanigans to spy on itself?), and if it's a browser running code from who knows where give it a way to flag itself and then keep all it's threads on separate cores, without running a second thread on the same core...

  • Every CPU in the 21st has branch predictions, cache, and speculative execution. There is no way to fully block this at the assembly level. DEC invented marking certain memory addresses as data and not executable to peaking and poking holes. Could it be possible to make a completely black box register and cache to store values that are 100% inaccessible outside the cpu to store data?

    This feels more like a black box drm but I see no way to prevent this and without destroying performance in a fruitless endevor

  • and the summary even admits it's fixed, I guess it's about time for a useless RowHammer update too, just so we can't finally forget that those researchers exist, either.

Slashdot Top Deals

It's been a business doing pleasure with you.

Close