Skip to content

Security: 19PINE-AI/transparent-offload

Security

SECURITY.md

Security policy

Reporting a vulnerability

Email boj@01.me with "transparent-offload security" in the subject. Please do not open a public issue for a vulnerability.

Include what you would put in a bug report — the command line, the environment variables, the platform — plus what an attacker gains. You should get an acknowledgement within a few days.

What counts

This is a research-grade runtime that loads into another process and rewrites its concurrency behaviour. That is an unusual position, so it is worth being specific about what would and would not be treated as a vulnerability.

In scope

  • The runtime causing an application to return one connection's data to another. Cross-connection data leakage is the most serious thing that could go wrong here.
  • Memory corruption reachable from network input through the runtime's interposers: the fiber stack handling, the per-fiber TLS shadowing, the detector's fault handler.
  • The conflict detector reporting no conflicts where a real cross-fiber read-modify-write hazard exists, since operators rely on that to decide whether enforcement is needed.
  • Anything in the runtime that escalates privilege or executes attacker-chosen code.

Not in scope

  • The emulated accelerator backend (backends/emulated/) and the example servers. These are test fixtures with hard-coded keys and no authentication; they exist to be measured, not deployed. examples/servers/hostile_server.c loses updates on purpose.
  • Test certificates and keys in bench/fixtures/. They are self-signed and regenerable; nothing signs anything real.
  • TOFFLOAD_RT=1 causing priority-inversion deadlock. Documented, intended, and the reason it says not to use it in production.
  • TOFFLOAD_REALMUTEX=1 deadlocking. It exists to demonstrate that the naive mutex deadlocks.
  • Losing updates on unlocked shared state without the detector or enforcement enabled. That is the documented hazard the runtime creates; see docs/safety.md.
  • Anything requiring the attacker to already control LD_PRELOAD or the application binary.

Deployment notes

If you are running this in front of something that matters:

  • Read docs/safety.md first, particularly the section on where the runtime is genuinely unsafe.
  • Run with the detector and check det_conflicts before trusting a workload with unlocked shared state.
  • Do not use TOFFLOAD_RT=1.
  • The runtime has been tested against the servers listed in bench/results/. Yours is not on that list until you test it.

Supported versions

Pre-1.0. Fixes land on main; there are no maintained release branches yet.

There aren't any published security advisories