Dev Breakfast · 2026-09-16

In an eBPF security agent, the most CPU-intensive part is not policy execution, but rebuilding the path along the parent dentry for every file open to perform policy matching; the author cached the matched policies using a triple of mount namespace ID, mount ID, and inode number, reducing kernel CPU overhead by about 90%. This number looks impressive, but the cache key uses three fields instead of just inode, indicating that the real value is in figuring out where collisions would occur.

eBPF security agent overhead, an inode cache cuts it by 90%

An eBPF security agent's most expensive part is not deciding to allow or deny, but determining 'should this rule even apply to this file'. The author and his brother built this agent, and recent profiling revealed that the real CPU hog is policy matching, not policy execution. Their policies are written by path, with eBPF hooked into LSM's file open hook; every file open rebuilds the path, walking up the parent dentry layer by layer, checking if the file or any ancestor directory matches a policy.

The solution is straightforward: cache 'which policy should apply to this file' by inode. If a match is found, directly allow or deny; if not, take the slow path and write the result back to the cache. The author's exact words were 'this reduced our kernel CPU overhead by about 90%'.

The cache key is three fields: mount namespace ID, mount ID, and inode number. Why not just use inode? Because inode numbers are only unique within a single mount tree; when policies span multiple mount trees, inode numbers can collide. The mount ID marks which tree the file is seen from, and the mount namespace ID prevents cross-namespace reuse of entries. The cache value has two parts: access_index and cache state; the policy itself is stored as a bitmask to save space, and access_index is the corresponding bit position. Implementation uses a BPF_MAP_TYPE_LRU_HASH with max_entries set to 10000.

Performance numbers come from a direct benchmark: opening the same file 200,000 times. Without cache, the kernel consumed 28 billion cycles; with cache, it's 3.03 billion. In the flame graph, tail_call_security_check appears on the stack 89.2%, is_restricted_filepath 81.9%, path_check_callback 63.7%; after adding cache, the latter two shrink to about 0.02% each, essentially disappearing from the graph. Measurements used perf's cycles:k event, counting only kernel-side CPU cost during file open.

Most worth noting is how they handle edge cases. An inode can correspond to multiple paths; hard links are the simplest example—two different paths share the same inode, and a cache key collision would give a wrong conclusion. The author's stance is clear: result accuracy is more important than cache hit rate. Their approach reads the inode's i_nlink, and if greater than 1, skip this cache and fall back to the slow path:

if (BPF_CORE_READ_INTO(&nlink, inode, i_nlink)) {
    return false;
}
if (nlink != 1) {
    inode_cache_stats_inc(INODE_CACHE_STATS_SKIPS_NLINK);
    return false;
}

The author admits this is 'more of a workaround than a real solution', sacrificing some cache coverage, but thinks it's not a big deal. This trade-off is honest: the value ceiling of a cache is determined by its correctness; a fast cache that occasionally gives wrong answers is worse than none.

Viewing the 90% reduction in context: from 28 billion to 3.03 billion, the saved amount is roughly equivalent to removing the entire path traversal workload. And the change is purely internal—users don't need to modify a single line of policy; the agent itself becomes faster. The author says this makes him quite happy.

Incidentally, this repo was recently open-sourced, and everything in the article can be found on GitHub. The original post doesn't mention if any other issues arose after this cache went live, nor does it detail the actual skip rate for i_nlink > 1—to see that number, you'd have to check the stats counters in the repository.

💡 Chef's take: They cache 'policy decision results' rather than file contents, so the real risk surface is hot policy updates—once rules change, this batch of inode caches must be invalidated entirely, which the article does not elaborate on.

Sources:

• Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

Cloudflare reduced origin handshake guess error rate from 52% to 3.7%

TLS 1.3 has a somewhat awkward design: the client must guess the key exchange algorithm in the first packet. Guess correctly, and the handshake completes in one round trip; guess wrong, and the server responds with a HelloRetryRequest (HRR), restarting and costing an extra round trip. Cloudflare opens 45 billion connections daily, and for years has guessed X25519—with over 95% support rate, it seems stable. But testing revealed that for about 30% of origin connections, this choice wasn't optimal; the HRR rate hovered around 52%.

The current approach replaces 'guessing' with 'testing': first probe each origin to see which algorithms it supports and prefers, then use that on the first attempt; if the origin supports post-quantum, use the hybrid scheme X25519MLKEM768. The effect is HRR dropping from about 52% to 3.7%, with p90 handshake latency reduced by over 150 ms. The trade-off isn't free—X25519MLKEM768's keyshare is 1216 bytes, compared to X25519's 32 bytes, causing ClientHello to exceed a single network packet, and some legacy middleboxes and origins fail on fragmentation; early scans showed about 0.34% of origins failed on this. So HRR has been used as a safety valve: initially declare only post-quantum support, actually send a classic keyshare, letting capable origins request a retry. Now this probe logic takes over that role.

For you as a coder, direct changes are minimal, but two things are worth noting. First, post-quantum connections are now automatic; hundreds of thousands of domains are running on it without configuration, so you likely don't know what algorithm your domain's handshake uses—if there are custom middleboxes or legacy gateways in the path, it's worth confirming they can handle a ClientHello over multiple packets. Second, 'harvest-now, decrypt-later' isn't a theoretical threat: traffic recorded today can be decrypted when compute power is sufficient. Cloudflare's self-imposed deadline is to make the internet quantum-safe by 2029, with a practical reason—it's impossible to expect millions of site owners to become cryptography experts, so automation is key. Encryption is shifting from 'remember to turn on the switch' to 'should be correct by default'.

Sources:

• hackernews · iamsyr

Qwen3 voice dual models open-sourced: 63ms first-word latency, price is one-fifth of ElevenLabs

Nari Labs placed its Qwen3-TTS / Qwen3-ASR endpoints on the front row of Coval's voice AI leaderboard. For TTS, Qwen3-TTS Fast has a time-to-first-audio median of 63 ms and WER of 3.8%, both first-tier—latency ranks second, accuracy ranks first, price is $10 / 1M characters, tying for cheapest overall; ElevenLabs Eleven v3 Conversational is 5 times more expensive, Cartesia Sonic 3.6 is 6.5 times more. For ASR, Qwen3-ASR Fast has a time-to-final-segment median of 44 ms, ranking first, WER of 3.6%, ranking second, just one point behind AssemblyAI Universal 3.5 Pro's 3.5%, price is $0.12 / hour, tying for second lowest; the latter is 3.75 times more expensive. There's also a Standard tier: TTS $5 / 1M characters, ASR $0.06 / hour, which is the true lowest price.

Most worth noting is the horizontal comparison within the same model: Alibaba's official Qwen3 TTS Flash Realtime endpoint has WER 8.8%, TTFA median 692 ms; Baseten's dedicated Qwen3-TTS endpoint has WER 6.0%, TTFA 101 ms. The model is the same; the gap is all in inference engineering. Nari says generic engines like vLLM / SGLang aren't suited for multimodal inference, so they wrote a dedicated inference engine for Qwen3-TTS and open-sourced it (github.com/nari-labs/nari-qwen3-tts), pushing latency under 50 ms at 10 RPS. This makes sense: voice models need to output tokens while cutting audio chunks; generic engines' scheduling and KV cache strategies aren't designed for this pipeline.

But don't take rankings as definitive. Coval's leaderboard can change every 30 minutes; this article references a snapshot from 2026-09-14 15:00 UTC, and rankings explicitly exclude dedicated inference endpoints—in other words, this is first in the small circle of 'publicly callable endpoints'. WER is aggregated across datasets; change the language, accent, or add background noise, and rankings will likely reorder. If you plan to use it in production, run it on your own audio first.

For voice Agent builders, the significance isn't who's first, but that the price anchor has been lowered: TTS gets 10,000 characters for ten cents, STT costs ten cents per hour. Previously, 'real-time voice' was a cost item; now it can be designed as a feature. The trade-off is that such small providers' endpoint stability and concurrency limits must be stress-tested yourself; don't find out p99 and p50 are different worlds after going live.

Sources:

• Nari Labs Leads Coval's Voice AI Benchmarks

Microsoft patches fix vulnerabilities, but break audio, remote access, and paste

Windows and Excel's monthly security updates just rolled out, and users discovered audio is gone, remote access won't connect, and paste stops working. Patches fixing vulnerabilities often take daily functions along for the ride; this isn't new on Windows, but for you forced to accept updates, the cost is real: when remote access fails, you might be working from home on a company machine. After installation, don't rush to work—leave time for a rollback.

Sources:

• hackernews · Alephinitesimal

Local single-node S3 alternatives: options beyond MinIO

The original has only the title, no body text, so here's what kind of article it is: the author compares several alternatives for running S3-compatible storage locally on a single node. If you use MinIO to simulate object storage during local development, this is worth a look to see how others choose. As for whether MinIO has actually stopped maintenance, the original title doesn't say that—don't get misled by the draft title.

Sources:

• Alternatives to MinIO for single-node local S3

---

If you have this slow path that rebuilds context every time, would you dare to add a cache layer and go live, or first list the collision conditions clearly? See you tomorrow morning at 8.

This issue selects 5 out of 64 pieces of information from X / Hacker News / GitHub Trending over the past 24 hours (written hourly throughout the day, fact-checked, and compiled in the morning). Content is assisted by LLM, each with original source links; important decisions should be cross-verified.