Intel “lazy FP state restore” vunerability could expose privileged data

Security researchers have uncovered a new microarchitectural vulnerability in some Intel processors. Called “Lazy FP State Restore,” this vulnerability relies on a side channel to leak potentially privileged data after the processor performs a context switch from an unprivileged process to a privileged kernel function, according to security analysis from Red Hat. Both Intel and Red Hat classify the potential impact of this vulnerability as “moderate.” AMD CPUs are not affected.

As with Spectre and Meltdown, the vulnerability stems from efforts to improve performance. Context switches are microarchitecturally expensive, and the less data that needs to be moved around during such a switch, the better. The leak relies on the fact that the processor can defer saving and restoring of FPU state until a new process actually uses the CPU's floating-point unit after a context switch (hence “lazy”). An attacker can apparently use another process to reveal or infer this lazily-restored data from target processes, although full details of the exploit are not yet available. Since the CPU's floating-point registers are often involved in cryptographic calculations, the ability to read data from them is bad news, according to The Register.

The choice to use lazy FPU save-and-restore is an operating-system-and-software-level one, so microcode updates won't be required to mitigate it, according to a statement provided to The Register by Red Hat. The issue apparently doesn't affect Intel processors uniformly, eitherโ€”Red Hat says newer Intel CPUs implement instructions that make the potential performance benefits of the lazy FP state restore mostly irrelevant, so the technique isn't used on those chips.

The Linux vendor says that operating systems using the lazy method of FPU restore should be configured to use “eager” FPU restore instead, in which the entire FPU state is swapped on every context switch, although a list of affected CPUs is not yet available. Given that Red Hat says version 7 of its Enterprise Linux OS uses this “eager” technique by default on Sandy Bridge and newer Intel architectures, the issue is likely confined to pre-Sandy Bridge chips.

Red Hat says it will be issuing an update to versions 6 and earlier of its operating system to expose a flag to configure eager FPU restore in the kernel. The company says enabling the parameter will not affect performance on vulnerable systems. The Register says Microsoft also has patches for affected systems in the works. As always, we advise TR readers to enable automatic updates on their systems and use supported versions of their operating system of choice.

Intel provided TR with the following statement on the vulnerability:

This issue, known as Lazy FP state restore, is similar to Variant 3a. It has already been addressed for many years by operating system and hypervisor software used in many client and data center products. Our industry partners are working on software updates to address this issue for the remaining impacted environments and we expect these updates to be available in the coming weeks. We continue to believe in coordinated disclosure and we are thankful to Julian Stecklina from Amazon Germany, Thomas Prescher from Cyberus Technology GmbH, Zdenek Sojka from SYSGO AG, and Colin Percival for reporting this issue to us. We strongly encourage others in the industry to adhere to coordinated disclosure as well.

Comments closed
    • ronch
    • 1 year ago

    So bottomline is, Intel’s taking questionable shortcuts to achieve better performance while compromising security, and all these recent discoveries are somehow putting them and AMD back on equal footing.

      • Redocbew
      • 1 year ago

      I could tell you you’re wrong, but I’m eager to avoid the shenanigans involved in that.

        • ronch
        • 1 year ago

        Don’t worry, the feeling’s mutual. ๐Ÿ™‚

        • jihadjoe
        • 1 year ago

        Or are you just being lazy?

          • Growler
          • 1 year ago

          Redocbew needs to check his privilege(d data).

            • Redocbew
            • 1 year ago

            No escalation of privilege here. Purported or otherwise.

    • xeridea
    • 1 year ago

    Man, Seems every week more news of how Intel gets its good IPC and clocks. Dozens of lazy hacks and shortcuts, at the expense of dozens of security holes. If all these were fixed in hardware, Ryzen may have better IPC than Intel.

    Of all the security vulnerabilities, AMD has only been subject to one IIRC, one of the 2 Spectre variants initially discovered. Not Meltdown, not the dozen other Spectre variants, not this, likely not what else is bound to show up.

      • chuckula
      • 1 year ago

      AMD is [url=https://cyware.com/news/amds-sev-virtual-machine-encryption-can-be-broken-to-extract-memory-data-researchers-say-2b86a4d4<]truly perfect in every way especially with its completely unbreakable VM encryption that's perfect and could never ever possibly be cracked wide open less than a year after Epyc launched.[/url<]

        • ronch
        • 1 year ago

        I don’t believe it until you confirm it, Chuck. Do it now.

          • Redocbew
          • 1 year ago

          I think confirmation need not be required in this case.

            • ronch
            • 1 year ago

            Until he confirms it, any news is considered Fake News.

        • xeridea
        • 1 year ago

        IIRC the attack required administrator access, which at that point you are screwed anyway.
        Intel had a super easy to exploit flaw, Meltdown, in CPUs for 10 years. It was likely known my shady folk for much of that time. Intel also has had plenty of low level firmware exploits that could easily cripple a business. We are comparing 2-3 exploits, to 20. I never said they were perfect, just that they had significantly less flaws.

        • kuttan
        • 1 year ago

        Yeah AMD 2/10 vulnerability.
        Intel 10/10 vulnerability.

        Chuckula paid AMD hate failed again ๐Ÿ˜€

        • shank15217
        • 1 year ago

        Hey genius, very few people are actually encrypting VM memory in the first place.

      • Klimax
      • 1 year ago

      You have an error there. AMD was vulnerable to second wave of Spectres.

        • xeridea
        • 1 year ago

        Are you talking of variant b, or the round of 8 that were discovered. Last I checked the reports, AMD was not vulnerable to the 8, but I didn’t follow up later.

          • psuedonymous
          • 1 year ago

          For the currently (publicly) known SPECTRE vulnerability variants – 1, 2, 3, 3a, and 4 – AMD’s current CPUs are known to be vulnerable to 1, 2, and 4. SPECTRE is not ‘a’ vulnerability but a whole new [i<]class[/i<] of vulnerabilities, and it is very likely as more will be found more wqill also be found that Ryzen is vulnerable to (as they also affect ARM, POWER, and all other architectures that use Speculative Execution).

    • chuckula
    • 1 year ago

    [quote<]Given that Red Hat says version 7 of its Enterprise Linux OS uses this "eager" technique by default on Sandy Bridge and newer Intel architectures, the issue is likely confined to pre-Sandy Bridge chips.[/quote<] You can learn more about "lazy" vs. "eager" [url=https://tthtlc.wordpress.com/2016/12/17/understanding-fpu-usage-in-linux-kernel/<]here[/url<]. TL;DR version: Unless you go out of your way to change from the defaults, a modern Linux system doesn't even need an additional patch because you are already in eager mode.

      • Waco
      • 1 year ago

      This. I saw the announcement, groaned, read the details, and then realized nobody is going to care or have to lift a finger to fix this.

        • jihadjoe
        • 1 year ago

        I read somewhere that ‘lazy’ was basically a holdover from the days when the FPU was a separate chip.

          • mczak
          • 1 year ago

          I think it had its uses quite past that old age – the cost of saving/restoring fpu state is still quite high (hundred or so cpu cycles) on modern cpus.
          However, it is true that lazy fpu state restore doesn’t really help (and may be slightly worse even due to the cost of the exception handler when you do have to restore in the end anyway) in modern environments.
          Of course, there’s plenty of apps which are “mostly” integer – but still having the rare fpu instruction (that one is even true for old environments).
          But even if some app never actually uses floating point, it will still likely touch sse (xmm) or avx (ymm) registers nowadays anyway. For instance, all optimized memcpys (when it’s more than a few bytes to copy) will use sse (or avx) for it – you can read 128bit (or 256bit) chunks at once instead of 32bit (ok, 64bit with 64bit OS), and there’s some neat streaming options if you don’t want to pollute caches (usually used if very large chunks are copied). Auto-vectorizing integer code will also use sse2. So do the AES-NI instructions (where of course this bug is very problematic).
          So, in a nutshell, all tasks are nearly guaranteed to actually need xsave/xrestore anyway, hence there’s no point in trying to do it only when needed, it’ll just cause an exception handler to run to do it.
          Also note that there’s xsaveopt which should help with saving only state if things actually changed (but I don’t know how much that helps).

    • JosiahBradley
    • 1 year ago

    By the time these security vulnerabilities start ramping down, AMD and Intel IPC should probably even out.

      • DPete27
      • 1 year ago

      No kidding. I know Intel was “rushed” into the Spectre and Meltdown patches, but I’d like to believe there’s something they can do given the time that has passed to update those patches and give some performance back?

      • Srsly_Bro
      • 1 year ago

      And with AMD 32 for threadripper vs the upcoming 22 core, and next year AMD 7nm, Intel will be no more.

      My bro @Chuckula will be in the soup line unless he jumps ship now.

        • bjm
        • 1 year ago

        Nah, he’ll be fine. There’s going to be a new line of chuckula AIO coolers coming out soon and they will be a hit. I hear they perform as well as chilled water coolers.

          • chuckula
          • 1 year ago

          Good, I have the [url=http://www.guru3d.com/news-story/amd-radeon-pro-v340-with-two-vega-10-gpus-surfaces-online.html<]GPU for that cooler.[/url<]

            • bjm
            • 1 year ago

            Impressive! I didn’t know you could cool vaporware.

            • willmore
            • 1 year ago

            Du’ah, he’s use a vapor phase cooler. ๐Ÿ˜‰

        • chuckula
        • 1 year ago

        What makes you think I haven’t done it already!

        #MoAMDMoneyMoTrollPosts

        • Gadoran
        • 1 year ago

        But…….do you really trust in GloFo?
        Are you sure a fully functional 7nm will be available from a company costrained to licesee 14nm from Samsung???
        Come on, not a way. 2020 is more likely.

          • Zizy
          • 1 year ago

          Yes, considering it came from IBM ๐Ÿ˜€
          Furthermore, AMD can use TSMC. They are the leading fab at this moment.

Pin It on Pinterest

Share This