Safety: The "Guru Mode

Protecting the Kernel from Your Script

Since SystemTap loads a kernel module, a buggy script could theoretically trigger a kernel panic and crash the server. To prevent accidental disasters, SystemTap enforces several safety constraints by default:

1. Loop bounds: Loops are limited in iteration count. An infinite loop in a probe handler would deadlock the kernel — SystemTap prevents this at compile time.
2. Memory safety: You cannot dereference arbitrary pointers. Accesses to kernel and user memory go through checked helper functions.
3. Read-only by default: You can read kernel variables, but you cannot modify them. This prevents probes from accidentally corrupting kernel state.
4. Recursion prevention: Probe handlers cannot recursively trigger themselves.

Guru Mode (-g):

Passing the -g flag when invoking stap disables these safety constraints.

Guru mode unlocks:

• Variable modification: You can change the value of a kernel variable mid-execution. For example, you could intercept sys_open and redirect the filename to a different path — a technique used in some sandboxing and fault injection tools.
• Raw C embedding: You can embed raw C code blocks directly in your script using %{ ... %} syntax, giving you full kernel programming power.
• Privilege escalation research: Modifying a uid field to 0 inside a running kernel function is a classic privilege escalation technique. Guru mode makes this trivially scriptable — which is exactly why it requires root and why you should never run untrusted .stp scripts with -g.

The production rule: Never run guru mode scripts on production systems unless you have tested them exhaustively in a staging environment with an identical kernel version. A single bad memory write in a probe handler can corrupt kernel data structures and cause a delayed, hard-to-diagnose panic.