Yes, I know that this is the third GT / HH material on this issue.
However, unfortunately, until now I have not met a good Russian-language material - yes, in general, and with English-language ones, which is no secret, the same problem, there were also many journalists who were
raped by scientists - which clearly would have been on the shelves January 3, 2018, and how we will continue to live with it.
I will try to fill the gap, while not getting too deep into the depths of the processors (assembler will not, I'll try to avoid subtle details where they are not needed for understanding), and describing the problem as fully as possible.
')
Thesis: last year they found, and in this they published information about the most serious error in processors for all decades of their existence. To one degree or another,
all the processors currently used in desktops, servers, tablets, smartphones, cars, airplanes, trains, mail, telephones and telegraphs are subject to
it . That is, in general, all processors, except microcontrollers.
Fortunately, they are subject to it in varying degrees. Unfortunately, the most serious blow fell on the most common processors - Intel, and it affected absolutely all manufactured and almost all operated (the only exception is the old Atom, released before 2013) processors of this company.
Until now, the entire information security system on a local computer basically relied on one premise: the central processor is able to guarantee complete isolation of programs running on it from each other, therefore, provided there are no errors in the software, different processes do not have access to each other's data if such access was not explicitly granted.
Remove this premise - and everything else collapses like a house of cards.
Specifically, in the x86 architecture, the protected mode was introduced in 80286 processors and brought to mind in 80386. When working in it, applications instead of direct access to physical memory receive virtual address spaces mapped to physical memory so that the spaces of different applications do not overlap. Control over the address spaces is implemented by the hardware — the MMU, Memory Management Unit — so if the OS correctly allocated memory to it when the new process starts, an attempt to get out of this memory will be immediately stopped by the processor. In addition, memory areas may have different access levels, which are also controlled by the MMU - as a result, the user application will not be able to access the memory occupied by the system kernel or drivers, even if the corresponding addresses are formally accessible to it.
Everything was good, until it became clear that
the processor itself , while working on its internal algorithms, can purposefully ignore the MMU, and the results of the work of these algorithms can be indirectly obtained programmatically.
All modern processors - if we are talking specifically about Intel x86, then these are models from Atom 2013, Pentium Pro and Pentium II - they have the functions of speculative execution of instructions and branch prediction, as well as instruction and data caches.
These algorithms are necessary to ensure high performance of the entire system, provided that all available peripheral devices, including RAM, are much slower than the central processor. In the case when the next instruction that is executed causes the data to wait outside, during the waiting period, instead of idle, the processor starts to execute the code following the instruction, based on expectations of which data is most likely to arrive.
For example:
if (x < array1_size)
{
y = array1[x]
}
,
x array1, . - if', x < array1_size, ,
. ,
.
, ? , . , .
,
x , ?
. , MMU, , -
x, , MMU , — , MMU .
MMU , , — .
« » .
. , , — ( , ). , — , , , ( Pentium 4, , — , , , ).
, — . , . , , — , , , . — .
, :
- N
- MMU
, N.
, — , . ,
N, , ( ) ( ).
: N, , ,
- .
- N, ? . : , , X, Y, — Z, X. , .
, , — , .
, , — - , , .
, , 0...9999, — 10000...20000, . , , (, , 999 ), , 15000.
- 15000. , , 98.
- , 98.
- MMU 15000.
- , 98, .
- 0 ( ), , , ,
- 98 ,
, - - , . ? , , . 15000, , 98.
, , , .
Meltdown (CVE-2017-5754), .
Meltdown?
Intel Core, Intel Xeon, Intel Celeron Pentium Core.
ARM Cortex-A75, , , - , — Qualcomm Snapdragon 845 Kryo 385, Cortex-A75 Cortex-A53 — . , Kryo 385 Meltdown.
Apple, « iOS-» Meltdown. , , - iPhone/iPad ( , - iPhone 4 Cortex-A8), ARM-
iPhone iPad .
Meltdown?
, : — , , — Meltdown AMD ARM Cortex, .
, Meltdown, , , .
, , — , MMU ,
; ( ), .
, ARM Cortex-A15, Cortex-A57 Cortex-A72 — Meltdown, Meltdown «Variant 3», — «Variant 3a»
, , Samsung Exynos 5 Exynos 7 ( Galaxy S5, Galaxy S6, Galaxy Note 3 7), Qualcomm Snapdragon 650, 652, 653, 808 810, Mediatek Helio X20.
, «Variant 3a», «» Meltdown , — , , , .
.
, Meltdown?
, — , « » Intel . MIPS. , , , .
, , -1 MIPS P5600, — MIPS. Meltdown, . - Cortex-A57 , , Meltdown.
, ARM- — , , Samsung Mongoose ( Exynos 8, Galaxy S7, Galaxy S8, Galaxy Note 8), Qualcomm Krait Kryo 2xx, HiSilicon Kirin — .
Meltdown ?
. Meltdown , , .
, , .. , — Meltdown .
, (syscalls) — . , , 1-2 . , PostgreSQL 20 %, .
, TLB, Translation Lookaside Buffer — , , . Intel PCID, , TLB , , . PCID ( , ) , .
, — 3 %, . , .
, , , , . : , Linux , , AMD.
Meltdown?
Meltdown . , , , Meltdown .
, Javascript — . ( 4 Firefox 57.0.4 , Chrome ) JS , , , JS- , , .
, , , Meltdown - , «» . Meltdown , «» - , . , Meltdown , - . , , .
, .
Android, — , , ARM Meltdown , / .
, !
Meltdown. — , .
Meltdown — , , , .
Meltdown ?
— . — , , , .
Meltdown KGB?
, . — - , JTAG, . , , , « ».
Intel , ?
, . -, , Intel , . -, — ( , ARM MIPS; AMD Intel , , , , — , , « , , — »). -, , ARM, , , — , MMU, , , . -, Intel ,
: , , ?
, 9- Intel Core .
. , AMD .
<Intel | AMD | ARM | Microsoft | Google | Amazon | etc.> , ,
: — .
, - , PR- , - « » . , , — .
, Meltdown, , .
, , « » , , . , — , «… , », .
TL:DR
, , , . AMD .
Spectre?
, Spectre .
: Spectre
: