Meltdown an and Sp Spectre vu vuln lnerabili litie ies th the - PDF document

2/21/2018 Meltdown an and Sp Spectre vu vuln lnerabili litie ies th the ch chall llenge is is up! Jos van Eijndhoven Synopsys {040CODERS.nl} Meetup 20180215 Jos van Eijndhoven Profession: IC design tools, Hobby: Processor design and simulation DIY Audio electronics 15 Feb 2018 2 1

2/21/2018 Synopsys • Headquarters in Mountainview, California • About 11.600 employees, offices all over the world • The world’s #1 company in electronic design automation tools and services • At the forefront of Moore’s Law: Approved design technology for 7nm is available today • R&D office at HTC 41 Eindhoven, about 50 engineers Among others, ARC embedded processor developments All opinions in this presentation are strictly my own, they do not reflect the company view. 15 Feb 2018 3 Meltdown and Spectre: news headlines Jan. 3, 2018 • Software proof-of-concept demonstrates that memory barriers, supposedly enforced by the operating system, are crumbled down. • Underlying cause is vulnerability in CPU hardware: not a software bug • Potentially affects server systems, PC desktops, mobile phones, … everything … • Software work-arounds cost performance (10% - 30%?) Technical info on: https://spectreattack.com/ Also used for this presentation... 15 Feb 2018 4 2

2/21/2018 Importance? Nervous stock market… • Meltdown proof-of-concept demonstrates on Intel processors, not on AMD (saved by the bell…) • NASDAQ first half of Jan: Intel loses 17B$ stock value AMD gains 1.7B$ Relative share value over time 15 Feb 2018 5 Further content of this presentation • Type of attack: through the memory barrier • Meltdown versus Spectre: differences • Some CPU background knowledge: pipelining, speculation • Simple standard software loop execution • Meltdown overview • Spectre overview • Counter measures: software and hardware • Conclusion 15 Feb 2018 6 3

2/21/2018 Attacking the memory barrier • Hacker executes his malicious code on the target machine (native binary compiled C, or -maybe- JavaScript) • Thereby gathers memory content which supposedly was inaccessible • Meltdown: OS kernel memory, which includes the physical (DRAM) memory • Spectre: (virtual) memory space of a selected victim process • Safe systems must have layered defense systems: inner circle should stay protected • On home desktops and mobiles, ‘outer layers’ are rather weak. 15 Feb 2018 7 Meltdown • Malicious code reads OS kernel memory (Windows or Linux) • Breaks through ‘kernel protection’ (root privilege) layer • Using ‘speculative execution’ and analyzing CPU cache state • Intel, AMD, ARM, Power, are all reported vulnerable. (First demo worked only on Intel) 15 Feb 2018 8 4

2/21/2018 Spectre • Malicious code peaks in private memory of another process • Malicious code lets other process do activities in its software execution flow which seem impossible • Using ‘speculative execution’ and analyzing CPU cache state • Malicious code and victim must execute on the same CPU core • Other potential options are described, leading to a family of attacks. • Intel, AMD, ARM, Power, are all reported vulnerable 15 Feb 2018 9 Pipeline: traditional RISC design • few stages • Single issue • In-order start and finish Might be OK in the 80’s… 15 Feb 2018 10 5

2/21/2018 Pipeline ARM A15 (2012) • 15-stage integer, 25-stage floating point • Triple issue with Speculation 15 Feb 2018 11 Pipeline Intel Nehalem (2008) • 100+ instructions might be ‘in flight’ • 20-25 stage pipeline Deep pipelines: How to reduce penalty of a branch instruction?? • Prediction of branch target • Speculative execution of post-branch instructions 15 Feb 2018 12 6

2/21/2018 Speculated execution • The CPU ‘guesses’ destination of conditional/computed branch instructions. (“Branch Prediction”, “Branch Target Buffer”) • Most frequent case become fast, pay for overhead on rare cases • Computation of branch target can take 100+ cycles (when a memory-fetch is needed for the condition or for the target address) • Use ‘speculation’ to issue many other instructions in those 100+ cycles. Assume that these are on a correctly predicted path. • If guessed wrongly, there is a high penalty: • the CPU must nullify the results of those speculated instructions • Restart the pipeline with instruction fetch and execution on the correct path 15 Feb 2018 13 Simple loop [1] float A[100] … float sum = 0.0; for (i=0; i <= 100; i++) { sum += A[i]; } BUG: can bad things happen when this is executed? Access 101 th element can cross page boundary into unallocated memory? “ memory fault core dumped ” Or, more likely, code is silently executed and gives bogus numeric result. 15 Feb 2018 14 7

2/21/2018 Simple loop [2] float A[100] … float sum = 0.0; for (i=0; i < 100; i++) { sum += A[i]; If you INTEND to access beyond the If you INTEND to read beyond the } array boundary, your malicious code array boundary, your malicious code LOOKS as if it doesn’t! LOOKS as if it doesn’t! Access to non-existing 101 th element will probably happen!! CPU predicts taken branch back in loop body, and speculates ‘+= A[ 100 ]’ Any raised exception will be nullified for being speculated. 15 Feb 2018 15 Meltdown: exploit speculation For instance: • Malicious code tries to invoke a ‘load’ in kernel memory space • That load is on a non-taken branch, but predicted to be taken (requires subtle programming!) • The load in kernel memory gets executed! • All its results are nullified…  (including the privilege exception) But… can we still detect some side-effect from that speculated load? 15 Feb 2018 16 8

2/21/2018 Meltdown int poi, dummy; unsigned char* array1, array2; .. poi = … if (poi < array1_size) dummy = array2[ array1[poi] * 256]; • For a specific (large) value of poi , array1[poi] fetches a byte of interest • The CPU branch predictor gets trained that the if is usually true • The byte value of array1[poi] causes a cache-line to be loaded for array2 • The cache load occurs also for the mis-predicted out-of- bounds ‘ poi ’! • Measurable side-effect of speculation: measure access time for each i of an array2[ i*256 ] access. 15 Feb 2018 17 Meltdown results • Measuring of cache line access times: • Repeat this procedure for many bytes in a target range: reliably reads kernel memory with a speed of 500KB/sec. • The kernel (virtual) memory also encompasses all machine physical memory Data taken from: “Meltdown”, by Moritz Lipp1, Michael Schwarz1, Daniel Gruss , …, available at: https://spectreattack.com/ 15 Feb 2018 18 9

2/21/2018 Spectre: outline Attacker program is carefully written to match with a victim program: • It has same snippets of code as victim, same ‘branch target’ virtual instruction addresses. • When the attacker executes, it trains the CPU branch predictor and branch target buffer to (speculatively) follow a weird execution path • Then, a process switch to the victim program will let the victim follow the same weird execution path • That path leads to a construct like ‘ array2[ array1[poi] * 256] ’ somewhere in the victim code. • After a process switch back to the attacker, the attacker inspects the CPU cache state. 15 Feb 2018 19 Spectre Proof-of-Concept Attacker process: Victim process: Proof-of-Concept Spectre demo: . . • Exploitable code fragments were Aligned instruction address space . . searched in DLLs. Windows loads . . DLLs on same virtual address over TGT: TGT: different processes. other code; array2[array1[i]*256]; . . • Exchange of branch predictor and . . cache state between Attacker and . . Victim is obtained by executing . . these processes on one shared for ( i .. ) { for ( i .. ) { hyper-threaded core. jump to TGT regular body } } • Victim memory space content could be extracted at about 10KB/sec Attacker trains branch predictor that in some loop the (See https://spectreattack.com/) victim will jump to a totally unrelated code section 15 Feb 2018 20 10

2/21/2018 Virtual machine isolation also compromised Not just ‘plain’ OS process memory isolation is compromised: • Javascript attacker code could successfully break through the sandbox layer, accessing the browser memory. [Spectre publication] • Container isolation (Docker, LXC, OpenVZ) is broken: container applications can still access host kernel data, and thereby the memory space of neighboring containers. [Meltdown publication] Cloud providers are very active with counter measures… (for example: https://aws.amazon.com/security/security-bulletins/AWS-2018-013/) 15 Feb 2018 21 Impact on processor design? • The processor ISA, and its Programmers Reference Manual, have always been the one-and-only abstraction layer to build correct and reliable software on otherwise unknown hardware. • The ‘leakage’ of non-architected processor state violates the designed security layers. • The Meltdown and Spectre authors rightfully ask for a thorough redesign of the SW/HW abstraction layer guarantees. • This might lead to different architectures for ‘secure’ versus ‘fast’ cores. 15 Feb 2018 22 11