Baryon Systems, end to end.

What is Baryon Systems?

Baryon Systems is a desktop application (Electron, Windows today, macOS+Linux next) and a small company building it. The desktop signs you in, manages your account, and opens a Products panel that lists every Baryon product available to you. Each product runs on its own Linux footprint and keeps its own state — the desktop is just the shell.

Today the Products panel ships two unlocked tiles:

• Baryon Gluon — the eBPF/XDP host-defence stack.
• Baryon Tachyon — the runaway-process autopilot.

Three more tiles — Quark (confidential analytics), Lepton (zero-trust gateway), Boson (compliance hub) — are visible but locked; they unlock in place as they ship. The products are independent. Installing one does not require, configure, or talk to any of the others.

Baryon Gluon · overview

Gluon is a fleet manager for Linux instances you’ve paired with the desktop. It bundles five tightly-integrated layers:

1. Layer 1 — Kernel firewall. Real eBPF/XDP, generated and compiled from your rules, hot-attached to the NIC.
2. Layer 2 — Identity & attestation. Per-host HMAC challenge-response and full systemd-sandbox snapshots.
3. Layer 3 — Audit ledger. SHA-256 hash-chained JSONL, verifiable offline.
4. Layer 4 — Workspace backend. Postgres 16 + PostgREST + Supabase Realtime, deployed in Docker, reached only via SSH tunnel.
5. Layer 5 — Chat & live alerts. Real-time collaboration with kernel-event mirroring.

The agent that runs on each Linux host is a single Python file — agent/gluon-agent.py — using only the standard library and ~1300 lines including all the eBPF code generation. The systemd unit grants the minimum capabilities required (CAP_BPF, CAP_PERFMON, CAP_NET_ADMIN, CAP_SYS_ADMIN) and locks everything else down.

Gluon architecture

There are three trust zones:

• Your desktop (Electron app) — holds the workspace encryption key, the SSH credentials, and the pinned agent fingerprints.
• Each Linux host — runs gluon-agent.service on 127.0.0.1:7777 (control plane, admin-token-gated) and a rate-limiting reverse proxy on 127.0.0.1:7778 (data plane). The agent owns /etc/gluon/ and /var/lib/gluon/.
• The workspace backend — Postgres + PostgREST + Realtime in three Docker containers, bound to localhost on the backend host. Reached from your desktop only through an SSH tunnel.

Nothing in this picture is reachable from the public Internet except port 22 (SSH). The XDP firewall additionally drops everything else at the NIC.

Trust model

The short version:

• Your SSH keys are what get you onto a host. We never see them.
• Your workspace key is the master secret in the desktop — it derives the per-instance admin tokens and decrypts everything in the local workspace bundle.
• Each agent has an independent identity key (/etc/gluon/agent.key, 0600 root:root, 32 random bytes). Its SHA-256 fingerprint is pinned on the desktop at first pair.
• Any future challenge-response that doesn't HMAC against that key fails loudly — even if SSH still works.
• The ledger hash chain is a backstop: if anyone tampers with a past entry, every later entry's hash no longer matches. verify() tells you the first broken line.

Requirements

Your desktop:

• Windows 10/11, macOS 12+, or recent Linux desktop
• ~150 MB free disk space

Each Linux host you want to pair:

• Ubuntu 20.04+, Debian 11+, RHEL/Rocky 8+, or anything with systemd, python3 (3.8+) and a kernel = 5.10 (for XDP / eBPF)
• Root SSH access during install (it creates a system user and installs a service)
• For the kernel firewall: clang, llvm, libbpf-dev and kernel headers — installed automatically by install.sh

Install the desktop app

Two binaries are shipped per release:

On first launch you create a workspace passphrase. The app derives an AES key from it, stores nothing in the cloud, and unlocks the workspace on every subsequent open.

Pair a Linux host

From the desktop, open Instances ? Add. The wizard asks for:

• A friendly name (e.g. edge-vps-1)
• SSH host + port
• SSH user (must be able to sudo or be root for install)
• Path to your SSH private key

The wizard then runs the install script on the host. Output streams live into the panel. When it finishes you'll see three machine-parseable lines:

GLUON_INSTALL_OK
GLUON_FINGERPRINT=A1:B2:C3:…
GLUON_ADMIN_TOKEN=•••

The desktop pins that fingerprint and stores the admin token encrypted in the workspace. From now on it talks to the agent over the SSH tunnel on 127.0.0.1:7777, presenting the bearer token.

Your first firewall rules

Open Layer 1 · Per-instance XDP. The panel has three editors:

• Block list — CIDRs that always get dropped (max 256).
• Per-port rate limits — TCP/UDP destination port + pps cap (max 16 entries).
• UDP flood mitigation — global per-source pps cap on UDP.

Click Compile & attach. Behind the scenes:

1. The desktop POSTs the validated rules to the agent.
2. The agent regenerates firewall.c with your rules and an SSH whitelist baked in (so you can't ever lock yourself out by accident — even with an empty rule set, SSH is always allowed).
3. The agent runs clang -O2 -g -target bpf -c firewall.c -o firewall.o.
4. The agent runs ip link set dev <iface> xdp obj firewall.o sec xdp, falling back to xdpgeneric on virtual NICs that don't support native XDP.
5. Status panel goes green: XDP ATTACHED · native · sha256 7c4d…

Layer 1 — eBPF/XDP firewall

The kernel firewall is generated C, not config-driven. The generator lives in XdpEngine.generate_c() inside the agent and emits a self-contained program that:

• Defines three maps:
  • baryon_rl — LRU hash keyed by (saddr, dport) for per-port token-bucket rate limits
  • baryon_udp — LRU hash keyed by source IP for UDP flood counting
  • baryon_stats — per-CPU array (4 slots) for pass / drop_block / drop_rl / drop_udp counters
• Lets ARP and non-IPv4 through unconditionally (so cluster fabrics keep working)
• Hard-codes the SSH port at the top of the path so you cannot lock yourself out — even an "drop everything" config still passes tcp dport 22
• Inlines one branch per blocked CIDR via __constant_htonl masks (no map lookups in the hot path)
• Runs udp_flood_check if enabled, capping per-source UDP pps over a sliding window

Counters are dumped on demand via bpftool map dump -j and accumulated across CPUs. The status panel polls them every 3 seconds.

Endpoints

GET  /v1/xdp/status     # attached? iface, mode, sha256, counters, toolchain
GET  /v1/xdp/rules      # current ruleset
POST /v1/xdp/rules      # validate & save (admin)
GET  /v1/xdp/preview    # preview the generated C
POST /v1/attach         # compile + load + verify (admin)
POST /v1/detach         # ip link set dev <iface> xdp off (admin)

Layer 2 — Identity & attestation

Every agent generates a 32-byte random key at install time at /etc/gluon/agent.key (mode 0600, owned by gluon). Its SHA-256 fingerprint is exposed in /etc/gluon/agent.fpr and printed at the end of install.

The desktop pins that fingerprint on first pair. Any future verification request sends a fresh nonce and expects back an HMAC-SHA256 over nonce || instance-id || timestamp.

The Identity panel also surfaces the live systemd sandbox state: capabilities granted, mount-protection flags, no-new-privs, the currently-loaded XDP object's sha256, and the agent's process ID.

Layer 3 — Audit ledger

/var/lib/gluon/ledger.jsonl is append-only. One JSON object per line. Every entry carries:

The desktop's Ledger panel offers Verify chain — it streams the file, recomputes each line's hash, and reports the seq of the first break (or "OK, N entries").

Layer 4 — Workspace backend

From Workspace ? Backend the desktop will (over SSH):

1. Install Docker if missing
2. Write a docker-compose.yml with three services: postgres:16-alpine, postgrest/postgrest, supabase/realtime
3. Generate a strong DB password, write it into the desktop's encrypted workspace
4. Bring the stack up bound to 127.0.0.1
5. Open a local SSH port-forward so the desktop can reach postgres://gluon:****@localhost:5433

The schema in schema.sql defines users, workspaces, roles, channels and messages. PostgREST gives you a REST + RPC surface bounded by row-level security. Realtime streams DB changes over WebSocket.

Layer 5 — Chat & alerts

The chat panel is a thin client over Realtime + LISTEN/NOTIFY. Owners can create channels; members can post; guests are read-only. The #kernel-alerts channel auto-receives every xdp.attach, xdp.detach and ban event from any paired host. You see drops happen in real time alongside the human conversation.

HTTP API · Gluon agent

All endpoints live on 127.0.0.1:7777. Admin endpoints require Authorization: Bearer <admin.token>.

Public (no auth)

GET  /v1/health         # {ok: true, uptime, version}
GET  /v1/status         # mode + xdp summary + capabilities
GET  /v1/identity       # fingerprint, sandbox snapshot
POST /v1/identity/challenge   # {nonce} ? {hmac, ts}

Admin (Bearer token)

GET  /v1/ledger          # stream last N entries
POST /v1/ledger/verify   # walk hash chain

GET  /v1/xdp/status
GET  /v1/xdp/rules
POST /v1/xdp/rules       # body: {blocked_ips, ratelimits, udp_flood, ssh_port}
GET  /v1/xdp/preview     # text/x-c source preview
POST /v1/attach          # body optional: {rules?, iface?}
POST /v1/detach

Example rule payload

{
  "blocked_ips": ["1.2.3.4", "198.51.100.0/24"],
  "ratelimits": [
    {"port": 80,  "pps": 1000},
    {"port": 443, "pps": 5000}
  ],
  "udp_flood": {"enabled": true, "pps_per_source": 800},
  "ssh_port": 22
}

Operator runbook · Gluon

If you're SSHed into a host directly and want to see what the agent is doing:

# Service health
$ systemctl status gluon-agent
$ journalctl -u gluon-agent -n 200 --no-pager

# Is the firewall attached?
$ ip -d link show eth0 | grep -A1 xdp

# Live counters
$ sudo bpftool map dump pinned /sys/fs/bpf/baryon_stats

# Verify the ledger
$ sudo cat /var/lib/gluon/ledger.jsonl | wc -l
$ curl -sH "Authorization: Bearer $(sudo cat /etc/gluon/admin.token)" \
       http://127.0.0.1:7777/v1/ledger/verify

# Detach (emergency)
$ sudo ip link set dev eth0 xdp off

Baryon Tachyon · runaway-process autopilot

Tachyon is a separate Baryon Systems product. It does not care about firewalls, identity, or chat. Its one job is to watch every Linux process on the host and, the moment one starts to misbehave, throttle it before a human notices. The Tachyon tile in the desktop’s Products panel has its own pairing flow, its own Linux installer, and its own state on disk — you can run it on boxes that have no other Baryon product installed.

What it’s for

• CI runners that occasionally get a fork bomb in a PR.
• Multi-tenant boxes where one customer’s job shouldn’t take down the rest.
• ML training hosts where a stuck process leaks memory until OOM.
• Gameservers and any long-lived workload where “just restart it” isn’t cheap.

Install

From the desktop: Products → Tachyon → Add host. The wizard SSHes into the host and runs a self-contained installer that drops a single binary plus a policy file. No clang, no kernel headers, no Postgres — Tachyon needs none of that.

ssh root@host bash tachyon-install.sh
[tachyon-install] python3 present
[tachyon-install] creating system user (tachyon)
[tachyon-install] writing /etc/tachyon/policy.yaml (default = stop @ 50k syscalls/s for 3s)
[tachyon-install] reloading systemd
TACHYON_INSTALL_OK
TACHYON_FINGERPRINT=D4:E5:F6:…

How it works

• An eBPF tracepoint attached to raw_syscalls:sys_enter increments a per-PID counter in a BPF map. Cost is < 200 ns per syscall on the hot path.
• A userspace loop runs every 250 ms. It pages in the deltas, compares them against the operator policy (syscalls/sec, CPU%, RSS, fd count) and decides whether to trip.
• On trip, Tachyon picks one of two remediation strategies:
  1. SIGSTOP — the process is paused (not killed). An operator can SIGCONT later.
  2. cpu.max=5000 100000 on a fresh cgroup v2 leaf — the process keeps running but is throttled to 5% of one CPU. Useful when SIGSTOP would deadlock a service mesh.
• Every trip is logged locally to Tachyon’s own SQLite store at /var/lib/tachyon/breaks.db. Tachyon does not depend on, talk to, or share state with any other Baryon product.

Policy

/etc/tachyon/policy.yaml is plain YAML. The default config ships with one rule and a safety allow-list:

rules:
  - name: syscall-storm
    match: syscalls_per_sec > 50000 for 3s
    action: sigstop

never_stop:
  - sshd
  - systemd*
  - docker*
  - containerd*
  - tachyon

Safety net

Tachyon refuses to touch PID ≤ 1, the daemon’s own PID, or its direct parent. Operators add additional never_stop globs in the policy file (matched against /proc/<pid>/comm).

Recovery

Trips are listed at GET /v1/circuit/breaks. To release a stopped process call DELETE /v1/circuit/breaks/<pid> — Tachyon sends SIGCONT or removes the throttling cgroup, and logs the recovery.

FAQ

Can I lock myself out with a bad rule?

No. The C generator always emits a hard-coded SSH whitelist branch at the top of the XDP program. tcp dport 22 passes regardless of what's in the block list.

What about IPv6?

The first release filters IPv4 only — IPv6 traffic passes through. IPv6 support is on the roadmap; if you need it sooner please tell us on the demo form.

What kernel features do I need?

Kernel = 5.10 covers XDP, BPF LRU hash maps, percpu arrays and bpftool dump. The agent works without these — it just degrades to "userspace mode" and the firewall panel stays inert.

Is the data plane encrypted?

The desktop reaches every host only via SSH tunnel. End to end TLS on top of that is on the roadmap for releases where you might want to let a teammate reach the desktop's API directly.

How do I uninstall?

sudo systemctl disable --now gluon-agent && sudo rm -rf /etc/gluon /var/lib/gluon /etc/systemd/system/gluon-agent.service /opt/gluon && sudo userdel gluon. That's it — nothing else is touched.

Found a gap in the docs? Email lapizh@icloud.com — every fix earns a credit in the changelog.