Linux Internals Dev

linux-internals

Deep Linux internals for practitioners who need to reason below libc and framework abstractions.

This skill is for structural mechanics: what the kernel and loader actually do, what invariants hold, what breaks across versions, and where detection surfaces appear.

When to activate

• You are writing or reviewing custom ELF loaders, in-memory execution, or reflective mapping logic
• You are parsing /proc for process, memory, mount, or namespace intelligence and need race-safe interpretation
• You are building namespace or container boundary logic with clone, unshare, setns, or pidfd flows
• You are loading eBPF programs and debugging verifier failures, helper constraints, map lifetime, or attach semantics
• You are reasoning about LSM policy behavior, hook order, and process security attribute surfaces
• You need to explain detection and hardening implications of low-level Linux behavior

If the task is ordinary userland API usage, this skill is overkill. If the task is ABI and kernel boundary mechanics, use this skill first.

Territory map

Quick invariants

Decision flow: choose the right subsystem lens

1. Issue is binary load or symbol resolution behavior

   • Start in elf-format.md
   • Validate PT_INTERP, DT_NEEDED, DT_RPATH and DT_RUNPATH, then relocation type flow

2. Issue is process or memory inspection mismatch

   • Start in procfs.md
   • Validate ptrace permission model, hidepid mode, and map-read race conditions

3. Issue is container boundary or namespace transition

   • Start in namespaces.md
   • Validate ownership user namespace, capability context, and one-way PID namespace movement

4. Issue is syscall origin, anti-hooking, or low-level ABI behavior

• Start in syscall-dispatch-linux.md
• Validate calling convention (r10/rcx), dispatch source (vDSO vs libc vs direct), and fallback implications

5. Issue is eBPF load rejection or runtime attach surprises

   • Start in ebpf.md
   • Read verifier error class first, then map/program refs and attach target constraints

6. Issue is policy enforcement or security hook behavior

   • Start in lsm.md
   • Confirm active stack and hook order before attributing allow or deny outcomes

Detection and hardening surface checklist

Use this whenever implementing a low-level technique.

• ELF path
  • Does behavior depend on dynamic linker search path state such as RUNPATH, cache, preload, or secure-exec stripping?
• procfs path
  • Are you assuming stable snapshots from files documented as racy?
  • Are you accidentally leaking sensitive args or env due to permissive proc mount options?
• namespace path
  • Are capability checks evaluated in the expected owning user namespace?
  • Could namespace lifetime be pinned by open descriptors or bind mounts?
• syscall path
  • Is the syscall instruction sourced from the location you think it is (vDSO/libc/direct asm), and does that match your telemetry assumptions?
  • Are x86-64 register conventions respected for 4-6 argument syscalls?
• eBPF path
  • Are helper or map choices constrained by program type and privilege model?
  • Are verifier assumptions broken by helper-induced packet buffer changes?
• LSM path
  • Is behavior due to stacked module ordering rather than a single policy engine?
  • Are process attrs read from module-specific paths versus legacy aggregate paths?

Pitfalls

• Treating section headers as mandatory at runtime for execution behavior
• Assuming DT_RPATH and DT_RUNPATH are equivalent in dependency traversal
• Assuming /proc/pid/maps partial reads are stable under concurrent VMA changes
• Forgetting hidepid and ptrace gating when process inventory appears incomplete
• Expecting setns to move the caller itself into a new PID namespace instead of affecting future children
• Trying to reenter same user namespace to regain dropped capabilities
• Passing syscall arg4 in rcx instead of r10 on x86-64 and then debugging phantom failures
• Assuming all direct-syscall approaches have the same observable syscall origin in kernel telemetry
• Ignoring eBPF reference-release paths after socket lookup helpers
• Debugging eBPF without verifier logs, then guessing blindly
• Attributing policy outcomes to one LSM without checking active stack order

Resources

• references/elf-format.md for loader and relocation mechanics
• references/procfs.md for process and memory introspection semantics
• references/namespaces.md for isolation model and transition constraints
• references/syscall-dispatch-linux.md for syscall ABI, dispatch-source tradeoffs, and fallback design
• references/ebpf.md for verifier and syscall-level eBPF operations
• references/lsm.md for LSM architecture and policy interaction model