Thursday, June 14th 2018

Intel Processors Hit by "Lazy FP State Restore" Vulnerability

Security researchers have discovered a vulnerability affecting all modern Intel Core and Xeon processors, which is an exploit of a performance optimization feature called "lazy FP state restore," which can be exploited to sniff out sensitive information, including cryptographic keys used to protect sensitive data. The flaw affects all x86 micro-architectures by Intel, "Sandy Bridge" and later.

The "lazy FP state restore" feature is a set of commands used to temporarily store or restore the FPU states of applications running "lazily" (as opposed to "eagerly"). Red Hat put out an advisory stating that numbers held in FPU registers could be used to access sensitive information about the activities of other applications, including encryption keys. Intel began working with popular OS vendors to quickly roll out software patches against the vulnerability.
Sources: Intel, Red Hat, TheHackerNews
Add your own comment

43 Comments on Intel Processors Hit by "Lazy FP State Restore" Vulnerability

#1
btarunr
Editor & Senior Moderator
One by one, all of the secret-sauce features that made Intel processors faster than AMD are turning out to be exploitable; and being neutered by software patches.
Posted on Reply
#2
DeathtoGnomes
Hopefully that will get fixed in the new architecture, Intel Core Cascade Fake. :D
Posted on Reply
#3
dj-electric
btarunr said:
One by one, all of the secret-sauce features that made Intel processors faster than AMD are turning out to be exploitable; and being neutered by software patches.
I didn't know that insanely low latency between cores, high IPC, post 4.5Ghz operating frequency and software optimizations by software makers are all exploitable.
Posted on Reply
#4
qubit
Overclocked quantum bit
Since Sandy Bridge - that's my CPU a security risk then. :rolleyes:
Posted on Reply
#5
dorsetknob
"YOUR RMA REQUEST IS CON-REFUSED"
The flaw affects all x86 micro-architectures by Intel, "Sandy Bridge" and later.
Guess then my CPU is Safe then (pre Sandy:))
Posted on Reply
#6
the54thvoid
Just like prior AMD concerns, what is required to access this flaw? So many of these are found in highly specific, isolated environments, that are unrealistic to implement.

I'm more concerned about the router hack that is under FBI investigation right now...
Posted on Reply
#7
R0H1T
dj-electric said:
I didn't know that insanely low latency between cores, high IPC, post 4.5Ghz operating frequency and software optimizations by software makers are all exploitable.
Then you must've missed meltdown & spectre :ohwell:
Posted on Reply
#8
stimpy88
So Intel stopped designing new CPU's years ago, ever since giving us valued customers 3-6% IPC increases each "generation" of the Core2 architecture, then with these vulnerabilities comes with it the news that these optimizations are half assed, and open the CPU up to security flaws...

If Intel are not careful, all those "massive" 3-6% improvements dating back the last 10 years or so will be gone, and we will be back to 2008 performance levels, with our shiny "new" and very expensive CPUs.
Posted on Reply
#9
Aquinus
Resident Wat-man
btarunr said:
numbers held in FPU registers could be used to access sensitive information about the activities of other applications, including encryption keys.
Quick question. Why the hell is an encryption key stored in a FP register? You need exact math for crypto which usually means integer/fixed point. If anything, encryption keys would be stored in an integer register if the register was big enough. I don't know about the rest of you, but most of my keys that I generate myself are 8192 bits long which is a whole lot bigger than FP or integer registers are. Something about this doesn't smell right.

@btarunr, is there a link you can share?

Edit: Found one: https://www.phoronix.com/scan.php?page=news_item&px=Lazy-State-Restore-Spec-Exec

Edit 2: ...and this one: https://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html

Note how neither of those links say anything about leaking encryption keys but rather just exposing FP register state. Is it a possible vulnerability, yes. Is it going to leak encryption keys? Probably not.
Posted on Reply
#10
kruk
So, it looks like Spectre/Meltdown researchers opened up a massive can of worms. I hope both vendors take security more seriously in the future ...
Posted on Reply
#11
Vya Domus
Aquinus said:
Quick question. Why the hell is an encryption key stored in a FP register? You need exact math for crypto which usually means integer/fixed point. If anything, encryption keys would be stored in an integer register if the register was big enough. I don't know about the rest of you, but most of my keys that I generate myself are 8192 bits long which is a whole lot bigger than FP or integer registers are. Something about this doesn't smell right.
You do not need a 8192 bit wide register to compute 8192 bit wide calculations , you just need a huge sequence of operations involving smaller registers. And then if you have access to them you can easily infer what those huge numbers are from observing that series of results coming of those registers. Compilers do this all the time when you try , for example to do 64 bit math on 32 bit capable machines. If you look at the machine code generated by it , you can tell where that 64 bit calculation took place even though it involved only 32 bit registers.


Aquinus said:

Note how neither of those links say anything about leaking encryption keys but rather just exposing FP register state.
Well , that's the whole point of it , you don't need to get the key in it's entirety , you just need to know what was in those registers at the right time.
Posted on Reply
#12
Fluffmeister
dorsetknob said:
Guess then my CPU is Safe then (pre Sandy:))
Ditto, hopefully one day there will be a CPU worth upgrading too.
Posted on Reply
#13
R0H1T
More info, straight from the horse's mouth. So I guess lazy FP restore isn't an AMD thing, that's why they're not vulnerable.
Intel LazyFP vulnerability: Exploiting lazy FPU state switching

Posted on June 6, 2018 by Thomas Prescher, Julian Stecklina, Jacek Galowicz

After Meltdown (see also our article about Meltdown) and Spectre, which were publicly disclosed in January, the Spectre V3a and V4 vulnerabilities followed in May (see also our article about Spectre V4). According to the German IT news publisher Heise, the latter might be part of 8 new vulnerabilities in total that are going to be disclosed in the course of the year.
Earlier this year, Julian Stecklina (Amazon) and Thomas Prescher (Cyberus Technology) jointly discovered and responsibly disclosed another vulnerability that might be part of these, and we call it LazyFP. LazyFP (CVE-2018-3665) is an attack targeting operating systems that use lazy FPU switching. This article describes what this attack means, outlines how it can be mitigated and how it actually works.
For further details, see the current draft of the lazyFP paper: Link withheld by request from Intel

Please check back regularly, we’re going to update this post in coordination with Intel.

Summary and Implications
The public disclosure of this vulnerability was initially postponed by a typical responsible disclosure information embargo until August, but first rumors led to this date being dropped.
The register state of the floating point unit (FPU), which consists of the AVX, MMX and SSE register sets, can be leaked across protection domain boundaries. This includes leaking across process- and virtual machine boundaries.
The FPU state may contain sensitive information such as cryptographic keys. As an example, the Intel AES instruction set (AES-NI) uses FPU registers to store round keys. It is only possible to exploit when the underlying operating system or hypervisor uses lazy FPU switching.
Users are affected when they run a combination of affected processor and affected operating systems.
  • Affected operating systems:[list]
  • Currently withheld by request from Intel
  • Affected CPUs when affected operating system or hypervisor is used:
    • Currently withheld by request from Intel
    [/list]Mitigation requires system software to use eager FPU switching instead of lazy FPU switching.

    External ReferencesTechnical Background
    This vulnerability is similar to Meltdown (CVE-2017-5754). While Meltdown allowed to read protected memory contents from a user space program, this new attack allows to read certain register contents across protection domain boundaries.
    Further explanation withheld by request from Intel.
    To have a better understanding of how this attack actually works, it is necessary to dive deeper into the inner workings of the x86 FPU, and how it is used by operating systems.

    The Floating Point Unit (FPU)
    In the early days of x86, the FPU (also called math coprocessor) was an external co-processor that could be added to Intel’s now widely adopted x86 processor architecture. The Intel 8087 was the first floating point math co-processor of this kind. The purpose of this extension was to accelerate mathematical operations on floating point numbers, such as division and multiplication. With the Intel 486DX CPU model (released in 1989), the FPU got integrated into the microchip itself. This way, no additional co-processor was needed anymore.
    Over the years, the processor was extended to support Single Instruction, Multiple Data (SIMD) instruction sets, i.e. MMX/SSE/AVX. SIMD instructions perform the same mathematical operation on multiple pairs of operands at the same time in order to improve performance. Each of these instruction set extensions introduced new register sets that continue to be managed as part of the FPU register state. On recent Intel processors, the FPU register state can contain more than 2 kB of data (AVX2 offers 32 registers of 512 byte, each, which translates into 2 kB additional processor state). Due to the usefulness of these instructions this register set may contain not only floating point values but also other data as e.g. integer values.

    Loading and Storing the FPU state
    To enable multi-tasking, operating systems periodically interrupt processes to give other processes a chance to run. Otherwise a single process that loops forever could grind the system to a halt.
    When the operating system switches from one process to another, it needs to save the state of the previous process and restore the state of the process that is about to be run. This state consists of the values stored in general purpose registers and FPU registers.
    The x86 instruction architecture provides several instructions to load/store the register state of the FPU from/to memory. We already know about the large size of the FPU state, hence it is pretty obvious that one does not want to read and write such amounts of data on every context switch unless it is actually necessary, because not all processes use the FPU.

    Eager and Lazy FPU Switching
    Eager FPU switching is comparable to saving the general purpose register state on a context switch. For each process, the operating system reserves an area in memory to save the FPU state. When switching from one process to another, it executes an FPU store instruction to transfer the current FPU content to the state save area. It then loads the new FPU state from the state save area of the process that is about to be scheduled.
    Lazy FPU switching optimizes this procedure for the case where not every process uses the FPU all the time.
    After a context switch, the FPU is disabled until it is first used. Only then, the old FPU state will be saved, and the correct one restored from memory. Up to this point, the FPU keeps the register state of the process or VM that used it last.
    To implement this optimization, the operating system kernel temporarily disables the FPU by setting a certain control register bit (CR0.TS). If this bit is set, any attempt to access the FPU will cause an exception (#NM, Device Not Available, No Math Coprocessor). When the exception occurs, the kernel can save the old state to the respective state area and restore the state of the current process. Processes that simply do not use the FPU will never trigger this exception and hence never trigger FPU state stores and loads.
    Starting with the introducton of the x86-64 architecture, the presence of at least some SIMD instruction set extensions is mandated and their use has become more widespread. As such the underlying assumption of lazy FPU switching is not valid anymore. The performance gain by lazy FPU switching has become negligible, and some kernels already removed it in favor of eager switching.

    The Attack
    This section is currently withheld by request from Intel.

    Mitigation

    Using GNU/Linux with kernel versions >= 3.7, this attack can be mitigated by adding “eagerfpu=on” to the kernel’s boot parameters. We are not aware of a workaround for older versions. For all other operating systems: install the official update(s) from the vendor.
    We are not aware of a performance penalty caused by using eager FPU switching. The commit message of the Linux kernel patch that made eager FPU switching the default on Linux systems even points out that the assumptions which justified lazy FPU switching in the past do not hold any longer on the majority of modern systems.

    Cyberus Technology GmbH



    So erreichen Sie uns
  • Posted on Reply
    #14
    Dave65
    DeathtoGnomes said:
    Hopefully that will get fixed in the new architecture, Intel Core Cascade Fake. :D
    I think the next one is DRY LAKE:laugh:
    Posted on Reply
    #15
    Axaion
    "The public disclosure of this vulnerability was initially postponed by a typical responsible disclosure information embargo until August,"

    Just in time to release another CPU with the bug and go "lol, oops."
    Posted on Reply
    #16
    Zubasa
    dj-electric said:
    I didn't know that insanely low latency between cores, high IPC, post 4.5Ghz operating frequency and software optimizations by software makers are all exploitable.
    Some of that high IPC might have came from cutting corners in security.
    Software optimizations, in this case god knows what the software companies put in their bloatware anyway.
    I am not saying this is definitely the case, but exploitable? Apparently yes.
    Posted on Reply
    #17
    dj-electric
    Zubasa said:
    Some of that high IPC might have came from cutting corners in security.
    Software optimizations, in this case god knows what the software companies put in their bloatware anyway.
    I am not saying this is definitely the case, but exploitable? Apparently yes.
    The idea behind my somewhat sarcastic comment was to counter the ridicules claim that Intel's performance edge will disappear after a few security patches.
    Posted on Reply
    #18
    qubit
    Overclocked quantum bit
    dj-electric said:
    The idea behind my somewhat sarcastic comment was to counter the ridicules claim that Intel's performance edge will disappear after a few security patches.
    I'm not able to graph it right now, but this is the result after applying all security patches to Intel processors in a benchmark:

    Intel's fastest fancy million core Xeon CPU: 500 points
    Any AMD CPU: 1200 points

    As you can see, critical damage has been done to Intel.
    Posted on Reply
    #19
    First Strike
    btarunr said:
    One by one, all of the secret-sauce features that made Intel processors faster than AMD are turning out to be exploitable; and being neutered by software patches.
    Smell of ignorance there. Do you keep a clear account of how many optimizing features Intel kept?
    Posted on Reply
    #20
    Caring1
    First Strike said:
    Do you keep a clear account of how many optimizing features Intel kept?
    What part of secret sauce do you not get? :roll:
    Posted on Reply
    #21
    mouacyk
    Pretty soon, with all the "security" patches, our desktop CPUs will run like server molasses. Probably worse, due the mitigation being almost entirely in software.
    Posted on Reply
    #22
    csgabe
    More like lazy engineers vulnerability.
    Posted on Reply
    #23
    eidairaman1
    The Exiled Airman
    And I guess in town knew about this one before they launch the processors way back then too
    Posted on Reply
    #24
    coonbro
    key thing I see from all this stuff is how a lot of posters say ''upgrading '' $$$$ I now wonder with how it is with this computer hardware and all if all this is a scare tactic to help insure you keep upgrading fast instead of keep running your older works well today hardware . like that spector and meltdown thing , how many post around the forums do you see a lot of folks being affected by it and suffered to have ot go ''upgrade '' $$$ ? . its all now about how much faster they can dupe you in to spending more of your money to them as fast as you can ? if we can dupe you in to a scare tactic to get you to upgrade in 1 or 2 years instead of 4 or 5 ?? ya, .
    Posted on Reply
    #25
    efikkan
    Aquinus said:
    Quick question. Why the hell is an encryption key stored in a FP register? You need exact math for crypto which usually means integer/fixed point.

    Note how neither of those links say anything about leaking encryption keys but rather just exposing FP register state. Is it a possible vulnerability, yes. Is it going to leak encryption keys? Probably not.
    The problem here is many people automatically conclude that since there is a leak of information, that information can be sensitive, and then jump to the worst case example of sensitive data, forgetting if that kind of data can be stored there in the first place. And you're right, encryption keys will not be stored in the FPU state register.

    As mentioned in the Red Hat source, these leaks can be used for one process to make assumption of the state of execution of another process. So it wouldn't leak actual sensitive data, but leak context. This sounds like an extreme edge case, but we'll see if they eventually find more "related" bugs that are actually serious. For a data leakage from a CPU to be useful, you would have to be able to target reading of specific memory addresses or similar, so you can slowly assemble sections of memory. If the data leaked is either uncontrollable or just general state information, then it's useless by itself, and probably in a larger context too.

    Let me give another example of similar incorrect assumptions. Quite often we hear of new bugs in software where an attacker can cause a buffer overflow. Since a buffer overflow in theory can lead to arbitrary code execution, people usually automatically consider the bug serious and tell everyone to patch it immediately. In reality, "all" modern PCs have execute bit protection enabled which would stop any such exploit. But since there are still systems out there that may be vulnerable, this is automatically assumed critical, even though it's mostly limited to enterprise embedded systems, routers, legacy systems(>15 years). This very important distinction is almost always lost in the articles about the exploits.

    kruk said:
    So, it looks like Spectre/Meltdown researchers opened up a massive can of worms. I hope both vendors take security more seriously in the future ...
    It's fairly common that one new bug gives researches ideas for new approaches of testing, and if a bug is due to incorrect assumptions, you can probably find more "related" problems. If you remember the software bug "Heartbleed", in the hysteria that followed, researchers found at least another 10 serious bugs. And people finding real bugs is a good thing.
    Posted on Reply
    Add your own comment