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.

Hopefully that will get fixed in the new architecture, Intel Core Cascade Fake. :D

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

Since Sandy Bridge - that's my CPU a security risk then. :rolleyes:

The flaw affects all x86 micro-architectures by Intel, "Sandy Bridge" and later.

Guess then my CPU is Safe then (pre Sandy:))

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

dj-electricI 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:

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.

btarunrnumbers 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: www.phoronix.com/scan.php?page=news_item&px=Lazy-State-Restore-Spec-Exec

Edit 2: ...and this one: 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.

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

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

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

dorsetknobGuess then my CPU is Safe then (pre Sandy:))

Ditto, hopefully one day there will be a CPU worth upgrading too.

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:
  • Currently withheld by request from Intel
• Affected CPUs when affected operating system or hypervisor is used:
  • Currently withheld by request from Intel

Mitigation requires system software to use eager FPU switching instead of lazy FPU switching.

External References

• Intel security advisory INTEL-SA-00145
• Amazon Security Bulletin

Technical 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.
[INDENT]Further explanation withheld by request from Intel.[/INDENT]
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
[INDENT]This section is currently withheld by request from Intel.[/INDENT]

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

DeathtoGnomesHopefully that will get fixed in the new architecture, Intel Core Cascade Fake. :D

I think the next one is DRY LAKE:laugh:

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

dj-electricI 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.

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

dj-electricThe 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.

btarunrOne 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?

First StrikeDo you keep a clear account of how many optimizing features Intel kept?

What part of secret sauce do you not get? :roll:

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.

More like lazy engineers vulnerability.

And I guess in town knew about this one before they launch the processors way back then too

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

AquinusQuick 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.
<snip>
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.

krukSo, 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.