# And the hits keep coming: A new Intel bug discovered.



## Maelstorm (Jun 15, 2018)

The good folks over at El Reg have another story which may be of interest.  It seems that Intel keeps AES crypto keys in FPU registers where there is not much access control.

https://www.theregister.co.uk/2018/06/13/intel_lazy_fpu_state_security_flaw/

According to the article, "Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenBSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665)."

I run AMD hardware, but is FreeBSD affected by this?


----------



## Crivens (Jun 15, 2018)

Yes, the charlie foxtrot is not over. This begs the question if this string of isolated little glitches (a.k.a. huge steaming pile of p'tak) is random, accidental or orchestrated? Inquiring minds want to know...


----------



## michael_hackson (Jun 15, 2018)

Like it would be an undercover AMD affiliate who from the beginning fabricated lossy code?


----------



## Crivens (Jun 15, 2018)

No, but other 3 letter things from the alphabet soup officials springs to mind. Ok, 4 letters for the british.


----------



## Sensucht94 (Jun 15, 2018)

Here's the fix https://svnweb.freebsd.org/base?view=revision&revision=335072; Illumos is patched too for those wondering


----------



## Deleted member 30996 (Jun 16, 2018)

Crivens said:


> No, but other 3 letter things from the alphabet soup officials springs to mind.



Ahhh... My 500MHz Pentium III Katmai with PSN, or Processor Serial Number. I still have it in the tower it came in.

But that was waaay back in 1999. I'm sure there's nothing like that to worry about in 2018.


----------



## Maelstorm (Jun 16, 2018)

Sometimes I have to wonder if these flaws weren't deliberate and researchers stumbled on them by accident.  It has been rumored numerous times over the years that Microsoft deliberately introduced bugs into Windows to allow the 3 letter agencies (or 4 letters depending on your country) to be able to gather intelligence on foreign state actors.  One thing that comes to mind is the RNG incident or the Elliptical Curve one from RSA.


----------



## Maxnix (Jun 20, 2018)

OpenBSD disables Hyper-threading: https://www.theregister.co.uk/2018/06/20/openbsd_disables_intels_hyperthreading/


----------



## ralphbsz (Jun 21, 2018)

And now Intel's CEO gets fired.  No, the reasons seem to have nothing to do with bugs or security problems with the processors; it seems he was sleeping with a co-worker.  At least that's the public story.


----------



## michael_hackson (Jun 21, 2018)

Crappy reason to get kicked for really.


----------



## Crivens (Jun 21, 2018)

Adding insult to injury.


----------



## Deleted member 30996 (Jun 21, 2018)

There is an update to FreeBSD 11.1-RELEASE-p11 today to deal with Intel laziness:


```
$ uname -a
FreeBSD relentless 11.1-RELEASE-p11 FreeBSD 11.1-RELEASE-p11 #0: Thu Jun 21 03:46:08 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
```



> II.  Problem Description A subset of Intel processors can allow a local thread to infer data from another thread through a speculative execution side channel when Lazy FPU state restore is used.
> 
> III. Impact Any local thread can potentially read FPU state information from other threads running on the host.  This could include cryptographic keys when the AES-NI CPU feature is present.



https://www.freebsd.org/security/advisories/FreeBSD-SA-18:07.lazyfpu.asc


----------



## ralphbsz (Jun 21, 2018)

michael_hackson said:


> Crappy reason to get kicked for really.


Actually, it makes perfect sense.  The problem isn't the relationship in and of itself.  The problem is that Intel, like most companies, has a policy on romantic relationships.  Which says that you can not do that with someone who reports to you, or whose career you control.  Since by construction nearly everyone at Intel reports to the CEO, that means that the CEO can't get involved with any employee.  Whether it is all very consensual and romantic, or not.  The Intel CEO wasn't fired for the romance; he was fired for violating the policy (and probably for lying about it, perhaps lying by omission).  The "crappy" part is that this implies that CEOs will have to walk further (outside the building) to get laid, while lower-level employees have a statistically more fulfilling love life.  Tough, isn't it?

But I think the reality is that the affair is a convenient pretext.  Intel has not been doing well.  Already a few years ago, the company figured out that it can not sit on the laurels of being the de-facto only server CPU supplier: desktops and laptops are becoming irrelevant, mobile devices are mostly not using Intel gear, it had missed the IoT SoC business, it had let the support chip business atrophy through inattention.  And in the server space, the big customers (Facebook/Google/Amazon, HP/Dell/IBM/Lenovo, and the US government) would make sure that some competition exists, and today AMD is looking like it is becoming serious competition.  While Krzanich had figured that out, and made that his long-term strategy, he wasn't able to deliver on it tactically.  Like many CEOs (in particular SiliconValley types), he was pretty good on vision, but bad on execution and leadership, and his oversized ego didn't allow him to let his staff (like a COO or president) share the execution part.  So the "get away from only server CPUs" strategy remained just foilware, while the server CPU business stumbled due to security problems.  He fundamentally had to go anyway.


----------



## michael_hackson (Jun 21, 2018)

I knew that part, I didn't consider that it was due to a policy break. That is a better matter. I can see both good and bad in having a policy "not to sleep with co-workers" but as you say it is as a chess move to fire the CEO.


----------



## Deleted member 30996 (Jun 21, 2018)

michael_hackson said:


> I knew that part, I didn't consider that it was due to a policy break. That is a better matter. I can see both good and bad in having a policy "not to sleep with co-workers" but as you say it is as a chess move to fire the CEO.



I met the girl who ended up being my 2nd wife as a co-worker. We started dating, moved in together, then I was promoted to Manager where we worked.

Since the relationship had begun before my promotion it was condoned by upper Management. It would not have been if I had already been Manager .


----------



## Crivens (Jun 21, 2018)

Not to forget: fire him for sinking the ship and then you will meet some angry stock holders.


----------



## Maelstorm (Jun 23, 2018)

I don't own Intel stock, but it sounds to me like the relationship was an excuse to remove the CEO.  I suspect that the reason goes beyond the security flaws.  Company performance sounds like a major issue, and then the stock dump right before the Meltdown/Spectre bug disclosures which looks like insider trading.

That was overt.  So the question that I asked myself was "Can you be even more suspicious?"


----------



## Crivens (Jun 23, 2018)

Well, he could have tried to buy citizenship in  place that has no extradition relations with the rest of the world. Or there could have been the Atta-maneuver (passport +written confession found in a rented car at the airport lot). Plenty of ways to be more than suspicious.


----------



## ralphbsz (Jun 28, 2018)

We haven't heard any security disasters from Intel in several weeks.  What's wrong?  I don't believe for a second that the flow of vulnerabilities has stopped; I think it's rather that the news is slowing down.


----------



## Crivens (Jun 28, 2018)

Or it is a case of dog bites man. Oh, _another_ security slip up. *yawn*

Or the currently emerging stuff is wrapped in destroy-before-reading tape because it is what those nice chaps near DC had the pleasure to suggest. *wink wink nudge nudge*
Yes, sounds a bit tinfoil hat, but if true I would be completely unsurprised.


----------



## gofer_touch (Jun 28, 2018)

AMD has an extraordinary opportunity if it doesn't mess this up. But ultimately x86 needs to retire.


----------



## ralphbsz (Jul 13, 2018)

Strangely, nobody has mentioned the new vulnerabilities that came out this week: Discussion in The Register, and more details in Ars Technica.  The Register article also talks about the fact that Intel will change the way they release information about such vulnerabilities.  I have no idea whether these vulnerabilities are being exploited, could even be exploited in practice, and how far countermeasures have progressed.


----------



## Phishfry (Jul 13, 2018)

gofer_touch said:


> AMD has an extraordinary opportunity if it doesn't mess this up. But ultimately x86 needs to retire.


Well that's the first I have heard of that sediment.
Quite surprising as well seeing how Arm is affected by these speculative execution bugs.

I have an Atom D525 and it does not use speculative execution. So what is wrong with the x86 instruction set. Its all these goofy add-ons that is causing all these problems. Not the instruction set.
Maybe its time to realize that speculative execution is BAD and we revert back to the days where we didn't have weekly major CPU bugs.
Time to admit your speed tricks didn't work.


----------



## ralphbsz (Jul 14, 2018)

To begin with: As far as I know, all CPU vendors had problems in this area.  That includes AMD, ARM, IBM Power.  Intel's problems are the worst, but I can't tell whether that's just an effect of more attention in the press, and more security researchers going for a bigger target, or whether Intel really has a lower quality standard in this area.  Intel also has the most open ecosystem, with the largest variety of systems (hardware) and software (operating systems...) running on their hardware, so the biggest problem patching the vulnerabilities.

Sure, AMD can try to turn this into an opportunity: their chops have gotten less bad press.  But I don't know whether their chips are any less vulnerable; they might just exist more in the shadows.

Next thing: These problems are actually extremely old.  One interesting thing is that the original papers about the Spectre/Meltdown bug quoted an article written in the late 60s or early 70s!  It's just that until recently (the last 10-15 years) there hasn't been enough of a computer ecosystem to make computer crime profitable.  In theory, it might have been possible to have a similar bug on the IBM mainframe I'll mention in a moment below, but in 1964 several things were different: (a) computers were only used by a very small set of people.  (b) Those people were inherently trustworthy, otherwise one wouldn't have allowed them to access such a precious and expensive resource.  (c) There was very little software around, and all software that existed was inspected in source form (IBM used to distribute the OS source to its customers, in the form of microfilm, since customers were expected to find and debug problems at the source level).  Matter-of-fact, I think the IBM mainframes had not access control and no form of permission checking (except for the user/kernel separation) until the RACF product shipped in the late 1970s.

Finally: Speculative execution is simply necessary.  You can't just wish it away because it happens to be inconvenient.  Today, CPUs are not going faster: Clock speeds have improved from 33 MHz in 1994 to 1GHz in 2000 to 3GHz in 2005, but they have since stalled; the fastest CPUs I know of run at about 4.7 or 5 GHz today (and those are not generally available to the public).  The CPUs that consumers can buy, and that are used in data centers and in the cloud, are all about 3GHz.  To get more speed (Moore's law isn't dead yet, so you do get more gates per acre, just not more clock cycles per second), we need to do more at the same time.  But putting more cores on each CPU is running into limits too, mostly that much software is hard to parallelize (either intrinsically hard, or we haven't done it yet).  So to get more speed, we need to execute multiple instructions at the same time.  This started in the mid 1960s, with the IBM 360/91 (which did out-of order, parallel, and pipelined execution, some if which it stole from the ill-fated IBM Stretch/Harvest machine).  By the way, I've met people who worked on Stretch and the /91 (they were admittedly very old, about 15 years ago).  Since then, all "serious" computers (not toy microprocessors) have had to work this way, to get to the desired speed.  The real issue is that chip designers never thought that the information leakage from speculative execution through cache effects was significant enough to be considered a problem worth thinking about.  And for better or worse, today it is considered a problem.  It will take a few processor generations to seal those leaks.


----------



## Crivens (Jul 20, 2018)

And another one...


----------

