"efficient software-based fault isolation"

1

"Efficient Software-based Fault Isolation"

by R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham.

Presenter: Tom Burkleaux

2

What is the problem?

With closely cooperating software modules, how do we protect from distrusted code?

What is distrusted code?• Code that might corrupt memory of other

cooperating modules• Code that is not adequately tested• Perhaps written by third-party persons

3

Cooperating Modules

Complex systems are often broken down into separate (logical) components

This supports the following goals:• Independent development of individual

components• Upgrade and enhance existing components• “Extensibility” – allow other programmers to

add functionality

4

Examples: Cooperating Modules

• Micro-kernel operation systemsElements of the OS are moved to user-

space. • Postgres database manager

Extensible Type System• Microsofts Object Linking & Embedding (OLE)

Extensibility code supported by OSLink together independently developed

software modules

5

Structuring Cooperating Modules, 1

How can we structure cooperating modules? There are two basic choices, each with a distinct advantage:• Share the same address space

Low communication cost between modules• Keep modules in separate address spaces

Separate protection domains

6


… and each has a disadvantage:

• Share the same address spaceDistrusted code can cause hard to find bugs within a system

• Keep modules in separate address spaces Cross-Protection Domain calls are

expensive (RPC). Overall application performance suffers.

7


Protection Domains Shared Address

RPC

Shared Memory

8


Protection Domains Shared Address

RPC

Shared Memory

Slow!

Distrusted Code

?Yes

9

Trends in structuring?

In OS, which method of structuring coop. modules is more prevalent?• BSD System• Mach • Mac OS X• Linux

(I think?) more a tendency to share address space for performance reasons

10

Proposed Solution

If we want fault isolation, the authors offer a tradeoff:

Fault Isolation with – “substantially faster communication between fault domains, at a cost of slightly increased execution time for distrusted modules”

11

What Does Solution Look Like?

Shared Memory

Distrusted Code

NO

• We want the speed of shared memory• But we want to prevent distrusted code from corrupting memory of other modules• “Fault Domains”

Yes

12

Overview of Techniques

The authors suggest two techniques for software based fault-isolation:

• Segment Matching• Sandboxing

And two times these can be applied:• Compile Time• Object Linking

13

“Fault Domain” -- Definition

990---

Segment (code)

991---

992---

…

991---

992---

…

993---

…

Segment (data)

Fault Domain

Each segment shares unique pattern of upper bits. “segment identifier”

14

Examining Binary Code

For distrusted modules: What about modifying the binary so we add a check on all loads and stores? “binary patching”• Assume this could be done at load-time • Addresses are used very frequently, and this method would add extra instructions for each address reference• Many tools are based on identifying compiler-specific idioms to distinguish between code and data

15

Software-Enforced Fault Isolation: Segment Matching

“unsafe instruction” – an instruction that jumps or stores an address, and can’t be statically verified•Jumps through register are example•Compiler can add code to check instructions•On typical RISC architectures, this takes 4 instructions•Requires dedicated registers, to prevent checks being by-passed

16

Segment Matching, 2

Pseudo code example.

w/o dedicated registers, code could jump to last instruction

17

Segment Matching, 3

Shared Memory

Distrusted Code

Trap

With segment-matching, we can pin-point the source of the fault

How does this compare with hardware-based memory protection?

Yes

18

Segment Matching, 4

What about the loss of registers?

• We need four: addresses in data segment, address in code segment, segment shift amount, and segment identifier

• Author rely on most modern architectures having at least 32 registers

19

Software-Enforced Fault Isolation: Address Sandboxing

Idea is we can reduce run-time overhead by giving up information on source of fault.

Sandboxing:Before each unsafe instruction we simply insert code that sets the uppers bit of the target to the correct segment identifier

20

Sandboxing, 2

•There is no trap

•Only two extra instructions

• Recall that segment matching has five extra instructions

21

Sandboxing, 3

Shared Memory

Distrusted Code

Any address access outside of the module’s segment is prevented

We access and potentially corrupt an incorrect address within our own segment

Execution continues, unaware of error!

Yes

?

The sandbox

22

Optimizations

Guard Zones are one example of an opt. that can be handled by a compiler.•Avoid address arithmetic•Reg + Offset instr.•We sandbox only the Reg and handle offset by creating guard zones

23

Process Resources

We need to prevent distrusted modules from corrupting resources allocated on a per-address-space basis.

•One idea: make OS aware of fault domains

•Authors choose to require distrusted modules to access resources through cross-fault-domain RPC

24

Implementation

Authors identify two strategies for implementation•1. Have a compiler emit encapsulation code and have a verifier confirm object code at load time.•2. Modifying object code at load time. “binary patching”

They went with option 1. Problem with modifying object code is making modified object code use a subset of registers.

25

Low Latency Cross Fault RPC

Because distrusted modules are isolated, we need something like LRPC.

• Efficient software isolation was first part of solution

• The second part of solution is fast communication across fault domains

26

Cross Fault RPC, 2

Constraints of running distrusted code:

•Distrusted code can’t directly call a function outside its segment, or return from an outside call via an address on the stack

•When code is running within a distrusted module it has its own execution context.

27

Cross Fault RPC, 3

Like LRPC, the solution is done through stubs

•For each pair of fault domains a customized call and return stubs is created for each exported procedure•Stub run unprotected outside both domain•They are responsible for copy of args•And managing machine state

28

Cross Fault RPC, 4

Args are copied through a shared buffer

Jump Table: each entry is a control transfer instruction to legal entry point outside the domain

29

Cross Fault RPC, 5

The stubs and the jump table are added to the code.

The jump table added to the code segment, so distrusted code can’t modify.

30

Evaluation

For evaluation, the authors looked at three questions:

•What is overhead for software encapsulation?

•How fast is XFD-RPC?

•What effect does this solution have on end-user applications?

31

Evaluation – Software Encapsulation, 1

The authors developed an analytical model to predict cost. Expected overhead is:

(s-instructions – interlocks ) / cycles-per-second------------------------------------------------------Original-execution-time-seconds

S-instructions = sandbox instructionsInterlocks = saved floating point interlocks

32

Evaluation - Software Encapsulation, 2

The purpose of the model is help identify 2nd order effects.

To get data, they ran various benchmarks, and ran the benchmark code as “untrusted” modules.

They found that their model predicted the “average” overhead very well. But individual benchmark test showed NEGATIVE overhead!

33

Evaluation-Software Encapsulation

34

Evaluation - Software Encapsulation, 4

Explaining results

•Anomolies – 2nd order effects? Conjecture: “instruction cache mapping conflicts”•Programs with more floating-point operations exhibitied less overhead (2.5% vs 5.6%)•These were compute heavy benchmarks•They expect I/O programs to have less overhead

Overall, overhead is not much!

35

Evaluation – Cross-Fault RPC, 1

How to measure XFD-RPC? Their mechanism spends most of its time saving and restoring registers. •Table 2 (following) – shows performance for NULL cross fault domain RPC. And this is compared to a C procedure call and Pipes.•Their call is 1 order of magnitude better than C procedure call•Other optimized RPCs are, at best, 2 orders of magnitude better than C procedure call.

36


37


Table 3 measures how their system works when applied to Postgres, using the Sequoia 2000 benchmark.

Postgres has extensible type system, which is a recognize safety problem.

They want to compare their system with Postgres’ built in “untrusted function manager” and traditional hardware protection domains.

38

Analysis

•The author’s Postgress example shows savings over other methods. •The formula for savings in general is:

Savings = (1 – r) tc - h td

tc time spent crossing fault domains

td time spent in distrusted code

h overhead for encapsulation r ratio of their crossing time to hardware RPC

39

Analysis, 2

•The savings formula can be graphed to illustrate the breakeven curve.

• In figures following:X-axis: percentage of time spent crossing domainsY-axis: relative cost of software enforced fault-domain crossing vs hardware method

40

Breakeven curve

41

Analysis, 4

• The question is: does savings in efficient XFD-RPC (over traditional RPC) make up for encapsulation overhead?• Answer appears to yes• Author’s give example if app spends 30% of its time crossing fault domains, their RPC mechanism needs to be only 10% better• Figure 5 was conservative and assumed everything was protected. Usually most of the app is trusted. Figure 6 assume only 50% of time is spend in distrusted code.

42

Breakeven curve

43

Some Additional Points

Why not object code? Because tools are there and you may lose compiler efficiencies

How many tools are written for this? In what compiler languages?

Any Questions?

"efficient software-based fault isolation"

Documents