Cong Wang

Founder and CEO,

[Cong Wang @c0ngwang]

We made co-located TCP up to 7x faster by adding a copy, not removing one.

That sentence should bother you. Every performance engineer is trained to drive copies toward zero. So when we built bpf_sock_splice_pair(), a new BPF kfunc that splices two TCP sockets on the same machine (think service-mesh sidecars, loopback RPC, co-scheduled microservices), our first design did exactly that: a single direct user-to-user copy, the theoretical minimum for an unmodified sockets API.

It was elegant. It was also the wrong tradeoff.

A single copy forces the sender to write straight into the receiver's buffer, which means both sides have to meet at the same instant. That synchronous rendezvous quietly kills batching. The sender can never run ahead, so throughput is capped by handshake latency instead of memory bandwidth.

The fix is a lesson queueing theory has taught for decades: to let a producer outrun a consumer, you need a buffer between them. A buffer costs a second copy, and that second copy is the price of decoupling. Decoupling enables batching, batching amortizes per-message overhead, and owning an in-kernel ring lets the receiver busy-poll, the one thing that finally cracks loopback latency.

The result, measured with netperf at a realistic 1 KB request-response:

- Loopback TCP_RR: 106k to 713k transactions/sec (6.7x)
- Container TCP_RR: 100k to 705k transactions/sec (7.0x)
- No application changes. No new address family. Just BPF pairing ordinary TCP sockets.

We also benchmarked it against AF_SMC's shared-memory loopback, which independently arrived at the same "buffering enables batching" conclusion. Our two-copy ring still comes out ahead of its three-copy path.

The full design story, the dead end we walked into first, and a comparison with AF_SMC:

https://t.co/BTaH86WCnC

The patchset is up as an RFC on the BPF and netdev lists. Reviews and benchmarks welcome.

#LinuxKernel #eBPF #Networking #Performance #TCP #SystemsEngineering #OpenSource

[Cong Wang @c0ngwang]

Wow, my TCP splicing optimization improves the small message (64B) performance by 36x...

[Cong Wang @c0ngwang]

It's me

[Cong Wang @c0ngwang]

Why Rust becomes such a monster... Why?
$ du -h -d 1 target/
2.2Gtarget/release
4.0Ktarget/doc
24Ktarget/tmp
30Gtarget/debug
32Gtarget/

[Cong Wang @c0ngwang]

🚀 sandlock 0.8.0 is out, with run_with_handlers().

sandlock is a lightweight, unprivileged Linux process sandbox (built on Landlock + seccomp). The new API lets you register your own seccomp user-notification handlers, so you can virtualize syscalls for a sandboxed process from ordinary application code, no kernel module and no privileged setup.

To show what that unlocks, this release includes a single self-contained Python file that gives a sandboxed program a read-only, S3-backed view of its filesystem. The program just calls open("/s3/...") and os.stat("/s3/...") and reads objects straight from an object store.

No FUSE. No daemon. No mount. No privilege.

Why do this with syscall handlers instead of a FUSE mount?

✅ No daemon to kill. A FUSE filesystem is a daemon sitting next to your workload. If you are running an untrusted agent, it can signal that daemon to take the filesystem down, or (same user, ptrace allowed) attach to it and read your cloud credentials out of its memory. sandlock's supervisor is the agent's parent, outside the sandbox, unreachable from inside it, and it fails closed.

✅ No mount, no CAP_SYS_ADMIN, no /dev/fuse. It works in the most locked-down unprivileged container, where you often cannot mount FUSE at all.

✅ One policy point for everything. The same supervisor already mediates files, network, process creation, and memory. Object storage becomes just one more handler, with one audit log, instead of a separate mechanism bolted on per resource.

✅ Programmable and private. Decisions can depend on who is asking (pid, argv, open flags), and nothing lands on disk: bytes are served from an in-memory fd, not a local cache directory.

This is built for the execute-only-agents model: giving an untrusted AI agent a controlled view of exactly the resources you choose, with an enforcer it cannot reach.

Take a look:

📖 Extension handlers guide:
https://t.co/owlpT8KTiP

🧩 Full S3 example (openat + statx + newfstatat handlers):
https://t.co/N6NLfKyuSG

⭐ Project and 0.8.0 release:
https://t.co/ZrArsD89s1

#Linux #Security #Sandboxing #seccomp #Landlock #AIAgents #CloudSecurity #OpenSource #Rust #Python

[Manu Arora @mannupaaji]

AGENTS.md
DESIGN.md
CLAUDE.md
SKILL.md
REQUIREMENTS.md
PROPOSAL.md
PLAN.md
.
.
GOD-HELP-ME.md

[Cong Wang @c0ngwang]

I am heading to Minneapolis for Open Source Summit. If you are attending it too, let's meet and chat.

[Cong Wang @c0ngwang]

Use sandlock to block Copy Fail kernel exploit 👀

[Cong Wang @c0ngwang]

branchfs 0.1.1 is out, and it now runs on macOS.

branchfs is a FUSE filesystem with atomic, copy-on-write branching. You take a workspace, fork it instantly, run something speculative against the branch, and either commit the result into the parent or throw it away. No copying gigabytes, no cleanup scripts, no "let me reset my environment" detour.

This is built for the way AI agents actually work. An agent should be able to try an approach, see if it holds up, and abandon it cheaply if it does not. branchfs makes that branch-and-discard loop a filesystem primitive instead of something you bolt on afterward.

Highlights in this release:
- macOS support. branchfs started on Linux, and it now builds and runs on macOS too, so you get the same branching workflow on your laptop. Thanks to @nitin966 for the port.
- FUSE passthrough for near-native read and write I/O.
- Higher throughput from file descriptor caching on the hot read and write paths.
- Symlink and rename support across the FUSE layer, copy-on-write, and branch operations.
- Immediate-parent merge on commit and abort, plus @branch virtual directories for inspecting branch state.
- Storage safety: --max-storage quota enforcement, branch name validation against path traversal, and graceful daemon shutdown.

Prebuilt binaries for Linux x86_64 and macOS arm64 are attached to the GitHub release, and the crate is on https://t.co/dV7mBpdm1Z, so "cargo install branchfs" just works.

I would genuinely like to hear what breaks for you. If you are building agent infrastructure, speculative execution tooling, or just want fast disposable workspaces, give it a spin.

If you are on a Mac, I would especially love for you to try it. The macOS port is fresh, and real-world testing on different setups is the fastest way to shake out the rough edges. Install it, branch a workspace, run something speculative against it, and tell me how it goes.

Repo and releases: https://t.co/oHeYvj0dz3

#rust #filesystem #fuse #aiagents #opensource #macos

[Cong Wang @c0ngwang]

I'm excited to present Fork, Explore, Commit: Linux Primitives for AI Agents Exploration - Cong Wang, Multikernel Technologies with Yusheng Zheng, eunomia-bpf at Open Source Summit + Embedded Linux Conference North America 2026 https://t.co/ztGyEB78Lz @sched

[Cong Wang @c0ngwang]

I'm excited to present KernelScript: Unifying EBPF, Userspace, and Kernel Extensions in One Language - Cong Wang, Multikernel Technologies at Open Source Summit + Embedded Linux Conference North America 2026 https://t.co/p6krbfVgNf @sched

[Cong Wang @c0ngwang]

Introducing KBI: Packaging Linux Kernels as OCI Artifacts

Excited to announce KBI (Kernel Bundle Image), an open-source tool that packages Linux kernels as standard OCI artifacts.

As part of our Multikernel work, we needed a clean way to package, distribute, and manage kernel artifacts independently from the OS. That is KBI.

The problem it solves: today the kernel is embedded inside OS images, tangled with the root filesystem. Updating the kernel means rebuilding the entire image. Kernel modules and eBPF programs have no formal way to declare or verify compatibility. The kernel has no independent lifecycle.

KBI changes this by treating the kernel as a first-class, independently versioned artifact.

What it does:

- Packages kernel artifacts (vmlinuz, modules, config, BTF, initrd, firmware) into a single OCI image with typed layers and structured metadata
- Computes a deterministic Kernel Build Identity (KBI ID) from kernel content, enabling explicit compatibility binding
- Supports ModulePacks and BPF Packs for out-of-tree kernel extensions, with build-time validation of module compatibility via vermagic and BTF verification
- Works with any OCI-compliant registry: Docker Hub, GHCR, Quay, ECR, Harbor
- Installs to bare metal or VM filesystem layouts

The core idea: a kernel is a governed resource, not an implicit dependency. It deserves its own packaging, versioning, distribution, and compatibility model.

KBI is built in Go, licensed under Apache 2.0, and available now on GitHub:
https://t.co/3tfIklVhww

I would love to hear from anyone working on kernel management at scale, bootc/image-based Linux, or eBPF toolchains. Feedback and contributions are welcome.

#linux #kernel #containers #oci #opensource #ebpf #infrastructure

[Cong Wang @c0ngwang]

Security Update: PraisonAI Now Ships with Sandlock Integration

We are pleased to announce that PraisonAI is the first public project to adopt Sandlock, delivering kernel-level code isolation for AI agent execution and bringing enterprise-grade security to autonomous and LLM-generated code workflows.

As AI agents increasingly execute untrusted, model-generated code in production environments, process-level sandboxing is no longer sufficient. PraisonAI's new SandlockSandbox leverages Sandlock to enforce isolation directly at the kernel, closing critical gaps that traditional subprocess sandboxes leave open.

What this means for teams building with PraisonAI:

1. Kernel-enforced filesystem allowlisting, preventing unauthorized access to credentials, SSH keys, and system files.
2. System call filtering via seccomp-bpf, blocking dangerous operations before they reach the kernel.
3. Network isolation to prevent data exfiltration from agent-executed code.
4. Fine-grained resource limits across memory, CPU, processes, and execution time.
5. Approximately 5ms startup overhead, roughly 20x faster than Docker, with comparable security guarantees.
6. No root privileges required, enabling user-space security that deploys anywhere.
7. Drop-in replacement that implements the same SandboxProtocol as existing backends.

SandlockSandbox is available today as an optional dependency via pip install "praisonai[sandbox]" and integrates seamlessly with existing Agent execution configurations. Teams running multi-tenant code runners, untrusted code evaluation pipelines, or agent-based automation can migrate with a single line change.

This adoption reflects our continued commitment to building AI infrastructure that is production-ready, secure by default, and trusted by enterprise teams.

Explore the integration and documentation in the PraisonAI repository: https://t.co/wdp258sy0n.

#AIAgents #EnterpriseAI #Security #PraisonAI #Sandlock #Linux #DevSecOps

[Cong Wang @c0ngwang]

Use `sandlock --dry-run` to mock package installation 👀

[Cong Wang @c0ngwang]

I just installed a Rust crate and it pulled 270 dependencies… Is Rust competing with Node.js now, or did Cargo secretly run npm install behind my back? Help me out, Rust folks. 🫠

[Cong Wang @c0ngwang]

@lagosrui That's right, the trust model of Agentry is agents are trusted, since they manages everything, including orchestration.

[Cong Wang @c0ngwang]

AI agent sandboxes got security wrong. Here's why.

The industry is spending millions wrapping AI agents in containers and microVMs. But the threat model doesn't match the solution.

1. Agents aren't adversaries. They follow prompts. The real threat is prompt injection and accidental errors, not kernel exploits. You need policy, not a hypervisor.

2. Isolation isn't security. A Firecracker microVM can't stop an agent from reading your SSH key if you mounted it. What matters is what's accessible inside the sandbox, not whether it can escape.

3. You almost never needed root. Containers and microVMs require privileged infrastructure to create isolation. That privilege becomes the prize when isolation fails. An unprivileged sandbox has a strictly smaller attack surface.

4. One box for all tools is no security at all. If every tool shares the same permissions, the sandbox policy is the union of everything. Per-tool-call isolation is the only way to enforce least privilege.

We built Sandlock to get this right: deny by default, allowlist by path, enforce at the kernel level, no root required. Process fork + Landlock confinement in under 1ms per tool call.

Read the full analysis: https://t.co/f1q71L9rEu

#AIAgents #Security #Linux #OpenSource #Infrastructure

[Cong Wang @c0ngwang]

Excited to announce that I'll be presenting KernelScript at the eBPF Developer Conference in China on April 18!

KernelScript is a domain-specific language for eBPF development that compiles a single source file into eBPF bytecode, userspace binaries, and even kernel modules, all from one unified source.

Writing eBPF programs today means juggling raw C with libbpf, managing complex kernel APIs, coordinating userspace loaders, and handling endless boilerplate. KernelScript eliminates this friction with:

- Single-file, multi-target compilation via simple attributes like @xdp and @kfunc
- Automatic infrastructure for tail calls, dynptr management, and BTF registration
- Type-safe guarantees that catch errors at compile time, not at runtime
- Natural multi-program coordination with shared maps and state

This will be the first public presentation of KernelScript. I'm looking forward to sharing what we've been building and getting feedback from the eBPF community.

See you in China!

https://t.co/HkfFeVsofG
https://t.co/6gZBcf7ZQe

#eBPF #KernelScript #Linux #Kernel #OpenSource #Programming

[Cong Wang @c0ngwang]

@lagosrui Right, this is decision trace. I built Agentry with this feature: https://t.co/IC4p9tCpLY

[Cong Wang @c0ngwang]

@lagosrui You mean audit?