This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
architecture paper feedback: suggested security and performance scenarios
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Thu, 10 Feb 2005 17:14:24 -0800
- Subject: architecture paper feedback: suggested security and performance scenarios
It might be useful for the paper to define some
goals/expectations for common scenarios pertaining
to performance, safety and security. I've been
thinking about a few; I've attached them below.
With respect to the current "Safety" requirement, DTrace
appears to do an outstanding job of preventing people
from shooting themselves in the foot. Any thoughts on
adding this as an explicit requirement for systemtap?
Brad Chen
Performance Scenarios/goals:
============================
- dormant tool
=> 0.00% overhead
- interrupt-based flat profiling at various frequencies
=> sampling at XX KHz with 1% overhead
- interrupt-based call-stack profiling at various frequencies.
=> sampling at XX KHz with 1% overhead
- system-wide system call profiling (alla strace)
=> 1% overhead
A couple performance reference points: Digital's DCPI supported
5KHz sampling at < 3% overhead, but without walking the stack.
I believe OProfile is at about 1% overhead for 1KHz sampling.
Safety/Security Scenarios:
==========================
Scenario: version mismatch
Script was compiled on an old version of the system, then the system
is upgraded, and is not inconsistent with current APIs, symbols, etc.
Scenario: Oops! Wrong binary
In the heat of troubleshooting, a user specifies the wrong binary to
load into the kernel. Assume the user is root and the binary is not
deliberately malicious but otherwise arbitrarily bad.
Scenario: buggy script
A user who is learning to use the system writes many buggy scripts.
Can the we guarentee that the system will never crash? Consider
memory leak, recursion, infinite loop, stale pointers, bogus
pointers, jumps into arbitrary locations in kernel code, etc.
Scenario: a buggy compiler, translator, runtime
Does the system crash or just print a warning message?
Scenario: malicious attack: corrupted kernel
Probably nothing much you can do here.
Scenario: malicious attack: corrupted compiler, corrupted script-
launching system
Assertion: We do our users a favor by minimizing the number of
software components they need to secure in order to make the
overall system secure.