News Serious security flaw in Intel processors

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Y2K was mostly panic.

Admin edit: Fair warning, the page behind this link contains an acronym which spells out a rude word.

This one seems to be for real, though.

A serious security flaw in the intel cpu architecture, going back a decade. The only possible countermeasures are developing a new chip (and then for everyone to go get that, obviously), or patching the flaw on the OS level, which Microsoft, Linux and Apple are currently in the process of doing.
Trouble is, doing a CPU job with software is terribly slow... Exact benchmarks on the performance impact of these OS level fixes are not yet available, the linked article puts it anywhere between 5% and 30%. So anywhere from "very significant" to "utterly disastrous".
Fun times ahead...
 
Last edited by a moderator:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,870
Points
188
Website
github.com
A faster computer... just what I needed...
jiFfM.jpg
 

statickid

CatDog from Deimos
Donator
Joined
Nov 23, 2008
Messages
1,683
Reaction score
4
Points
38
It's almost like they put an open exhaust port that leads directly to the core. :hmm:
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Not really, its rather that the current OS had been optimized for the Intel implementation and now have to find a workaround quick. Future implementations will be faster again.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
Oh hell. Now we're forced to choose between security and speed. It shouldn't be a choice, but for many people it will be...

On a related note, does this open Intel up to a class action lawsuit? I know recently nVidia was sued because of slower RAM:

https://arstechnica.com/tech-policy...0-customers-in-class-action-lawsuit-over-ram/

The performance hit will be workload dependent, if you're not CPU bound, or close enough to being CPU bound that this pushes you over the edge, you won't see any impact, so gaming, which tends to be GPU bound, probably won't see much of a performance hit.

As to a lawsuit, in the NVidia case the wording of the advertisements implied better performance than the card was actually designed for, and it was working as designed. In this case, the product isn't working as designed. The strongest case for a lawsuit would be negligence.

---------- Post added at 21:23 ---------- Previous post was at 20:54 ----------

Not really, its rather that the current OS had been optimized for the Intel implementation and now have to find a workaround quick. Future implementations will be faster again.

The workaround isn't slow because it's a quick emergency fix, it's slow because the nature of the fault is such that it can only be fixed in software by doing things that are inherently slow. The old, fast way of doing things will still work on other manufacturers' processors and on new Intel designs with the bug fixed, but "we :censored: up and it's not fixable in microcode, please buy our newest product in order to have a CPU that isn't defective" isn't a great marketing pitch, so expect Intel to see a huge drop in sales this year. If it were just one model or series of CPUs, I'd expect they'd issue a recall with free replacements, but what I've seen so far indicates that the bug affects all, or at least a significant portion, of the CPUs they've produced in the past decade, so a recall would utterly break the company.

Frankly, I'd say the odds are 50/50 that Intel doesn't live to see 2019.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Frankly, I'd say the odds are 50/50 that Intel doesn't live to see 2019.
They've weathered worse, like the dot com bubble burst of 2000. Then the price per share dropped from an all-time high of $73.93/share to $28.81/share in just six months. It looked more grim back in March 2009 when the stock price was at $12.41/share. Latest notation has the share price at $45.26/share.

Source: https://www.google.se/search?q=intel+stock
 

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,580
Reaction score
2
Points
0
And suddenly AMD processors get a massive (relative) jump in gaming performance... they were playing the long game all along! :lol:
 

Apollon

New member
Joined
Jun 26, 2011
Messages
56
Reaction score
0
Points
0
Frankly, I'd say the odds are 50/50 that Intel doesn't live to see 2019.

According to a Reuters article, AMD is also affected by a similar flaw.
AMD chips are also affected by variants of a security flaw also discovered in Intel chips, a person familiar with the matter told Reuters. The earlier report in The Register suggested that AMD chips were not affected, which appeared to boost shares.

I'd say that if Intel senses a long-term loss because of this revelation, they'll make sure they let everyone know that AMD was/is also affected.
 

Artlav

Aperiodic traveller
Addon Developer
Beta Tester
Joined
Jan 7, 2008
Messages
5,789
Reaction score
778
Points
203
Location
Earth
Website
orbides.org
Preferred Pronouns
she/her
This looks like the whole thing with technical details: https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

TL;DR:
-It's not that bad or different from older attacks, and is fairly fundamental to modern CPUs.
-AMD is affected as well, to a lesser degree.
-The thing is not an exploit by itself, but rather an enabler for a class of exploits.
-To stop the whole class you need to handle the userspace/kernel memory separation properly rather than efficiently, which happens to be about 5% slower on average (peak of 30% in synthetic I/O tests).
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
TL;DR:
-AMD is affected as well, to a lesser degree.

I'm curious to find out the exact details about that, because AMD has explicitly stated that AMD CPUs are not vulnerable to those types of attacks:

Tom Lendacky <[email protected]> said:
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

That statement was part of this Linux kernel commit comment to arch/x86/kernel/cpu/common.c:

Tom Lendacky <[email protected]> said:
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
 

tl8

Addon Developer
Addon Developer
Tutorial Publisher
Joined
Oct 16, 2007
Messages
3,645
Reaction score
25
Points
88
Location
Gold Coast QLD
There are 2 flaws.

Meltdown is the Intel specific one with the performance hit.

Spectre is a more complicated flaw with no easy fix. All processor types are affected.

Note, the performance hit is only valid for CPU constrained programs.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,017
Reaction score
1,254
Points
188
Location
Dallas, TX
Taking the Reuters and Project Zero links together, there appears to be one or two significant Intel-specific flaws, and then one or two more general attacks that are less severe but more general in their applicability to different processors (Reuters mentions two vulnerabilities, Project Zero mentions three, and I'm not sure how the vulnerabilities in each article map to each other). The Intel-specific flaw seems to be severe enough that Linux kernel devs are patching the kernel to unmap all but a stub of itself before returning to user-mode code on Intel processors, and only Intel processors, and to only map the full kernel when an application makes a system call.
 

Michkov

Member
Joined
Apr 4, 2008
Messages
130
Reaction score
16
Points
18
Can I get an ELI10 on what's wrong with the CPU architecture?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Can I get an ELI10 on what's wrong with the CPU architecture?

From what I got here for Meltdown, the exploit is quite easy once you know what to do: http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.html

The problem is mostly the speculative execution in modern CPU pipelining, together with memory page caching.

Speculative execution is a process where the CPU predicts what instructions should be fed into the pipeline next, in order to have the pipeline filled as good as possible.
Modern CPUs have pipelines, because one instruction actually consists of many micro-instructions to be executed in order (e.g. read from memory, then add a constant, then write to memory). I.e. while your first instruction (e.g. "add 2 to memory position A") is in the "add" pipeline stage, the next instruction (e.g. "sub 5 from memory position B") can already be in the "read" pipeline stage.
Naturally, the pipelining becomes complicated if you have branches or jumps. Then this speculative execution kicks in, where the CPU decides which code path it will follow next. If due to an instruction already in the pipeline, the decision later comes out as wrong, the CPU simply drops the pipeline results and starts over fresh.

And this last part is what is getting exploited. While the Intel CPUs apparently drop the pipeline results just fine, they do not revert all the other results of it, especially not the memory page caching. Page caching is where the CPU loads a portion of the huge, but slow, main memory into the smaller, but faster, cache.

So if you now write a program that in its first instruction loads the data of a restricted kernel memory (which will fail due to the virtual memory protection mechanism that still work fine in the CPU), and in the next instructions cleverly write to one of your own memory pages, you can determine the value of the kernel memory cell by means of what memory page got cached. Of course you will never see the value directly, because the first instruction fails, but because the 2 following instructions where already running in the pipeline before the first failed, the resulting page caching already took place.

Of course that's only the simple take-away from it, because many more details contributed to the problem.
 

MeDiCS

Donator
Donator
Joined
Sep 22, 2008
Messages
602
Reaction score
2
Points
0
Link with papers for both attacks.

What Face described is the Meltdown attack, which only works on Intel processors and can be patched against with performance drops on some workloads (most people shouldn't be too much affected by this according to the few benchmarks I've seen, but ofc the news love a big drama). The second (Spectre) is harder to exploit but can be used against pretty much every modern processor and can only be solved with new CPUs. It's not the end of the world but it's pretty bad.

---------- Post added at 08:09 AM ---------- Previous post was at 07:50 AM ----------

ELI5 (I'm still reading the papers): there are two attacks: Meltdown and Spectre. Both of them rely on the fact that modern processors execute code before it knows if it should or not, for performance reasons (Speculative Execution). That is usually not a problem because if, in the end, that piece of code shouldn't have been executed, the CPU simply discards all the work it did like nothing happened. However, that fact is that code did run and just from that fact, the CPU's cache is modified because it works independently from the part that deals with speculative execution.

The attacks goes like this:

1. Force the CPU to speculatively execute a piece of code that reads something it wouldn't normally

2. The CPU rolls back all the effects of that invalid operation, as it should

3. Read that piece of data that is now in the cache where it shouldn't

The difference between Meltdown and Spectre is that Meltdown can be exploited with simple code to read protected data from the OS, while Spectre must manipulate the OS (or another program) in a specific way to steal the data.
 
Top