This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
arch paper section on safety
- From: "Chen, Brad" <brad dot chen at intel dot com>
- To: <systemtap at sources dot redhat dot com>
- Date: Thu, 7 Apr 2005 17:50:06 -0700
- Subject: arch paper section on safety
Before I check this in I was hoping to get through
one round of review.
Brad
=================================================================
Safety in Systemtap
Systemtap is designed to be safe to use on production systems.
An implication is that it should be extremely difficult if not
impossible to disable or crash a system through use or misuse of
Systemtap. Problems like infinite loops, division by zero, and
illegal memory references should lead to a graceful failure of
a Systemtap script without otherwise disrupting the monitored
system. At the same time, we'd like for Systemtap extensions to
compile to machine code, to leverage existing infrastructure such
as compilers and "insmod" and to approach native performance.
Our basic approach to safety is to design a safe scripting language,
with some safety properties supported by runtime checks. Systemtap
compiles the script file into native code and links it with the
systemtap runtime library to create a loadable kernel module.
Version checks and symbol name checks are applied by insmod
[I ASSUME WE GET THE SAME SAFETY HERE AS /sbin/insmod].
The elaborator generates instrumentation code that gracefully
terminates loops and recursion at runtime if they run beyond a
configurable threshold.
We avoid priviledged and illegal kernel instructions by excluding
constructs in the script language for inlined assembler, and by
using compiler options commonly used for the kernel.
Systemtap safety also requires controling access to kernel memory.
By default, kernel code cannot be invoked directly from a Systemtap
script. The Systemtap runtime can use kernel subroutines, and
these references are assumed to be safe.
Systemtap provides special language features for referring to
external data. [PROBLEM: POINTER ARGUMENTS TO PROCEDURES] When
it sees such references, it constrains it based on a policy
specified when the script is run. By default, writes to arbitrary
kernel memory are prohibited, and external reads of any kernel
memory are allowed except for the range of the virtual address
space used for memory-mapped devices.
To implement these restrictions, external writes cause the
elaborator to generate an error, and checking code is inserted
to enforce range restrictions on external read references.
Additionally, a modified trap handler is used to safely handle
invalid memory references anywhere in the kernel address space.
Systemtap also supports a "guru" mode where these code and data
reference constraints are removed. This allows us to tradeoff
safety features to support the needs of kernel debugging tasks.
Safety Enhancements
We are considering a number of subsystems that extend the safety
and flexibility of Systemtap to match and exceed that of other
systems based on interpreters.
A memory and code "portal" would direct external memory
references from Systemtap scripts, both to code and data,
through a special-purpose interpeter or "portal."
The goal of the portal is to shift safety policy selection
to the script user rather than the script author, and to
support definition of safety policies by script users,
giving them explicit and finer-grained controls.
We anticipate a model where people commonly use scripts
written by others.
Trivial policies would be provided with the system to support
"guru" (no restrictions) and default modes (restricted external
write and code access).
Other simple policies would expand access for a script incrementally.
For example, you might allow external calls to an explicit list
of kernel subroutines, or writes to an explicit list of kernel
data structures or range of kernel memory addresses. Such policies
would expand script capabilities with better safety than guru mode.
Eventually, the policy subsystem might be extended to support
security goals, such as restricting memory access control based
on UID.
A optional static analyzer provides redundant checking and
protection against various system bugs, installation problems and
misuse. The static analyzer examines a disassembled kernel module
and confirms that it satisfies certain safety properties. Simple
checks include disallowing priviledged instructions and instructions
that are illegal in kernel mode. More elaborate checks confirm that
loop counters, memory portals and other safety features are used,
given minimal cooperation from the language implementation to make
the machine code checkable. The analyzer rejects uncheckable code.
Comparision to Other Systems
Solaris DTrace includes a number of unusual features intended to
enhance the safety and security of the system. These features include:
- very restricted scripting language. The D language does not support
procedure declarations or a general purpose looping construct. This
avoids a number of safety issues in scripts including infinite
loops and infinite recursion.
- interpreted language. The D scripts compile to a RISC abstract
machine language that executes in an interpreter embedded in the
Solaris kernel. Because D scripts are interpreted rather than
executed directly, it is impossible for them to include illegal or
priviledged instructions or to invoke code outside of the DTrace
execution environment. The interpreter can also catch invalid
pointer dereferences, division by zero, and other run-time errors.
Features such as these enhance the perceived safety of DTrace.
Systemtap will support kernel debugging features that DTrace does not,
including ability to write arbitrary locations in kernel memory and
ability to invoke arbitrary kernel subroutines.
Since the language infrastructure used by Systemtap is common to
all C programs, it may be better tested and more robust than the
special-purpose infrastructure used by DTrace.
The embedding of an interpreter in the Solaris kernel represents
significant additional kernel functionality. This introduces an
increased risk of kernel bugs that could lead to security or
reliability issues.
Like DTrace, DProbes uses an interpreted language. [would a DProbes
expert like to finish this part?]
SECURITY
I'm not convinced we have anything important to write here.
Goals:
- Prevent systemtap user from creating new system vulnerabilities
- Stretch: appropriate access controls for non-root users
Assumptions: systemtap user has root priviledges
Conclusion: nothing locally to protect at this time