Skip to content

docs: publish a recorded demo and measured numbers on the site - #5

Merged
umars28 merged 1 commit into
mainfrom
docs/site-demo-and-numbers
Sep 13, 2026
Merged

umars28 merged 1 commit into
mainfrom
docs/site-demo-and-numbers

Conversation

@umars28

@umars28 umars28 commented Sep 13, 2026

Copy link
Copy Markdown
Member

The README showed one docker line and the site showed none. This adds a
recording of docker driving mars, and a numbers section the page reads from
JSON at load time instead of carrying by hand.

The recording

site/demo.sh produces site/demo.cast, rendered to site/demo.gif with agg.
Every line reads kernel state back rather than trusting what the runtime says it
did:

  • a memory limit set on the command line, read out of the cgroup mars wrote
  • PID 1 inside its own PID namespace, compared against the host's
  • the capability set the container is left holding

The .cast is plain text, so it can be re-rendered at a different size or theme
without re-recording.

The numbers

scripts/bench.sh writes site/metrics.json; site/metrics.js renders it, and
shows a dash for anything absent. Nothing on the page is a number somebody
remembered.

binary 3,480,376 B
direct dependencies 12, of 80 crates locked
container start 117 ms, against 134 ms through the default runtime
capabilities kept 14
OCI assertions passing 26

The attack profile is deliberately not in that harness. It needs root and
ftrace and a long serial run, scripts/hap-bench.sh already owns it, and the
table it produces carries its own method. The numbers section says so, and says
plainly that start latency is the least interesting figure on the page because
docker and image setup dominate it — which is the whole reason this project
measures horizontal attack profile instead.

Traps worth knowing

bench.sh honours CARGO_TARGET_DIR. The development VM points it at
/var/tmp/mars-target because building on the virtiofs mount is slow, so
target/release/mars is not where the binary lands.

The demo needs docker on native.cgroupdriver=cgroupfs. On the systemd driver
docker delegates cgroup creation over dbus while mars writes cgroupfs
directly, and the two disagree about who owns the container's cgroup.
scripts/install-docker-runtime.sh already sets this and explains why.

Regenerating

cargo build --release
./scripts/bench.sh --out site/metrics.json
asciinema rec --command ./site/demo.sh site/demo.cast
agg site/demo.cast site/demo.gif

The README showed one docker line and the site showed none. It now opens
with an asciinema recording of docker driving mars: a memory limit read
back out of the cgroup mars wrote, PID 1 in its own namespace compared
against the host's, and the capability set the container is left holding.
Every line reads kernel state rather than trusting the runtime.

A numbers section carries binary size, dependency count, start latency
and the capability count, from scripts/bench.sh through metrics.json,
rendered as a dash when absent.

The attack profile is deliberately not in that harness. It needs root and
ftrace and a long serial run, scripts/hap-bench.sh owns it, and the table
it produces already carries its own method. The numbers section says so,
and says plainly that start latency is the least interesting figure on
the page because docker and image setup dominate it.

Traps:

bench.sh honours CARGO_TARGET_DIR. The development VM points it at
/var/tmp/mars-target because building on the virtiofs mount is slow, so
target/release/mars is not where the binary lands.

The demo needs docker on native.cgroupdriver=cgroupfs. On the systemd
driver docker delegates cgroup creation over dbus while mars writes
cgroupfs directly, and the two disagree about who owns the container's
cgroup.
@umars28
umars28 merged commit 0c8e617 into main Sep 13, 2026
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant