nav search
Data Centre Software Security DevOps Business Personal Tech Science Emergent Tech Bootnotes
BOFH
Lectures

back to article
Intel chip flaw: Math unit may spill crypto secrets from apps to malware

Silver badge

"Lazy state FPU restore" sounds like a lot of the problems in computers/programming now

We all grew up thinking we owned our computer, or at least our particular process on the computer, or maybe the thread that we were handed out in the old time-sharing systems.

We learned that those bits written to mag tape, drums, huge disk farms, (punched cards and tape) could later be read by the unwashed. But erasing old bits was really too expensive and it's really hard to put the chaff back into the hollerith cards.

Moving to shared memory storage - same problem but can be resolved in milliseconds instead of hours. Still not worth it for the computer/system manufacturers.

Memory caches (and these are now so multi-level that it's hard to say where one cache starts and another ends) exacerbate the problem many-fold. L1/L2/L3, in-processor vs. on chip. USB devices with their own secret ways of storing info that can't be erased.

I'm not sure a router/PC/network reboot to "factory settings" gets rid of the tentacles that are left behind.

19
1

Too much Gatorade?

Idiocracy takes hold.

3
9
Silver badge

"OpenBSD and DragonflyBSD projects published their patches to mitigate this issue – thus forcing the situation onto the world stage. The BSD teams went ahead after Intel declined to work with them under embargo, and instead stuck to larger operating system vendors and makers."

I'd like to think that'll prompt Intel to be bit more cooperative in future but I doubt it will.

55
0
Silver badge

They didn't work with the BSDs at the end of last year with the original Spectre/Meltdown, they didn't work with them just now, take a guess at what'll happen next time.

24
0

Maybe I should take another punt at moving to OpenBSD then...

13
0

Floating point crypto operations?

I'm not aware of any cryptographic operations that are implemented using floating point arithmetic. Can someone explain? Does the FPU also support integer arithmetic nowadays? I am so stuck in the 1980s.

7
2

This post has been deleted by its author

Silver badge

Re: Floating point crypto operations?

I'm not an expert, but elliptic-curve cryptography sounds like it needs some floating point arithmetics.

6
1
Def
Silver badge
Headmaster

Re: Floating point crypto operations?

The SSE instruction extensions support float, integer, and double operations. While the micro-ops for each variation will be processed through different execution ports the XMM register set is shared.

15
0
(Written by Reg staff) Silver badge

Re: Floating point crypto operations?

Intel's AES-NI instructions use FP registers to store AES round keys.

[Source]

C.

23
0
Happy

Re: Floating point crypto operations?

Thank you all for filling me in on this. I did not realize that the scope of the FPU had grown so much over the years!

5
0

Re: Floating point crypto operations?

It's not that the crypto is performed using the FPU, it's the fact that Intel when implementing the AES-NI instructions they (in their infinite wisdom) realised that due to the fact crypto does not typically use the FPU to perform it's calculations, could recycle the registers from the FPU instead of adding new ones specifically for AES-NI.

So, the FPU registers, when executing AES-NI instructions, can contain key-related data which due to the OS's lazy FPU state save/restore could leak to 3rd party processes.

22
0
Silver badge
Coat

Re: Floating point crypto operations?

> Intel's AES-NI instructions use FP registers to store AES round keys.

Where are the square and triangular ones kept?

19
0
Bronze badge

Re: Floating point crypto operations?

Where are the square and triangular ones kept?<P>

Does that even matter? The Pentagon types are the ones to worry about!

31
0
Silver badge

Re: Floating point crypto operations?

Modern x86 FPU programming is very different from historic programming - no-one uses the same methods used by the 8087, although obviously you can do if you really want.

7
0
Silver badge

Re: Floating point crypto operations?

"

good for X^Y which is rather frequent in cryptography

"

Not that I know of.

AES, 3DES etc. uses table-lookups and logical operations (e.g. rotates, xor ), I can't think of any use for a conventional FPU in any symmetrical key encryption I've worked with.

Public/private key cryptography does use a form of exponential arithmetic - but on "bignumbers" which must be handled using a very different (and strange) form of modulo arithmetic that again, I cannot see a conventional FPU providing much assistance with apart from a slight boost computing partial products of bignumber multiplies and Montgomery inverses, which would not leave any useful scraps in the registers.

I've implemented several common encryption and hashing functions as well as public key encryption using assembler on both Z80 and ARM based processors. An FPU was of no significant help, but several ARM based chips contain a hardware encryption engine, one of which even does bignumber functions such as modulo exponential and Montgomery multiplication etc.

5
0
Bronze badge

Re: Floating point crypto operations?

Again, I find myself forced to defend Intel.

Gates are not free. Floating point hardware, in particular, was the most expensive hardware on the part when integer registers were 32 bits. Repartitioning the gates that were used for floating point computations was just common sense and EVERYONE did it.

On a context switch, floating point access was disabled. If you attempted a floating point instruction, you would take an exception. The OS would save the floating point registers to the context of the appropriate thread, and then restore the values that your thread needed. This is called "lazy".

I can only assume that "eager" means that the values are saved & restored on every context switch. The only way that this could be faster would be if almost every thread was making use of these registers. I call BS.

Again, this is barely a HW issue at all. When an exception occurs, the processor only needs to save two registers--and the OS is responsible for making sure that the place that they are stored (two special registers) is clear. Everything else is the OS responsibility. The architecture has NEVER claimed to be side-channel free.

Well, now we realize that we've been using these processors in a way that require them to be side-channel free. Oops.

7
0
Silver badge

Re: Floating point crypto operations?

"I did not realize that the scope of the FPU had grown so much over the years!"

It actually hasn't. It's just that register reuse became popular.

Any task switcher needs to store all registers of an old task and restore all registers of the new task. If you add new registers, you'd need to change the code of your task switcher. In the 1990s when register reuse started, this obviously was a no-go. It would have meant that Microsoft would have to have provided patches to their existing software packages. For example that task switcher in dosshell would have had to be updated, as well as Windows.

Therefore they chose to re-use registers since that's way easier than convincing Microsoft to change their code.

1
0

OPENBSD people leaked this lol

So, the openBSD people were annoyed about not being included in the embargo again so they actually were talking about this a few days ago. You can see the video discussing the flaw in more detail here https://www.youtube.com/watch?v=UaQpvXSa4X8&t=473

1
13
Anonymous Coward

Re: OPENBSD people leaked this lol

OpenBSD people did not and could not "leak" this because THEY DID NOT HAVE ANY INFORMATION ABOUT IT! There was a rumour that there was some kind of issue in this area, that's all they had to go on.

17
0

Rumors of reboots at Azure, Google, and AWS

The BSD people have also mentioned that Azure, AWS, and all have Google’s infrastructure have been rebooted in the last 3 weeks- probably to implement a patch.

7
0

Here is the current fix in BSD

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474cbef7fcb61cd268019694d94db6a75af7dbe

5
0
Joke

I'm OK then...

...I don't use floating point, all my passwords are integer.

18
0
Anonymous Coward

Re: I'm OK then...

Reminds me of one of the pre-2000 Dilbert strips on the "millenium bug" with Ratbert declaring that the company was safe as he'd checked all their programs nad hadn't found any references to 2000 anywhere - "in fact all I could find were 1s and 0s"

11
0
Silver badge
Trollface

Re: I'm OK then...

...but if you use more than one decimal dot in your password, will it crash the FPU...?

2
0

Re: I'm OK then...

Ah, so your passwords are -

1

123

12345678

1337

0
0
Silver badge

While this is a data leak, right now it appears to be something that would be extremely difficult to exploit effectively. You get to see a snapshot of the FP registers. But you don't get to know the context, or even that it's from the process that you want to snoop on. And you don't get to sample frequently enough to get a correlated data set (or even a large data set).

8
0
Silver badge

True but...

I would assume it is like dropping keys in the street. To know which house it is for is near impossible. But a criminal could deduce something, else just try brute force. But the number of houses with 1 known good key, is an order of magnitude (or more) easier to brute force than the same number of houses and an unknown number of random keys.

2
0
Silver badge

> "I don't use floating point, all my passwords are integer."

You are using '1234' as well? That's my password!

11
0
Anonymous Coward

That's daft! You need to use something far more complex like I use abc123...oh...

1
0
Silver badge

'That's the kind of thing an idiot would have on his luggage!'

5
0
FAIL

Cost of recycling all those computers

Let them pay the cost of recycling

With soooo many scrapped computers and mobile phones (aprox every 2 years) being dumped.

Let Hardware and Software manufacturers pay the cost of recycling their own product !

Where a product is trashed by bugs or an operating system has never properly been supplied in full functioning and working order, requiring continual updates and bug fixes, that then ceases to be supported invalidating hardware Make them pay.

Understand FIT FOR PURPOSE.

Otherwise you will get fairy-floss and a piss puddle of excuses.

7
17
Silver badge

Homomorphic encryption only option

Homomorphic encryption is the only valid solution these days. Computationally expensive but what can you do when there is a side channel for everything?

3
7
Silver badge

Re: Homomorphic encryption only option

Homomorphic encryption only* allowed for operations to be performed on encrypted data. You still must encrypt it at time of input and decrypt it when you want to use those results, so whilst the attack surface would be reduced**, it is not eliminated. Something, somewhere is going to need to do some math on the key, at which point, whatever facts that can be inferred from these registers come into play.

*this is still pretty mind blowing

** and no doubt increased in other areas

10
0
Silver badge

Re: Homomorphic encryption only option

homomorphic encryption still needs to be implemented in a way that hides the information about the secret addition to the already encrypted data – that's a place for bugs.

it's not a panacea

2
0
Silver badge

Re: Homomorphic encryption only option

I was thinking of homomorphic encryption starting with the keyboard input, and then going from there.

Yeah, there's attack vectors everywhere. We all live with it.

1
1
Anonymous Coward

Exactly how many fails in intel CPU design are necessary before the do a recall?

further one wonders if limitations on release was for the CEO benefit again

zero shame, unworth of trust

6
4

As I have said since Spectre and Meltdown were first made public, I will not be buying ANY new devices for at least 5 years. I figure it will take at least that long for die changes after all the vulnerabilities are discovered.

4
11
Def
Silver badge
Pint

Presumably then you'll be digging up your old 486 from the cupboard, throwing away your mobile phone, not ever going online, and refusing to do business with anyone who uses a computer.

Or maybe you could take off that old tin foil hat, let the wind blow through what's left of your hair, take a few deep breaths, and realise that you're probably no more at risk now than you were six months ago. :)

10
0
Silver badge

shhh.. If they investigate they'll find all the bugs in the 486 as well, and then they'll never come out from under the bed.

5
0
Silver badge

Presumably then you'll be digging up your old 486 from the cupboard

Not necessarily. I read it that he accepts that what he has is flawed, but has no choice in the matter. He'll just not buy a replacement until the flaws are fixed.

On the other hand, waiting for a bug-free <item> is going to be an awfully long wait.

5
0
Devil

FreeBSD (et al?)

The article does not mention FreeBSD. The maintainers seem to on the case. Presumably this will filter through to macOS sometime soon, though Apple has said nothing AFAICT. (Strange for El Reg to miss the opportunity to snipe at this.)

4
1
Silver badge
Black Helicopters

Shares?

Have any Intel C suite people sold any shares recently? I'm sure if there were any sales then they were preplaned

6
1
Silver badge
Boffin

Performance on maths code?

The previous Spectre/meltdown patches didn't really impact performance on maths-intensive code, as this is patching the FPU, I guess this might change things. Does anyone know?

3
3
Silver badge

Re: Performance on maths code?

Just a guess, but I expect that it's a small bit of code that sanitizes the floating point registers on a context switch. Bound to have some performance impact, but probably only a small one.

My second guess is that if a process has not used any floating point registers, the OS makes no attempt to save and restore them, nor to clean them on a return from a context switch (saving space in the stack frame, and not running the code to copy the registers). If this is the case, then any code that does use floating point registers will do a save/restore when a context switch occurs anyway, so there may not be any performance impact at all for code that uses floating point instructions.

4
0
Silver badge
Pint

Re: Performance on maths code?

Thanks for the explanations Peter.

0
0
Silver badge

Re: Performance on maths code?

OS aside, aren't there CPU instructions to store and restore all registers for the purposes of context switching? This takes the requirement away from every OS to somehow know exactly how many registers there are in the CPU that it happens to be running on. i.e. an older or non-updated OS running on newer or slightly different hardware.

1
0
Bronze badge

Re: Performance on maths code?

"OS aside, aren't there CPU instructions to store and restore all registers for the purposes of context switching?"

On the Z80, yes. For processors designed in the '90s or later, no so much. Even if such instructions existed, the space required to save the registers would change whenever new registers are added.

This really is something that the OS has to handle.

1
0
Silver badge

Lever it out

Ah, we yearn for the days when you could lever out your '387 and shove a new, less buggy one in...

14
0
Coat

Re: Lever it out

Weitek?

Showing my age...

1
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing