Intel Processors Hit by "Lazy FP State Restore" Vulnerability

[efikkan]

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

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.

 

[Blueberries]

This is actually pretty brilliant... I wonder if the FP registers can actually be traced back to a specific page file or if they would just be logged and shotgunned.

 

[Aquinus]

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.




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.

Well, it's not like you know exactly when those registers have the data you're looking for and that there are only certain times that this becomes a possible exploit but, that's completely beside the point. Once again, it doesn't really matter either way because encryption keys aren't going to be stored in floating point registers because most cryptographic ciphers do integer math and bitwise operations. So there is absolutely no reason why something like an encryption key should be an FP register. It literally makes no sense.

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.

People need to understand when floating point is used and it's not for cryptography most of the time. Hell, you don't even want to do financials or anything where numbers have to add up with FP. You use this for things like timing and geometry where being exact isn't a big deal, literally the opposite of cryptography.

 

[Blueberries]

People need to understand when floating point is used and it's not for cryptography most of the time. Hell, you don't even want to do financials or anything where numbers have to add up with FP. You use this for things like timing and geometry where being exact isn't a big deal, literally the opposite of cryptography.

Single-precision floating points are 32 bits, or 7 decimal places of precision. Almost all applications use integers or floating points, anything more would be an erroneous allocation of memory. I can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

Modern encryption has a result typically 512 bits, with older encryption ranging from 128-256 bits. These signatures are generated using a number of factors including random seeds, server ticks, timezones, etc., that are typically stored in floating point registers.

 

[Aquinus]

I can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

Yes you can. It's called fixed point numbers. $19.00 would be represented as 1900.

 

[Captain_Tom]

Once again - when I searched for a secure laptop to hold sensitive data, it could NOT be Intel. No Intel system should be used to store any sensitive data.

 

[R-T-B]

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.

That's just silly. The most recent vulnerabilities like Spectre and Spectre-NG were targeting more general purpose out of order execution you know...

Once again - when I searched for a secure laptop to hold sensitive data, it could NOT be Intel. No Intel system should be used to store any sensitive data.

Honestly, when I was in a similar boat, it HAD to be intel, only because the ME is more understood than AMD's PSP.

Neither is truly secure. If you worry that much, you are basically going to have to worry. Sorry.

 

[wiak]

leaked intel road map now includes a "Exploit Lake EP"

 

[Blueberries]

Yes you can. It's called fixed point numbers. $19.00 would be represented as 1900.

I suppose you could but I would still hate you for doing it.

 

[R-T-B]

I suppose you could but I would still hate you for doing it.

Do you hate your PC?

It does it all the time. Trust me.

 

[jigar2speed]

I feel sad for my Intel CPU, its freaking full of security holes.

 

[DeathtoGnomes]

I feel sad for my Intel CPU, its freaking full of security holes.

You should feel praised for it being so Holy.

 

[Aquinus]

View attachment 102408

I suppose you could but I would still hate you for doing it.

You wouldn't hate the performance.

 

[Blueberries]

You wouldn't hate the performance.

We're talking less than a clock cycle

Do you hate your PC?

It does it all the time. Trust me.

The only reason a floating point be popped off the stack and returned as an integer is if it was instructed to... and if my PC is sentient and writing obfuscated code with integers where floats are much more logical and easier to read, input, and convert, I'm firing it.

 

[R-T-B]

The only reason a floating point be popped off the stack and returned as an integer is if it was instructed to...

Point is, it happens all the time in programs and it is regularly done, so yeah. It's because floating point ops aren't perfectly precise while integer ops are.

 

[Readlight]

That means all these security procesors tpm are completely useles.

 

[Aquinus]

That means all these security procesors tpm are completely useles.

No, it doesn't.

Once again, it doesn't really matter either way because encryption keys aren't going to be stored in floating point registers because most cryptographic ciphers do integer math and bitwise operations. So there is absolutely no reason why something like an encryption key should be in an FP register. It literally makes no sense.

 

[efikkan]

Single-precision floating points are 32 bits, or 7 decimal places of precision. Almost all applications use integers or floating points, anything more would be an erroneous allocation of memory. I can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

I suppose you could but I would still hate you for doing it.

I have to add to what Aquinus is correctly pointing out. People are commonly mistaking "integer" and "float" as simply integer numbers and floating point numbers. Most programming languages use a variant of IEEE 754 in this format: a × 2 ^ b. This results in a huge range, but constant precision per exponent of 2, which means the relative precision is constant for intervals like 2->4, 4->8, 8->16, … As you can see in the Wikipedia article, the error can be as high as 20% with 7 digits of precision. Even with 64-bit float formats ("doubles"), the rounding errors can be easily exceed 0.1%, and some much higher than that. If you know anything about how exponential numbers work, you'll understand that rounding of numbers in the format a × 2 ^ b can have very large errors when either the exponent of two numbers are very different or the numbers are close enough to cause a change in exponent. You might think this "relatively small" error is still unproblematic and be close to zero in average, but when you repeatedly do multiplication or divisions, errors tend to grow exponentially. This is why the financial sector does calculation in integer datatypes with a large base number, so the rounding errors are predictable.

You can see the problem in action by pressing F12 in your web browser and do the following calculations in the console:
0.1 + 0.2
0.01 + 0.06

Now try some rounding in JavaScript:
parseFloat(55.555).toFixed(2);
parseFloat(1.3555).toFixed(3);
(just paste it into the console, line by line)

Spoiler: Results

55.55 instead of the expected 55.56
1.355 instead of the expected 1.356

Remember that banks may calculate interest and fees monthly or even daily, these "small" rounding errors can grow exponentially when multiplying thousands of times.

This subject is actually highly relevant for software development. I've had several episodes with colleagues who insist this is a bug in the code or in the programming language, who even struggle to understand it after a detailed explanation, despite having master degrees in CS and many years of experience. The only "bug" is the programmer's lack of understanding of how theoretical math is applied to actual hardware and software, and the sad thing is that this is elementary stuff in CS.
</math_lesson>

 

[Jism]

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.

Well, keep patching and at some point those performance edge will lower. in VM systems the latest patch would seriously harm performance. We're not talking desktops here, but enterprise based on Intel hardware. The performance impact was seen there at most with meltdown and all.