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

2/21/2018 1

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

Profession: IC design tools, Hobby: Processor design and simulation DIY Audio electronics

Jos van Eijndhoven

15 Feb 2018 2

2/21/2018 2

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%?)

15 Feb 2018 4

Technical info on: https://spectreattack.com/ Also used for this presentation...

2/21/2018 3

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

• ver 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

2/21/2018 4

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

2/21/2018 5

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

2/21/2018 6

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

2/21/2018 7

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]

BUG: can bad things happen when this is executed? Access 101th element can cross page boundary into unallocated memory? “memory fault core dumped” Or, more likely, code is silently executed and gives bogus numeric result.

float A[100] … float sum = 0.0; for (i=0; i <= 100; i++) { sum += A[i]; }

15 Feb 2018 14

2/21/2018 8

Simple loop [2]

Access to non-existing 101th 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.

float A[100] … float sum = 0.0; for (i=0; i < 100; i++) { sum += A[i]; }

15 Feb 2018 15

If you INTEND to read beyond the array boundary, your malicious code LOOKS as if it doesn’t! If you INTEND to access beyond the array boundary, your malicious code LOOKS as if it doesn’t!

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

2/21/2018 9

Meltdown

• 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

int poi, dummy; unsigned char* array1, array2; .. poi = … if (poi < array1_size) dummy = array2[ array1[poi] * 256];

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

2/21/2018 10

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

Proof-of-Concept Spectre demo:

• Exploitable code fragments were

searched in DLLs. Windows loads DLLs on same virtual address over different processes.

• Exchange of branch predictor and

cache state between Attacker and Victim is obtained by executing these processes on one shared hyper-threaded core.

• Victim memory space content could

be extracted at about 10KB/sec (See https://spectreattack.com/)

15 Feb 2018 20 . . . TGT: array2[array1[i]*256]; . . . . for ( i .. ) { regular body }

Victim process:

. . . TGT:

• ther code;

. . . . for ( i .. ) { jump to TGT }

Attacker process:

Aligned instruction address space Attacker trains branch predictor that in some loop the victim will jump to a totally unrelated code section

2/21/2018 11

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

2/21/2018 12

Software counter measures?

Software workarounds for a hardware problem?

• 1. Preventive repairs in OS and library code:
• Scan code for occurences of ‘if (…) array[ array[ ] ]’
• Modify such code that even predication cannot do out-of-bounds access

(by inserting ‘memory barrier’ operations between the array accesses. Such operations prevent speculation beyond non-completed memory accesses.)

• Clear the ‘Branch Target Buffer’ at context switches
• 2. Apply the known OS ‘Kernel Page Table Isolation’ (Kaiser) update
• This removes the mapping of kernel memory space from the user process
• Unfortunately, this requires that the CPU clears and reloads its TLB on each

system call entry and exit. This costs many hundreds of cycles penalty on each system call.

15 Feb 2018 23

Nervously apply kernel code updates in a hurry?

From Linus Torvalds <> Date Sun, 21 Jan 2018 13:35:59 -0800 … BULLSHIT. Have you _looked_ at the patches you are talking about? You should have - several of them bear your name. … So somebody isn't telling the truth here. Somebody is pushing complete garbage for unclear reasons. Sorry for having to point that out. If this was about flushing the BTB at actual context switches between different users, I'd believe you. But that's not at all what the patches do. As it is, the patches are COMPLETE AND UTTER GARBAGE. They do literally insane things. They do things that do not make

• sense. That makes all your arguments questionable and suspicious. The

patches do things that are not sane. WHAT THE F*CK IS GOING ON? I think we need something better than this garbage.

15 Feb 2018 24

2/21/2018 13

Intel hurries into action

• Updates to CPU microcode,

now being distributed, affect actual CPU behavior

• Redesign of CPU hardware?

CEO Brian Krzanich, Jan 8: We’re working to incorporate silicon-based changes to future products that will directly address the Spectre and Meltdown threats in hardware, and those products will begin appearing later this year. Intel’s share value raises to highest price in 18 years. What Meltdown?

15 Feb 2018 25

ARM

• Cortex A7 … A75 are/were vulnerable, and Cortex R7, R8
• Arm published ‘Trusted Firmware’ updates
• To be applied in combination with OS updates and/or compiler updates
• “All future Arm Cortex processors will be resilient to this style of attack or

allow mitigation through kernel patches.” https://developer.arm.com/support/security-update

15 Feb 2018 26

2/21/2018 14

Google hurries into action

• Google claims to have patched Android against Spectre and Meltdown
• Android (8.1) January security updates are on its Pixel and Nexus devices

15 Feb 2018 27

Performance impact of KPTI against Meltdown

• Webhosting & PHP workload on Ubuntu servers
• “we will migrate all Web Hosting servers to more powerful ones”
• Good blog from: Edouard Bonlieu, online.net and scaleway.com

15 Feb 2018 28

2/21/2018 15

Status today, closely around myself…

• Synopsys has updated all company servers and laptops
• Synopsys’ ARC processors are not susceptible

They are deeply pipelined, but have a stricter pipeline for energy efficiency

• My mobile phone, a 2jr old Nexus, received an automatic update

NOT updated for Meltdown/Spectre are:

• An ancient home Win7 desktop machine
• My Raspberry Pi (quad A7), my home network media player (quad

A53), my home router (dual A9)

• My wife’s mobile phone

29 15 Feb 2018

Conclusion

• Publication of Meltdown and Spectre was world news, people got really

nervous, also in the financial world

• Meltdown can be protected against with a known KPTI kernel update.

That makes system calls notably slower. Improved hardware is promised by the end of 2018.

• Spectre is a range of options for inter-process leakage. Software

updates are needed for shared-library code, not just OS. This type of attack is very difficult to do. New leakage exploits might be discovered...

• Intel works hard to (re-)establish its brand name as best in class.

Upgradeable microcode comes to rescue.

• A large number of home and mobile devices will remain vulnerable

15 Feb 2018 30