Return to

Intel FUBAR ... again - Kernel memory leak in nearly every Intel CPU of the last decade (Spectre hits everyone, Meltdown still Intel exclusive)



Security is always a tradeoff with convenience, privacy and performance among many other factors.
Linux was never about security, rather it is about freedom to make it so if you chose to.
If you chose to, you can also make it many other things. :smiley:

And the developers endeavors to imbue it with sane defaults as a starting point.


Several of the High performance CPU’s by Apple as licensed from ARM are very susceptible to spectre attacks as well as plain meltdow, or a new variant of it.

The new unreleased A75 being particularly highlighted as vulnerable to Meltdown.
But honestly meltdown is the problem that’s easy to fix.

Spectre is about a fundamental problem in how we thought about speculative functions in CPU architecture and how they where ultimately implemented.
A substantial chunk of modern CPU’s performance comes from this ‘optimization’.



Dreaming the impossible dream, like asking intel NOT to implement admin credentials on back doors with zero length passwords :smiley:


The thread just hit 1024 messages.

Let us appreciate this moment.


Since Windows Update KB4055532 I noticed some “stuttering” in youtube playback through Vivaldi.
I know for sure that it is caused by the given update as removing it resolves the issue. Am I looking at M$ Spectre fix breaking other things?

Edit: Fix found, H.264ify to the rescue!


So Intel is now strongly encouraging people not to apply the spectre patches due to “Higher than expected” reboots.

We recommend that OEMs, cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions, as they may introduce higher than expected reboots and other unpredictable system behavior. For the full list of platforms, see the Security Center site.


This is a shit show :wink:


Expected nothing less :anguished:


Oh well, luckily it’s only a potential 99% of the market that’s affected. Could be worse.


Have you heard anything further on that? I found the description of that talk and the patrick in question but no further information about speculative execution doing things.

Had to kick out the AMD tag for it. ¯\_(ツ)_/¯


TIL there’s a limit on the amount of tags o_O




Sooo… upgrading all my Kernels on AWS was a bad idea then?


I´m very currious if AMD fixes these vulenerabillities on Ryzen2 cpu’s.


Well, for the first time, Intel is in serious trouble… (as are some of the rest…). /me breaks out the popcorn


If anything it’ll be in microcode only and that is very likely when they are already pushing the fixes for Ryzen (1).

Until it’s fixed in the architecture it’s going to be 5+ years.


Not really. I suspect there are papers waiting to publish on the subject. Big players are probably putting on pressure not to publish.


And Kernel 4.15 was delayed, when was the last time a kernel delayed this long?

This post looks pretty useful BTW:


AMD has currently got 2 concurrent CPU design operations.
From what I know this is roughly how they work:

  1. One team started work on Ryzen.
  2. Once that first CPU design from one team is finalized (taped out),
    a) the other team is already going through initial design of the next architecture forked from the first team.
  3. During this the first team makes improvements to the current architecture for the “refresh” roll-out to hold out until the next re-architecture is ready.
  4. By the time we got Ryzen, Ryzen+ was already in design and testing.
  5. While Ryzen 3 design and node tooling (7nm) was in it’s initial R&D phase.

Someone should make a graph for how that works.

As far as I can glean from my industry rumors, Ryzen 3 is currently in R&D with fixes being mulled over.

It would be foolish to assume Intel isn’t doing something similar. But it will likely be until 2019 (if someone drops a surprise) to get fixed architectures.

EDIT for clarity:

Likely until 2019 to get fixed architecture of any CPU types. So that includes ARM, X86, Power, etc.