[PPT] - Using Hardware Performance Events for Instruction-Level Monitoring PowerPoint Presentation

SLIDE 1

Using Hardware Performance Events for Instruction-Level Monitoring on the x86 Architecture

Sebastian Vogl and Claudia Eckert

{vogls,eckertc}@in.tum.de

Chair for IT Security Technische Universität München Munich, Germany

10.04.2012

S. Vogl and C. Eckert (TUM)

10.04.2012 1 / 42

SLIDE 2

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 2 / 42

SLIDE 3

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 3 / 42

SLIDE 4

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

My Research

Make use of full hardware virtualization to detect malware infections and exploitation attempts.

S. Vogl and C. Eckert (TUM)

10.04.2012 4 / 42

SLIDE 5

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

DATA

Stack vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

S. Vogl and C. Eckert (TUM)

10.04.2012 5 / 42

SLIDE 6

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vu

vuln lner erab able le>

40070c: mov 0x0, %EAX

DATA Stack 0x40070c (RET) vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

S. Vogl and C. Eckert (TUM)

10.04.2012 6 / 42

SLIDE 7

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

DATA Stack 0x40070c (RET) RBP vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

S. Vogl and C. Eckert (TUM)

10.04.2012 7 / 42

SLIDE 8

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

DATA Stack 0x40070c (RET) RBP vulnerable

400584: push %rbp 400585: mov %rsp,% ,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

S. Vogl and C. Eckert (TUM)

10.04.2012 8 / 42

SLIDE 9

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

DATA Stack 0x40070c (RET) RBP BUFFER vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

S. Vogl and C. Eckert (TUM)

10.04.2012 9 / 42

SLIDE 10

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

DATA Stack DATA (EBP) DATA

<vulnerable code>

* /bin/bash exit system

S. Vogl and C. Eckert (TUM)

10.04.2012 10 / 42

SLIDE 11

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: : leave 4006b3: ret

DATA Stack DATA (EBP)

<vulnerable code>

* /bin/bash exit system

S. Vogl and C. Eckert (TUM)

10.04.2012 11 / 42

SLIDE 12

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

DATA Stack

<vulnerable code>

* /bin/bash exit system system

S. Vogl and C. Eckert (TUM)

10.04.2012 12 / 42

SLIDE 13

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

One possible Solution

Make use of a Shadow Stack to verify the target of return instructions.

S. Vogl and C. Eckert (TUM)

10.04.2012 13 / 42

SLIDE 14

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vulnerable> 40070c: mov 0x0, %EAX

DATA

Stack vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

Shadow Stack

S. Vogl and C. Eckert (TUM)

10.04.2012 14 / 42

SLIDE 15

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vu

vuln lner erab able le>

40070c: mov 0x0, %EAX

DATA Stack 0x40070c (RET) vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

<vulnerable code>

Shadow Stack 0x40070c (RET)

S. Vogl and C. Eckert (TUM)

10.04.2012 15 / 42

SLIDE 16

Motivation

▸ Why Instructions-Level Monitoring (ILM) ? main

400707: call 400584 <vu

vuln lner erab able le>

40070c: mov 0x0, %EAX

vulnerable

400584: push %rbp 400585: mov %rsp,%rbp 400588: sub $0x20,%rsp 4006b2: leave 4006b3: ret

DATA Stack

<vulnerable code>

* /bin/bash exit system system Shadow Stack 0x40070c (RET) EIP: system

S. Vogl and C. Eckert (TUM)

10.04.2012 16 / 42

SLIDE 17

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

Observation

A Shadow Stack for return addresses can be implemented on the hypervisor-level by only trapping call and return instructions.

S. Vogl and C. Eckert (TUM)

10.04.2012 17 / 42

SLIDE 18

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

Observation

A Shadow Stack for return addresses can be implemented on the hypervisor-level by only trapping call and return instructions.

ILM Requirements

1

Based on full hardware virtualization

S. Vogl and C. Eckert (TUM)

10.04.2012 17 / 42

SLIDE 19

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

Observation

A Shadow Stack for return addresses can be implemented on the hypervisor-level by only trapping call and return instructions.

ILM Requirements

1

Based on full hardware virtualization

2

Secure

S. Vogl and C. Eckert (TUM)

10.04.2012 17 / 42

SLIDE 20

Motivation

▸ Why Instructions-Level Monitoring (ILM) ?

Observation

A Shadow Stack for return addresses can be implemented on the hypervisor-level by only trapping call and return instructions.

ILM Requirements

1

Based on full hardware virtualization

2

Secure

3

Flexible

S. Vogl and C. Eckert (TUM)

10.04.2012 17 / 42

SLIDE 21

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3

Trap Flag (TF)-based ILM

S. Vogl and C. Eckert (TUM)

10.04.2012 18 / 42

SLIDE 22

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3 Trap Flag (TF)-based ILM

S. Vogl and C. Eckert (TUM)

10.04.2012 19 / 42

SLIDE 23

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3 Trap Flag (TF)-based ILM ▸ Insecure

S. Vogl and C. Eckert (TUM)

10.04.2012 19 / 42

SLIDE 24

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3 Trap Flag (TF)-based ILM ▸ Insecure ▸ Incomplete

S. Vogl and C. Eckert (TUM)

10.04.2012 19 / 42

SLIDE 25

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3 Trap Flag (TF)-based ILM ▸ Insecure ▸ Incomplete ▸ Inflexible

S. Vogl and C. Eckert (TUM)

10.04.2012 19 / 42

SLIDE 26

Motivation

▸ Why a new ILM mechanism?

Existing Approaches

1

Page-Fault (PF)-based ILM

2

Debug Register (DR)-based ILM

3 Trap Flag (TF)-based ILM ▸ Insecure ▸ Incomplete ▸ Inflexible

⇒ None of the existing methods can provide the desired flexbility.

S. Vogl and C. Eckert (TUM)

10.04.2012 19 / 42

SLIDE 27

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 20 / 42

SLIDE 28

Performance Monitoring Counters (PMCs)

▸ Overview

Performance Monitoring on the x86 architecture

Performance Events

S. Vogl and C. Eckert (TUM)

10.04.2012 21 / 42

SLIDE 29

Performance Monitoring Counters (PMCs)

▸ Overview

Performance Monitoring on the x86 architecture

Performance Events PMCs that count these events

S. Vogl and C. Eckert (TUM)

10.04.2012 21 / 42

SLIDE 30

Performance Monitoring Counters (PMCs)

▸ Overview

Performance Monitoring on the x86 architecture

Performance Events PMCs that count these events

▸ Which event is counted can be programmed.

S. Vogl and C. Eckert (TUM)

10.04.2012 21 / 42

SLIDE 31

Performance Monitoring Counters (PMCs)

▸ Overview

Performance Monitoring on the x86 architecture

Performance Events PMCs that count these events

▸ Which event is counted can be programmed. ▸ Can be set to raise an interrupt on overflow.

S. Vogl and C. Eckert (TUM)

10.04.2012 21 / 42

SLIDE 32

Performance Monitoring Counters (PMCs)

▸ Performance Events ▸

All instructions

▸

All branch instructions

▸

All conditional branch instructions

▸

All near call instructions

▸

All near return instructions

▸

All far branch instructions

S. Vogl and C. Eckert (TUM)

10.04.2012 22 / 42

SLIDE 33

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 23 / 42

SLIDE 34

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events

Question

How can we trap performance events to the hypervisor?

S. Vogl and C. Eckert (TUM)

10.04.2012 24 / 42

SLIDE 35

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events

Question

How can we trap performance events to the hypervisor?

Challenges

1

Interrupt Generation: Generate an interrupt whenever the desired hardware performance event occurs.

S. Vogl and C. Eckert (TUM)

10.04.2012 24 / 42

SLIDE 36

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events

Question

How can we trap performance events to the hypervisor?

Challenges

1

Interrupt Generation: Generate an interrupt whenever the desired hardware performance event occurs.

2

Control Transfer: The emitted interrupt must lead to a VM Exit.

S. Vogl and C. Eckert (TUM)

10.04.2012 24 / 42

SLIDE 37

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Signal Generation

Set the PMC initially to

MAX_PMC_VALUE - X + 1

where X is the number of events that should occur before the interrupt.

S. Vogl and C. Eckert (TUM)

10.04.2012 25 / 42

SLIDE 38

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Signal Generation

Set the PMC initially to

MAX_PMC_VALUE - X + 1

where X is the number of events that should occur before the interrupt.

⇒ PMC will overflow after the desired number of events.

S. Vogl and C. Eckert (TUM)

10.04.2012 25 / 42

SLIDE 39

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Signal Generation

Set the PMC initially to

MAX_PMC_VALUE - X + 1

where X is the number of events that should occur before the interrupt.

⇒ PMC will overflow after the desired number of events. ⇒ An Interrupt will be generated.

S. Vogl and C. Eckert (TUM)

10.04.2012 25 / 42

SLIDE 40

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC).

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 41

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC). It is possible to generate a Nonmaskable Interrupt (NMI).

▸ NMIs lead to a VM Exit if the appropriate flag is set.

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 42

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC). It is possible to generate a Nonmaskable Interrupt (NMI).

▸ NMIs lead to a VM Exit if the appropriate flag is set. ▸ NMIs are immediately handled by the processor.

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 43

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC). It is possible to generate a Nonmaskable Interrupt (NMI).

▸ NMIs lead to a VM Exit if the appropriate flag is set. ▸ NMIs are immediately handled by the processor.

Problem: Interrupt Delivery

There is a gap of time between the occurrence of a performance event and the interrupt delivery.

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 44

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC). It is possible to generate a Nonmaskable Interrupt (NMI).

▸ NMIs lead to a VM Exit if the appropriate flag is set. ▸ NMIs are immediately handled by the processor.

Problem: Interrupt Delivery

There is a gap of time between the occurrence of a performance event and the interrupt delivery. Other performance events may go unnoticed during this period of time.

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 45

PMC-based Instruction-level Monitoring (ILM)

▸ Trapping Performance Events: Control Transfer

Interrupt Generation

The type of interrupt that is generated depends on the settings within the local Advanced Programmable Interrupt Controller (APIC). It is possible to generate a Nonmaskable Interrupt (NMI).

▸ NMIs lead to a VM Exit if the appropriate flag is set. ▸ NMIs are immediately handled by the processor.

Problem: Interrupt Delivery

There is a gap of time between the occurrence of a performance event and the interrupt delivery. Other performance events may go unnoticed during this period of time. Problem has to be solved on a case-by-case basis.

S. Vogl and C. Eckert (TUM)

10.04.2012 26 / 42

SLIDE 46

PMC-based Instruction-level Monitoring (ILM)

▸ Instruction Reconstruction (IR)

Problem

The number of selected instructions that are executed during interrupt delivery depend on the event that we monitor. If we set a PMC to count every instruction, about 6 instructions will be executed on the average before the interrupt is acknowledged.

S. Vogl and C. Eckert (TUM)

10.04.2012 27 / 42

SLIDE 47

PMC-based Instruction-level Monitoring (ILM)

▸ Instruction Reconstruction (IR)

Problem

The number of selected instructions that are executed during interrupt delivery depend on the event that we monitor. If we set a PMC to count every instruction, about 6 instructions will be executed on the average before the interrupt is acknowledged.

Solution

The PMC will keep counting after an overflow occurred.

⇒ We know exactly how many instructions were executed before the

interrupt was acknowledged.

⇒ Reconstruct the instruction stream and obtain the instructions

that we missed.

S. Vogl and C. Eckert (TUM)

10.04.2012 27 / 42

SLIDE 48

PMC-based Instruction-level Monitoring (ILM)

▸ Instruction Reconstruction (IR)

Approach

1

Save the value of the instruction pointer on every overflow.

2

Check the value of the PMC on overflow to determine how many instructions were missed if any.

3

Disassemble every instruction starting from the last saved instruction pointer till we reach the current instruction pointer.

Example

1

40f448 : mov %r12 ,% r d i ; <====== LAST EIP

2

40f44b : mov $0x20,%esi

3

40f450 : mov %rbp ,%rdx

4

40f453 : mov %ecx ,0 x28(%rsp )

5

40f457 : mov %r8b ,0 x10(%rsp )

6

40f45c : mov %r9 ,0 x20(%rsp )

7

40f461 : add %rbp ,%r12 ; <====== CURRENT EIP

S. Vogl and C. Eckert (TUM)

10.04.2012 28 / 42

SLIDE 49

PMC-based Instruction-level Monitoring (ILM)

▸ Instruction Reconstruction (IR) What about branches?

1

40f24e : pop %r12 ; <====== LAST EIP

2

40f250 : pop %r13

3

40f252 : pop %r14

4

40f254 : pop %r15

5

40f256 : ret

Problem

The target of a branch may depend on a memory operand that may have been overwritten in the meantime.

S. Vogl and C. Eckert (TUM)

10.04.2012 29 / 42

SLIDE 50

PMC-based Instruction-level Monitoring (ILM)

▸ The Last Branch Record (LBR) Stack

LBR Stack

Records the last taken branches Set of MSRs

▸ A top-of-stack (TOS) pointer (MSR_LASTBRANCH_TOS) ▸ A pair of MSRs for each branch that the stack can record:

MSR_LASTBRANCH_x_FROM_IP ⇒ MSR_LASTBRANCH_x_TO_LIP

The size of the LBR stack depends on the microarchitecture

S. Vogl and C. Eckert (TUM)

10.04.2012 30 / 42

SLIDE 51

PMC-based Instruction-level Monitoring (ILM)

▸ The Last Branch Record (LBR) Stack

LBR Stack

Records the last taken branches Set of MSRs

▸ A top-of-stack (TOS) pointer (MSR_LASTBRANCH_TOS) ▸ A pair of MSRs for each branch that the stack can record:

MSR_LASTBRANCH_x_FROM_IP ⇒ MSR_LASTBRANCH_x_TO_LIP

The size of the LBR stack depends on the microarchitecture

⇒ Save the TOS pointer on each monitoring related interrupt.

S. Vogl and C. Eckert (TUM)

10.04.2012 30 / 42

SLIDE 52

PMC-based Instruction-level Monitoring (ILM)

▸ The Last Branch Record (LBR) Stack

LBR Stack

Records the last taken branches Set of MSRs

▸ A top-of-stack (TOS) pointer (MSR_LASTBRANCH_TOS) ▸ A pair of MSRs for each branch that the stack can record:

MSR_LASTBRANCH_x_FROM_IP ⇒ MSR_LASTBRANCH_x_TO_LIP

The size of the LBR stack depends on the microarchitecture

⇒ Save the TOS pointer on each monitoring related interrupt. ⇒ All taken branches are recorded between the last saved TOS and the current

TOS.

S. Vogl and C. Eckert (TUM)

10.04.2012 30 / 42

SLIDE 53

PMC-based Instruction-level Monitoring (ILM)

▸ Instruction Reconstruction (IR)

0x40f256 0x40f4b3 Last TOS Current TOS

MSR_LASTBRANCH_7_FROM_IP MSR_LASTBRANCH_7_TO_LIP MSR_LASTBRANCH_8_FROM_IP

Using the LBR Stack

1

40f24e : pop %r12 ; <====== LAST EIP

2

40f250 : pop %r13

3

40f252 : pop %r14

4

40f254 : pop %r15

5

40f256 : ret

6 7

40f4b3 : mov %r12 ,% r d i ; <====== CURRENT EIP

S. Vogl and C. Eckert (TUM)

10.04.2012 31 / 42

SLIDE 54

PMC-based Instruction-level Monitoring (ILM)

▸ What about security?

PMCs are MSRs All PMC control structures are MSRs as well Read/Write accesses to MSRs can be intercepted from the hypervisor

⇒ An attacker cannot disable or manipulate the PMCs.

S. Vogl and C. Eckert (TUM)

10.04.2012 32 / 42

SLIDE 55

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 33 / 42

SLIDE 56

Experiments & Results

▸ Experiments

Monitored four common Linux applications at the instruction-level:

▸ ls

(Argument: /usr/bin, 597 files)

▸ tar

(Argument: Hello World.c, 10 LOC)

▸ cat

(Argument: Hello World.c, 10 LOC)

▸ gcc

(Argument: Hello World.c, 10 LOC)

S. Vogl and C. Eckert (TUM)

10.04.2012 34 / 42

SLIDE 57

Experiments & Results

▸ Experiments

Monitored four common Linux applications at the instruction-level:

▸ ls

(Argument: /usr/bin, 597 files)

▸ tar

(Argument: Hello World.c, 10 LOC)

▸ cat

(Argument: Hello World.c, 10 LOC)

▸ gcc

(Argument: Hello World.c, 10 LOC)

Each application was executed multiple times using different monitoring modes:

▸ PMC ALL & IR: All instructions & Instruction Reconstruction ▸ TF ALL: All instructions ▸ PMC ALL: All instructions without Instruction Reconstruction ▸ PMC Branches: All branch instructions ▸ PMC Shadow Stack: Only call & return instructions

S. Vogl and C. Eckert (TUM)

10.04.2012 34 / 42

SLIDE 58

Experiments & Results

▸ Experiments

Monitored four common Linux applications at the instruction-level:

▸ ls

(Argument: /usr/bin, 597 files)

▸ tar

(Argument: Hello World.c, 10 LOC)

▸ cat

(Argument: Hello World.c, 10 LOC)

▸ gcc

(Argument: Hello World.c, 10 LOC)

Each application was executed multiple times using different monitoring modes:

▸ PMC ALL & IR: All instructions & Instruction Reconstruction ▸ TF ALL: All instructions ▸ PMC ALL: All instructions without Instruction Reconstruction ▸ PMC Branches: All branch instructions ▸ PMC Shadow Stack: Only call & return instructions

Measured the execution time from the hypervisor for each run Calculated the average slowdown factor

S. Vogl and C. Eckert (TUM)

10.04.2012 34 / 42

SLIDE 59

Experiments & Results

▸ Results

Mode ls tar cat gcc

PMC ALL & IR 755 (18s) 1002 (3.0s) 334 (0.6s) 1263 (92s) TF ALL 310 (7.0s) 415 (1.2s) 142 (0.3s) 545 (40s) PMC ALL 273 (6.5s) 403 (1.2s) 126 (0.3s) 435 (32s) PMC Branches 163 (4.0s) 259 (0.8s) 81 (0.2s) 281 (21s) PMC Shadow Stack 95 (2.0s) 196 (0.6s) 31 (0.1s) 212 (15s)

S. Vogl and C. Eckert (TUM)

10.04.2012 35 / 42

SLIDE 60

Experiments & Results

▸ Improving the Performance

Improving the Performance

The performance of the approach heavily depends on the number

f the VM Exists.
S. Vogl and C. Eckert (TUM)

10.04.2012 36 / 42

SLIDE 61

Experiments & Results

▸ Improving the Performance

Improving the Performance

The performance of the approach heavily depends on the number

f the VM Exists.

The performance will increase by almost the same factor as the VM Exits are decreased.

S. Vogl and C. Eckert (TUM)

10.04.2012 36 / 42

SLIDE 62

Experiments & Results

▸ Improving the Performance

Improving the Performance

The performance of the approach heavily depends on the number

f the VM Exists.

The performance will increase by almost the same factor as the VM Exits are decreased. Possible Approaches

▸ Precise Event Based Sampling (PEBS) ▸ Branch Trace Store (BTS)

S. Vogl and C. Eckert (TUM)

10.04.2012 36 / 42

SLIDE 63

Experiments & Results

▸ Improving the Performance

Improving the Performance

The performance of the approach heavily depends on the number

f the VM Exists.

The performance will increase by almost the same factor as the VM Exits are decreased. Possible Approaches

▸ Precise Event Based Sampling (PEBS) ▸ Branch Trace Store (BTS)

Security

The overall security of the mechanisms will decrease if the VM Exits are reduced.

S. Vogl and C. Eckert (TUM)

10.04.2012 36 / 42

SLIDE 64

Outline

1

Motivation

2

Performance Monitoring Counters (PMCs)

3

PMC-based Instruction-level Monitoring (ILM)

4

Experiments & Results

5

Summary

S. Vogl and C. Eckert (TUM)

10.04.2012 37 / 42

SLIDE 65

Summary

Contributions

PMC-based trapping A flexible and secure ILM mechanism Instruction Reconstruction

S. Vogl and C. Eckert (TUM)

10.04.2012 38 / 42

SLIDE 66

Summary

Contributions

PMC-based trapping A flexible and secure ILM mechanism Instruction Reconstruction

Performance

The proposed ILM mechanism still leads to significant overhead. However, the mechanism can be significantly faster than existing hardwared-based mechanism on the x86 architecture. There is still a lot of room for improvements. More detailed experiments are needed.

S. Vogl and C. Eckert (TUM)

10.04.2012 38 / 42

SLIDE 67

Summary

Contributions

PMC-based trapping A flexible and secure ILM mechanism Instruction Reconstruction

Performance

The proposed ILM mechanism still leads to significant overhead. However, the mechanism can be significantly faster than existing hardwared-based mechanism on the x86 architecture. There is still a lot of room for improvements. More detailed experiments are needed.

⇒ We encourage other researchers to explore the possibilities of

PMC-based trapping as well as PMC-based ILM.

S. Vogl and C. Eckert (TUM)

10.04.2012 38 / 42

SLIDE 68

Summary

▸ Questions?

S. Vogl and C. Eckert (TUM)

10.04.2012 39 / 42

SLIDE 69

References I

Lucas Davi, Ahmad-Reza Sadeghi, and Marcel Winandy. Ropdefender: a detection tool to defend against return-oriented programming attacks. In Proceedings of the 6th ACM Symposium on Information, Computer and Communications Security, 2011. Artem Dinaburg, Paul Royal, Monirul Sharif, and Wenke Lee. Ether: Malware Analysis via Hardware Virtualization Extensions. In Proceedings of the 15th ACM conference on Computer and Communications Security, 2008. Tal Garfinkel, Keith Adams, and Andrew Warfield. Compatibility is not transparency. In Proceedings of the 11th Workshop on Hot Topics in Operating Systems, 2007.

S. Vogl and C. Eckert (TUM)

10.04.2012 40 / 42

SLIDE 70

References II

Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide, 2011. Corey Malone, Mohamed Zahran, and Ramesh Karri. Are hardware performance counters a cost effective way for integrity checking of programs. In Proceedings of the sixth ACM workshop on Scalable Trusted Computing, 2011. Jonas Pfoh, Christian Schneider, and Claudia Eckert. Exploiting the x86 Architecture to Derive Virtual Machine State Information. In Proceedings of the fourth international conference on Emerging Security Information, Systems and Technologies, 2010.

S. Vogl and C. Eckert (TUM)

10.04.2012 41 / 42

SLIDE 71

References III

Jonas Pfoh, Christian Schneider, and Claudia Eckert. Nitro: Hardware-based System Call Tracing for Virtual Machines. Advances in Information and Computer Security, 2011.

S. Vogl and C. Eckert (TUM)

10.04.2012 42 / 42