"Efficient Software-based Fault Isolation". by R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham. Presenter: Tom Burkleaux. What is the problem?. With closely cooperating software modules, how do we protect from distrusted code? What is distrusted code?
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
by R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham.
Presenter: Tom Burkleaux
Elements of the OS are moved to user- space.
Extensible Type System
Extensibility code supported by OS
Link together independently developed software modules
Low communication cost between modules
Separate protection domains
Distrusted code can cause hard to find bugs within a system
Cross-Protection Domain calls are expensive (RPC). Overall application performance suffers.
Protection Domains Shared Address
Protection Domains Shared Address
(I think?) more a tendency to share address space for performance reasons
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”
Each segment shares unique pattern of upper bits. “segment identifier”
Pseudo code example.
w/o dedicated registers, code could jump to last instruction
With segment-matching, we can pin-point the source of the fault
How does this compare with hardware-based memory protection?
What about the loss of registers?
Idea is we can reduce run-time overhead by giving up information on source of fault.
Before each unsafe instruction we simply insert code that sets the uppers bit of the target to the correct segment identifier
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!
They went with option 1. Problem with modifying object code is making modified object code use a subset of registers.
Args are copied through a shared buffer
Jump Table: each entry is a control transfer instruction to legal entry point outside the domain
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.
The authors developed an analytical model to predict cost. Expected overhead is:
(s-instructions – interlocks ) / cycles-per-second
S-instructions = sandbox instructions
Interlocks = saved floating point interlocks
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!
Overall, overhead is not much!
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.
X-axis: percentage of time spent crossing domains
Y-axis: relative cost of software enforced fault-domain crossing vs hardware method
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?