Memory management bug in Intel CPUs threatens massive performance hits.

[NivagSwerdna]

Are you people crazy? It affects Virtual machines that can read from each other. It only affects you, if you are running more than 1 virtual machines on your PC server, and one would run malicious code, specifically designed to attack the other virtual machine. This is only an issue for cloud providers.
99.9999% of PC users are not affected.

Nope.  The ASLR leak has been demonstrated from Javascript so any code running from a web page you have visited can exploit MMU timing to resolve the address of kernel mode data structures and subsequently it just needs an exploit for buffer overflow etc or rewriting the stack return address and you are pwned. But ignorance is bliss.

https://www.vusec.net/projects/anc/

[mikeselectricstuff]

Is this even an issue for standalone PCs ?

[dr.diesel]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

[Monkeh]

Is this even an issue for standalone PCs ?

Yes - your applications aren't meant to be able to find the kernel, let alone read it.

[Ampera]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

This is rather interesting. I read that this only affects Intel chips, yet Intel is stating it affects AMD and Acorn chips as well.

[PA0PBZ]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Look what they did there:

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.

[Mr. Scram]

This is rather interesting. I read that this only affects Intel chips, yet Intel is stating it affects AMD and Acorn chips as well.

They don't seem to be actually saying this. Just conveniently mentioning it together.

Obviously, Intel is in full damage control mode right now. This might be the moment they lose the crown to AMD, especially considering they've taken a few hits in the recent past. There is no way they wouldn't downplay the issue on their side and attempt to shift the focus elsewhere.

Regardless of which party you like more, Intel has shown to be very shrewd and ruthless when it comes to marketing again and again.

[langwadt]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

This is rather interesting. I read that this only affects Intel chips, yet Intel is stating it affects AMD and Acorn chips as well.

maybe the Intel guys fixing the bug is overly cautious, or they just don't want AMD to have an advantage, but ...

https://lkml.org/lkml/2017/12/27/2

[Ampera]

Darn me and my inability to read.

Yeah, this does seem like Intel is starting to freak out. Good.

AMD should take the x86 helm and keep it. Intel has been being a dick about things for way too long. Before now there just wasn't another alternative.

[Cerebus]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

This is rather interesting. I read that this only affects Intel chips, yet Intel is stating it affects AMD and Acorn chips as well.

To quote Mandy Rice-Davies "Well, 'e would [say that], wouldn't he?".

There is no currently extant evidence that this problem affects anyone else, just Intel.

Although the "official" explanation isn't out yet what the problem appears to be is: On Intel's chips that support speculative execution, tests for whether a privilege violation has taken place are delayed until retirement of speculative executions. Thus, say, a speculative read of kernel space by a user process can actually retrieve results from kernel space before being 'caught' by a privilege violation exception rather than being prevented from making the access in the first place. Quite how one exploits that to grab the accessed information before the exception takes place is the tricky bit, but the process of catching the violation after is has actually taken place, as opposed to preventing the violation taking place, is clearly flawed by design.

[Ampera]

I thought speculative execution was a P5 feature, unless I am thinking of something else.

If that is the case I don't own an Intel chip without it.

[MT]

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

And those who have more then a decade old CPU and not religious are safe? This time we can actually see and poke god in his/her eye!

[JoeO]

Intel's PR response:

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

This is rather interesting. I read that this only affects Intel chips, yet Intel is stating it affects AMD and Acorn chips as well.

Wow, at least they didn't mention the ATMEGAs. 

[bd139]

Some comments and anger.

----

Intel quote "Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers."

Fucking bollocks. https://danluu.com/cpu-bugs/ - Intel have a very bad security record when it comes to microcode, Intel ME, horrible Atom bugs, FDIV etc. That's just basically someone saying "hey chaps Chernobyl wasn't all that bad! We've still got the best nuclear power plant in the world. Can you poke the cameras the other way please, away from the blue glow in the windows from the Cherenkov radiation"

Also going back to 2007 (!) Theo de Raadt on x86: https://marc.info/?l=openbsd-misc&m=119318909016582

IA32 and x86-64 are piles of rancid shit. There are people who have left Intel now shitposting about how bad their design verification was and the management team pushing "velocity" because they got urinated upon in the mobile sector

----

Intel quote 2: "Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively."

Fuck them in the ass. What a bunch of spin doctoring cunts. They have literally zero honour dragging AMD and ARM into this. I would be fucking pissed. This could hurt stock and reputation for a potential non issue. That's just evil.

----

Are you people crazy? It affects Virtual machines that can read from each other. It only affects you, if you are running more than 1 virtual machines on your PC server, and one would run malicious code, specifically designed to attack the other virtual machine. This is only an issue for cloud providers.
99.9999% of PC users are not affected.

As alluded to in a previous post, this is a privilege escalation bug which allows kernel memory to be read by user processes. There is a proof of concept already demonstrated which is enough to pull vectors out of kernel RAM. This entirely defeats ASLR and entirely deletes the privsep implementation of x86-64. Virtualization via VT-x is another layer of abstraction above this and we don't know exactly how that is affected yet. The big worry with this and me is VMCS shadowing. I am almost 100% sure this is a turd which is going to fall under this. Maybe not for a few months yet. If you look at how the EPT / TLB implementation is, adding IOMMU and virtualization support, it's difficult to consolidate exactly how the hell it all fits together. It's that complicated that it's like the film "the Cube". I don't think any engineering team be it forward engineering or design validation can actually rationally test the whole thing.

Ugh this is a nightmare just unfolding.

[Decoman]

I think it is fair to assume that every Intel cpu has "NSA inside" with Intel's management engine. :|

Personally, I think owning a computer these days is just a horror show. No privacy, bad security, bad software and what I like to think of as being the police state (what people call 'surveillance state').

Afaik, any catastrophic security flaw involving the management engine has been expected for quite some time now.

[tszaboo]

Are you people crazy? It affects Virtual machines that can read from each other. It only affects you, if you are running more than 1 virtual machines on your PC server, and one would run malicious code, specifically designed to attack the other virtual machine. This is only an issue for cloud providers.
99.9999% of PC users are not affected.

.. no, no, that isn't it.

This is an issue which can potentially allow an unprivileged user-mode process to read kernel memory.

Then either they have more than 1 issue at the same time, or IDK what is going on.
https://www.techpowerup.com/240174/intel-secretly-firefighting-a-major-cpu-bug-affecting-datacenters

The vulnerability lets users of a virtual machine (VM) access data of another VM on the same physical machine (a memory leak).

Anyway, others write that all x86 is affected, even ARM (sounds bullshit, but possible). We see it in about a week, until that it is all a speculation.

[bd139]

Then either they have more than 1 issue at the same time, or IDK what is going on.

Some people are responding to Xen hypervisor embargoed XSA-253: https://xenbits.xen.org/xsa/ ...

I am currently hating that dealing with all this shit is my hat. I should have migrated to China in the late 1990s and done EE there

Also Amazon have started randomly rebooting AWS instances now, probably applying patches. Fun fun fun for me over the next few days.

[Refrigerator]

These look like extra juicy news. I'm looking forward to seeing how this unrolls.   

[Macbeth]

maybe the Intel guys fixing the bug is overly cautious, or they just don't want AMD to have an advantage, but ...

https://lkml.org/lkml/2017/12/27/2

PMSL 

Code: [Select]

if (c->x86_vendor != X86_VENDOR_AMD)
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
Enough said. But shit all my CPU's are Intel right now...

[Ampera]

In essence, it's half the people in the industry collectively shitting their pants and the other half waiting to see how bad it stinks.

maybe the Intel guys fixing the bug is overly cautious, or they just don't want AMD to have an advantage, but ...

https://lkml.org/lkml/2017/12/27/2

PMSL 

Code: [Select]

if (c->x86_vendor != X86_VENDOR_AMD)
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
Enough said. But shit all my CPU's are Intel right now...

Lol.

I own one Intel CPU that's affected, my main i7-4790k. All others are either AMD or too old to be affected (Pentium 3, Pentium 4, Pentium Pro, basically, I'm all about the Pentiums).

CPUs get more annoying by the day. It's a battle with no victor between people who wish to break down computers for profit and people who want to keep people secure. What it comes down to is people don't care about security, they care about a fast, simple, speedy device, with little else.

[bd139]

That AMD patch enabled this to happen:

[amyk]

The link posted before, https://twitter.com/brainsmoke/status/948561799875502080 , is currently the only public demonstration I know, but you can see how it works in general --- if an address has been recently accessed, then it will be in the cache so it will be faster to access than one which hasn't. My guess is that the CPU will do a speculative access and cache the data even if the access turns out to be invalid, altering the timing thereafter.

Intel's response that it's "operating as designed" is because no one ever thought this would be a real problem, and so far it remains to be seen how much of one it really is.

Is this even an issue for standalone PCs ?

Yes - your applications aren't meant to be able to find the kernel, let alone read it.

It depends on what applications you run, and whether you trust them. Obviously if you trust everything running on the CPU, e.g. like in an embedded system, this has little relevance. If you're a cloud provider or user with hardware being shared by dozens if not more users who don't trust each other at all, then it's a big problem.

This also theoretically includes things like Javascript running in browsers, so you need to be careful of any untrusted code running on your system, but if you don't have any, the situation hasn't changed.

It will be interesting to see what happens...

[station240]

Speculation that Intel will have to repeat the FDIV bug offer of replacement CPUs.
I can't imagine large data center companies like Amazon not demanding replacement silicon, given how huge the CPU hit is for the workaround for this bug.

Given how much shit Apple got in for slowing down CPUs in iPhones with weak batteries, I cannot imagine consumers being too pleased with Intel either.

[bd139]

If they offered replacements it would destroy them entirely. Watch the corporate wriggling over the next few months.

[Mr. Scram]

Speculation that Intel will have to repeat the FDIV bug offer of replacement CPUs.
I can't imagine large data center companies like Amazon not demanding replacement silicon, given how huge the CPU hit is for the workaround for this bug.

Given how much shit Apple got in for slowing down CPUs in iPhones with weak batteries, I cannot imagine consumers being too pleased with Intel either.

Intel never guaranteed performance and the chips still work, so I guess they're off the hook there. A problem with Apple was that they hid it and looked like they were slowing down old hardware to sell new hardware. Intel isn't hiding the problem and not hiding the performance hit.