DEV Community: Bartosz Osiej

700 US county domains, one DNS record apart from safe

Bartosz Osiej — Fri, 02 Oct 2026 11:09:03 +0000

I audited DNS for 700 US county and K-12 government domains this month. Passive lookups only — MX, TXT, CAA. No scanning, no probing, no service enumeration. Every record parsed per RR record and confirmed against at least two independent resolvers.

The numbers:

286 of 700 (41%) publish no DMARC record at all
only 97 (14%) are at p=reject
156 are at p=none — detectable, still delivered
227 have SPF ending in ~all — soft-fail, spoofed mail lands anyway
56 out of 700 are actually enforcing (SPF -all + DMARC p=reject)

p=none is not "we have DMARC"

p=none asks receiving servers to watch and report. It does not ask them to refuse anything. Spoofed mail claiming your domain still reaches the inbox — it's just marked, and users are trained to click through the mark. p=reject is what turns detect into do not deliver.

The order that works

_dmarc.example.gov. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.gov"

Start at p=quarantine with a rua= address. Read the aggregate reports until the only senders listed are ones you recognise. Then move to p=reject. Only then tighten SPF from ~all to -all.

Deploying -all before the reports are clean is the single most common way a DMARC rollout gets rolled back — one legitimate sender gets dropped, mail stops, and the record gets deleted.

The audit was wrong the first time

Worth publishing, because it's the part most write-ups skip.

The first pass concatenated each TXT RR set into one string and tested for a v=spf1 prefix. Any leading verification record — MS=, an Apple domain-verification TXT — broke the match, and the domain came back as "no SPF". A second pass used a 3-second resolver timeout under 48-way concurrency and recorded those timeouts as "record absent".

Between them, 22 of the first 82 contact emails carried a finding that wasn't true. All 22 were corrected by email the same day.

The corrected pass: parse per record, confirm with two or more resolvers, and if the answer isn't confirmed, publish nothing rather than guess. A number that gets forwarded to an auditor should survive dig.

Full report

Aggregates, methodology, the list of domains with no DMARC record, and a mailto that hands you your own domain's records as plain text:

https://hartwell-labs.pl/report/

If you run one of these domains: mail me and you get your exact SPF, DMARC, CAA and MX as they resolve today. Free, no call, no pitch — enough to hand to whoever holds your DNS.

Building detection and response for Linux in the meantime — eBPF, no kernel modules, one static binary. If any of your systems run Linux and the mail-gateway view isn't the whole picture: https://hartwell-labs.pl/talus.html

Killing ransomware from inside the kernel: writing the response engine for an eBPF monitor in Rust

Bartosz Osiej — Thu, 01 Oct 2026 11:14:23 +0000

TL;DR

In part 1 I showed how an eBPF monitor catches ransomware behavior: hook execve/openat/unlink/mkdir, stream events to userspace, score a 1-second sliding window per PID.

This is the other half: what happens after the verdict fires. Not another alert. Not a dashboard row. The process dies, in the same second, by design.

Three parts: why a plain SIGKILL from userspace is enough (no LSM, no kernel module), how I handle the race conditions, and how the agent sandboxes itself so a bug can't turn your EDR into the attack.

All code below is from Talus, MIT, written in Rust.

The decision point: a sliding window, not a signature

First, the verdict itself. Ransomware has one loud fingerprint: it opens files in bulk. So the monitor keeps a per-PID deque of timestamps and scores it every event:

let now = Instant::now();
let window = self.windows.entry(ev.pid).or_default();
let cutoff = now - Duration::from_secs(WINDOW_SECS);
while window.front().is_some_and(|t| *t < cutoff) {
    window.pop_front();          // evict events older than the window
}
window.push_back(now);

if self.threshold > 0 && stats.window_opens == self.threshold {
    stats.alerts += 1;
    // verdict: this PID is mass-opening files RIGHT NOW
    ...
}

WINDOW_SECS is 1. If a process crosses the open-rate threshold inside that second, it gets a verdict. The same pattern the big EDR vendors describe in marketing blogs - except here you can read the whole engine in one file.

Why SIGKILL from userspace is enough

The obvious objection: "if your detection runs in the kernel, why not kill in the kernel?" You can do that with an LSM or a bpf_send_signal() helper. I deliberately don't.

Reasons:

kill(2) is one syscall. The event already traveled kernel → userspace through a per-CPU perf buffer with zero-copy handoff. The round-trip adds microseconds, not seconds. The ransomware's own encryption loop is orders of magnitude slower than that.
Policy lives in userspace. Thresholds, allowlists, the neural sidecar (MeMLP), audit logging - all of it is ordinary, debuggable Rust. Kernel code is where correctness goes to die and panic is not an option.
The kernel side stays dumb. A dumb kernel program is a safe kernel program. All the eBPF side does is watch and report.

So the response path is exactly what you'd write by hand:

/// Send SIGKILL to a process. Returns true on success.
fn kill_process(pid: u32) -> bool {
    // SIGKILL cannot be caught, so the target process will terminate.
    let rc = unsafe { libc::kill(pid as i32, libc::SIGKILL) };
    rc == 0
}

And it's wired straight into the scoring loop:

if self.auto_kill {
    let result = kill_process(ev.pid);
    outputs.push(Output::Action(ResponseAction {
        ts: ev.ts.clone(),
        pid: ev.pid,
        comm: ev.comm.clone(),
        action: format!("SIGKILL sent to PID {} ({})", ev.pid, ev.comm),
        success: result,
    }));
}

(Listings abridged - error paths and logging trimmed.)

The race conditions nobody talks about

Auto-kill means your monitor is now allowed to end processes. Two races matter.

Race 1: kill on verdict, not on first event. A naive design kills the process the moment it sees one suspicious open. That's how you eat a false positive and murder your database. The verdict only fires when the rate crosses the threshold inside the window - so a process that legitimately touches many files (a build, updatedb, a backup job) either stays under the threshold or gets killed because it genuinely looks like ransomware, which is a tuning conversation, not a coin flip.

Race 2: PID reuse. The PID comes from the kernel as u32 and goes back into libc::kill as i32. Between the event and the kill, that PID could theoretically die and be reused. The window is tiny (the verdict is computed on the same event that triggered it, microseconds later), and SIGKILL to a recycled PID is bad but bounded. A full fix would verify /proc/<pid>/comm matches the reported process name before pulling the trigger - it's on the roadmap, and I'd rather ship the honest version than claim a perfect one.

What you do not get: catching file #1. The first opens of a real ransomware run will land. The design goal is narrower and honest: the attacker gets seconds, not your whole disk, and definitely not your backup job that started at 2 AM.

Testing auto-kill without wrecking your machine

You cannot test a response engine by running real ransomware. You don't need to. Ransomware's fingerprint is "opens files in bulk", so the test is just that:

# fake ransomware: 500 file opens as fast as the shell can go
for i in $(seq 1 500); do
  touch /tmp/v$i.enc && cat /tmp/v$i.enc > /dev/null
done

Run the monitor in observe mode with a low threshold first, confirm the alert fires, then flip on --auto-kill and run the same loop. The loop gets SIGKILLed mid-run - usually inside the first second, well before 500.

To keep even that controlled, run the victim inside a throwaway scope:

systemd-run --user --scope \
  bash -c 'for i in $(seq 1 500); do touch /tmp/v$i.enc; cat /tmp/v$i.enc >/dev/null; done'

Same syscall pattern, same verdict, and if anything goes wrong the blast radius is one scope you can systemctl away. I run this against my own desktop daily - a week of normal usage in observe mode (browsers, builds, editors) produced zero false positives, which is the number that actually matters for an auto-killing agent.

The agent must be unable to become the attack

Here's the part I care about most. Your response engine just got permission to kill arbitrary processes, loaded an eBPF program, and holds capabilities. If someone compromises the agent, they don't need ransomware anymore - they have your EDR.

So Talus strips itself down before it touches a single event. Step 1: drop every capability it doesn't strictly need:

let mut keep = HashSet::new();
keep.insert(CAP_BPF as u32);        // load/attach eBPF programs
keep.insert(CAP_PERFMON as u32);    // perf buffers
keep.insert(CAP_NET_ADMIN as u32);  // some eBPF program types

let to_drop: Vec<u32> = caps.difference(&keep).copied().collect();
for cap in &to_drop {
    // PR_CAPBSET_DROP = 24
    let ret = unsafe { libc::prctl(24, *cap as i32, 0, 0, 0) };
    ...
}

CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, everything else - gone, via the capability bounding set, so no child process can get them back either.

Step 2: seccomp. The agent builds a syscall allowlist (it needs a surprisingly short one: perf setup, kill, logging, that's mostly it) and installs a BPF filter so anything outside the list returns EPERM.

Step 3: Landlock (kernel ≥ 5.13). The filesystem gets a read-only ruleset over exactly the paths eBPF needs:

let allowed_paths: Vec<(&str, u64)> = vec![
    ("/sys/kernel/debug", LANDLOCK_ACCESS_FS_READ_DIR),
    ("/sys/fs/bpf",       LANDLOCK_ACCESS_FS_READ_DIR),
    ("/proc",             LANDLOCK_ACCESS_FS_READ_DIR),
    ("/dev/null",         LANDLOCK_ACCESS_FS_READ_FILE),
    ("/dev/urandom",      LANDLOCK_ACCESS_FS_READ_FILE),
    ("/tmp",              LANDLOCK_ACCESS_FS_READ_DIR),
];

A compromised agent on a Landlocked kernel can read BPF maps and process info. It cannot write your disks. That asymmetry - "can kill, can't touch data" - is the whole design.

Numbers

From my desktop, sustained: ~280k events/s at ~7.6% CPU, per-CPU perf buffers, zero-copy handoff. Single static binary, ~2 MB, no runtime dependencies. Install path: pip install talus-process-monitor && talus-monitor install.

Try it / next steps

Repo (MIT): https://github.com/BartoszOsiej/talus-process-monitor
Part 1 (detection): Detecting ransomware with eBPF in Rust

If you run Linux servers and you try it in observe mode, I genuinely want to hear what your open-rate distribution looks like - threshold defaults are the hardest part of this whole thing, and real fleets beat my desktop every time.

(For teams that want the response layer managed - web dashboard, license management, support - that's the Enterprise edition. The detector and everything you just read is MIT.)

Externum launches today: one typed source Python, Bash or bytecode (with honest benchmarks)

Bartosz Osiej — Mon, 21 Sep 2026 15:32:51 +0000

One statically typed source compiles to readable CPython, a standalone set -euo pipefail bash script, or a source-less bytecode artifact. The compiler is written mostly in itself, bootstrapped from a 6.4 KB Python stub.

Today Externum is launching (Show HN + DevHunt launch week). This post is the honest version of that story: what it does, what it's bad at, and the numbers I'd want to see before trusting any "multi-target compiler" pitch.

The three backends

Python target — emits plain CPython source. Typed source in, debuggable Python out; you can review the emitted file in a normal PR.
Bash target — emits a standalone set -euo pipefail script. Functions become bash functions with local params, recursion works via $(...) capture. Where bash has no equivalent (lists/dicts/classes), the compiler warns loudly instead of silently emitting junk. The first version silently produced empty files — which is how I learned that "empty output, exit 0" is the worst failure mode a compiler can have.
Bytecode target — a .exbc artifact run by a small VM. For "distribute the tool, not the code".

A pipeline operator x |> f(a, b) desugars to f(x, a, b) in every backend, including the VM.

The honest numbers

My first benchmark claim was wrong: I measured the CLI's code-generation mode instead of execution and briefly believed the Python path was 4.5× faster than CPython. Real numbers after fixing the harness:

transpiled-Python path: ~1.6× slower than hand-written CPython (the cost of the typed multi-target story)
~11× faster than bash on the same arithmetic loop
VM: ~30× slower — it exists for source-less distribution, not speed

If a benchmark in a language launch looks too good, assume the harness is measuring the wrong thing until proven otherwise. Mine was.

Engineering facts

~380 tests, differential harness in CI: every backend runs the same suite and the outputs must agree — that harness found 3 real VM bugs that unit tests missed
self-hosted: the compiler is written in Externum, bootstrapped from a minimal Python stub
MIT, self-hosted, browser playground, pip install externum

Launch week

You can also vote for Externum on DevHunt this week (launch week 22–29.09): https://devhunt.org/tool/externum

The code is MIT and free forever. If you want the curated path: the Pro Pack (70+ exercises with solutions + a 10-page production guide on choosing between targets) is $29 instead of $50 this week with code LAUNCHWEEK — link in the repo README.

Ask me anything here or on the HN thread — especially about the parts you think are wrong.

Externum — a typed language that compiles to Python, Bash and bytecode (Show DEV)

Bartosz Osiej — Mon, 21 Sep 2026 13:39:21 +0000

I've been building Externum — a self-hosted, statically typed language whose backends are runtimes that already exist everywhere:

Python target — emits readable CPython source (code-review friendly)
Bash target — standalone set -euo pipefail\ scripts; unsupported constructs warn loudly instead of silently emitting junk
Bytecode target — .exbc artifacts run by a small VM, no source needed

The pipeline operator x |> f(a, b)\ works on every backend. The compiler is self-hosted (bootstrapped from a 6.4 KB Python stub), every backend is tested against the others by a differential harness in CI, and the benchmark suite found 3 real VM bugs that unit tests missed.

Honest numbers: 1.6x slower than CPython, 11x faster than bash. ~380 tests. MIT. On PyPI (pip install externum\).

Repo: https://github.com/BartoszOsiej/externum
Playground (runs 100% in browser): https://hartwell-labs.pl/externum/play.html
Live on DevHunt this week: https://devhunt.org/tool/externum

Feedback welcome — especially on the bash backend's design tradeoffs (what to emit when the typed semantics can't map cleanly).

showdev #python #compilers #opensource

I ship open-source security tools solo — here's the full stack, the pricing, and the (zero) revenue so far

Bartosz Osiej — Mon, 21 Sep 2026 07:52:07 +0000

TL;DR

I'm a 19-year-old solo developer building security and devtools under the name Hartwell Labs. Everything is MIT-licensed and free. Two weeks ago I wrapped paid products around two of them — and I'm documenting the whole experiment, including the part nobody likes to publish: revenue so far is exactly $0.

This post is the full stack: what the tools do, what I sell, why the code stays free, and what I've learned about the difference between downloads and dollars.

The free stack (what you can take today, no money involved)

talus-process-monitor — a ransomware detection & response agent for Linux. It hooks execve/openat tracepoints with eBPF (via aya), streams events through per-CPU perf buffers, counts openat calls per PID in a 1-second sliding window, and SIGKILLs the process when it crosses the threshold. ~280k events/s at under 8% CPU, zero false positives in simulation, MIT.

externum — a self-hosted typed language that compiles to readable Python, standalone Bash (set -euo pipefail, real functions, recursion), and its own .exbc bytecode VM. ~380 tests, differential harness in CI that runs every case through all three backends, MIT, on PyPI (431 installs last month).

pqbit — a post-quantum Bitcoin experiment: ML-DSA-44/SLH-DSA signatures from genesis, UTXO + PoW node in Rust, fair-launch constitution. Early, public, and open for design review.

What I actually sell

Talus Enterprise Pack — $50: a deployment & operations guide for running the detector in production — tuning the threshold per workload, dealing with backup-tool false positives, systemd hardening, alert routing, and a support channel. The binary was always free; this is the path from "cool demo" to "running on my servers".

Externum Pro Pack — $29: a 10-page production guide for the language — choosing between the three targets, the ownership model, the real-world workflow I use, troubleshooting. Delivered by email within 24h (honest trade-off: Polar's file-delivery API has a checksum bug, so delivery is manual until they fix it).

Why charge for guides instead of the code

Three reasons, in order of honesty:

The code benefits more from being free than from being paid. MIT got talus into awesome-list PR queues, got externum 431 PyPI installs, and got strangers talking to me on Mastodon. A paywall on a 2-week-old repo would have bought none of that.
What people actually lack is not the binary — it's operational judgment. The tuning thresholds, the false-positive triage, the "which target do I pick" decision. That's worth packaging.
$29–50 is a tip with a deliverable attached. I'm not pretending this is enterprise pricing. It's "if this saved you an hour, here's a way to say thanks that gets you something back".

The numbers so far (the part most posts skip)

Downloads: externum 431/month on PyPI — the only channel with real organic pull
GitHub stars across 10+ repos: ~1 total (yes, really)
Mastodon followers: 6. Bluesky: 6. Telegram channel: 2 people (hi, mom)
Polar orders: 0 across both products
Cold outreach: ~110 emails to media/newsletters over 10 days, one article accepted (LinuxSecurity, publishing this week), one legend of the industry reacted with a single emoji — which honestly made my week

So: distribution is the bottleneck, not the product, and not the price. The free code travels; the paid wrapper hasn't moved at all yet. I suspect the missing piece is trust surface — 0★ repos and a fresh brand asking for $50 is a hard sell no matter how good the README is. The experiment now is whether published writing (this post, the LinuxSecurity article, upcoming Show HN launches) converts better than cold email did.

If you want to follow along

Everything free: github.com/BartoszOsiej
Talus Enterprise Pack ($50)
Externum Pro Pack ($29)
Support Session — $150: a 60-minute call about deploying talus in your environment — threshold tuning, false-positive triage, systemd hardening — plus a written config summary.
Build log: t.me/hartwell_info

Next milestone I'll report on: first sale, or the first piece of evidence that this pricing model is wrong. Both are useful data.

🎉 Launch Week Deal (Sep 22–29)

The Externum Pro Pack (70+ exercises, full solutions, companion e-book) is $29 instead of $50 with code LAUNCHWEEK — max 100 redemptions.

→ Get the Pro Pack with LAUNCHWEEK

Also: we're on DevHunt this week — if the article was useful, a vote helps other devs find the language.

This week only (Sep 22–27): code WEEK30 = 30% off the Support Session ($150 → $105) and the Enterprise license ($50 → $35). The checkouts above apply it on the page.

I'm Building a Post-Quantum Bitcoin in Rust — and a Test Caught a Real Consensus Bug Tonight

Bartosz Osiej — Sun, 20 Sep 2026 20:38:42 +0000

Most ransomware tools stop at detection. Most Bitcoin forks stop at marketing. This post is about neither — it's about building a Bitcoin whose signatures survive Shor's algorithm, and what "fair launch" means when you actually mean it.

pqbit is open source, phase 2 just shipped, and this is the honest state of it.
Repo: https://github.com/BartoszOsiej/pqbit

The thesis, in one paragraph

~7M BTC sit in quantum-exposed addresses — ECDSA public keys revealed on-chain by old P2PK outputs and reused addresses. BIP-360 (P2MR) was merged into the Bitcoin BIPs repo in February 2026, so the ecosystem agrees the problem is real. But Bitcoin moves slowly by design, and a migration touching every wallet is a decade of debate. pqbit skips the debate: the chain is born post-quantum. Not a faster Bitcoin, not a token sale — one thesis, executed cleanly.

What shipped today (phase 2)

pqbit-core — UTXO transaction model with canonical sighash, signatures via bitcoinpqc: ML-DSA-44 (FIPS 204) as primary, SLH-DSA-SHA2-128s (FIPS 205) as the conservative alternative. No ECDSA fallback at the consensus layer — that's the entire point.
pqbit-node — testnet chain engine: blocks, SHA-256d PoW (leading-zero-bits difficulty), coinbase with a height commitment, UTXO set with ML-DSA spend authorization, and a CLI miner.
9/9 tests — including a double-spend test that caught a real bug during development.

The bug the test caught (the good part)

The first coinbase design stored the block height in the signature field. Sounds fine — except the sighash preimage commits prevouts and outputs but not signatures. Signatures are witnesses, not committed data. Result: every coinbase hashed to the same txid, block after block. The UTXO set happily re-created the same output every block, and a legitimate "spend" of it succeeded twice.

If that survived to a real network, it would be a consensus failure — minted outputs reappearing like ghosts. The fix follows Bitcoin's own pattern: commit the height in the prevout reference (prev_txid[0..8], little-endian). Prevouts are committed, so the height now is too. One test, one real protocol bug, one clean fix — in an evening, not after mainnet.

// before: height in the signature field (NOT committed by sighash)
signature: height.to_le_bytes().to_vec()

// after: height committed in the prevout (sighash commits prevouts)
let mut prev = [0u8; 32];
prev[0..8].copy_from_slice(&height.to_le_bytes());

Why the fair-launch constitution is written like a legal document

Zero premine. Zero presale. Founder stash capped at 100 coins, single public address, published at genesis — and never moved. Moving one coin ends the project's own narrative, and everyone can watch that address forever. That's not a marketing line; it's a reputational bond with an observable state.

The kill criteria are equally public: fewer than 50 non-founder nodes six months after genesis means the coin experiment freezes and pqbit returns to pure research. Sunk cost kills more projects than competitors do — we pre-signed the exit.

What's deliberately undecided

The PoW algorithm. CPU-friendly maximizes early distribution but botnets exist; "ASIC-proof" claims age badly. The honest position is memory-hard-leaning, with the decision made from testnet data, not vibes. Same for block interval (5 vs 10 minutes). GENESIS.md is a draft open for public review — tear it apart before genesis, not after.

Where this goes

Phase 3 is p2p networking. Then an explorator, a whitepaper, and — only when the founder says go — a public genesis with a timestamped fair launch. Every step ships in the open.

Repo: https://github.com/BartoszOsiej/pqbit
Landing: https://bartoszosiej.github.io/pqbit/
GENESIS draft: https://github.com/BartoszOsiej/pqbit/blob/master/GENESIS.md

If you know post-quantum crypto or consensus internals and want to find holes in the design before it grows — the issues tab is open. That's exactly the review GENESIS.md is asking for.

Your Antivirus Only Watches. Mine Kills: Building a Detect-and-Respond Agent in Rust + eBPF

Bartosz Osiej — Sun, 20 Sep 2026 18:50:01 +0000

Most ransomware "solutions" stop at detection: an alert, a dashboard row, an email you'll read tomorrow. By then the attacker has already encrypted the shares.

I wanted the other thing: the process dies the moment the verdict fires. This post is about how Talus does that in Rust, with eBPF doing the watching and a response layer doing the killing — and what it took to keep the whole pipeline at ~280,000 events/second on ~7.6% CPU on a live desktop.

Talus is MIT-licensed and open source: github.com/BartoszOsiej/talus-process-monitor — demo GIF included, it really does SIGKILL the ransomware simulator in the terminal.

The shape of the problem

Ransomware is boring to detect in theory: it opens a lot of files, very fast. The hard parts are:

Seeing the opens without slowing them down. Every file open goes through the kernel — if your monitor adds latency there, you're taxing every process on the machine.
Not killing rsync or your build system. A naive "too many opens = ransomware" rule murders backup jobs and cargo build.
Acting faster than the encryptor. Detection that arrives after the first directory is wiped is just forensics.

Architecture: kernel watches, userspace thinks, response acts

Talus is a pipeline, and every stage exists to keep stage 1 cheap:

KERNEL SPACE (eBPF tracepoints, Linux 5.8+)
   │  hooks syscalls at the source — no LD_PRELOAD, no FUSE
   ▼
per-CPU perf buffers  ──►  zero-copy ring  ──►  userspace detection engine
                                                     │  per-PID sliding window
                                                     ▼
                                          TUI / JSON / WebSocket / Prometheus
                                                     │  verdict
                                                     ▼
                                               response layer (SIGKILL)

Why this split works:

eBPF tracepoints mean zero drivers and zero kernel patches. The probe is verified by the kernel before it runs — it cannot crash the box.
Per-CPU perf buffers mean no cross-CPU lock contention. Each core streams its own events; nothing serializes.
Zero-copy handoff to userspace means the detection engine reads events without copying them again.

Detection: a 1-second sliding window per PID

The heuristic is deliberately simple: per-PID file-open rate inside a 1-second sliding window. Cross the configurable threshold and the verdict fires.

Sliding (not fixed) windows matter here. With fixed buckets, a bursty process that opens 200 files in 50ms every second can hide between samples. A sliding window sees the burst inside the second.

To cut false positives, the file ranking layer scores most-opened files with Shannon entropy — encrypted or randomized filenames stand out from normal workloads immediately.

And the threshold is yours to set: watch-mode for auditing, low-threshold + auto-kill for EDR mode.

Response: yes, it kills

The response layer sends SIGKILL to the offending PID the moment the verdict fires. Not "quarantine eventually", not "notify admin". Kill, then log, then alert.

Is SIGKILL aggressive? Yes. That's the point — ransomware doesn't pause for your opinion. If you want to watch first, run monitor-only mode. The demo in the repo shows exactly this: terminal 1 runs Talus with a low threshold and auto-kill, terminal 2 runs a mass-file-encryption simulator, and Talus ends it mid-run.

The performance work that actually mattered

Getting to 280k events/s at ~7.6% CPU was mostly subtraction:

Don't copy what you can reference. The zero-copy ring between kernel and userspace removed an entire memcpy stage.
Don't aggregate what you can count. The eBPF side does minimal work per event — increment a map entry, emit when needed. The sliding-window math lives in userspace, where a bug costs a panic, not a kernel oops.
Let each CPU mind its own business. Per-CPU buffers beat one big shared buffer by not fighting over locks at the busiest moment (an attack is precisely when events spike).

The full data-flow diagram and pipeline stages are documented in ARCHITECTURE.md.

Try it in 30 seconds

# monitor-only
talus monitor

# full EDR mode: detect + auto-kill
talus monitor --kill --threshold 50

Second terminal, if you want to see a verdict fire:

# ransomware-like mass file-open burst
for i in $(seq 1 10000); do echo x > /tmp/victim_$i; done

(On a throwaway VM or container, like any security demo.)

What's next

Roadmap items I'm working through: per-process allowlists tuned for build/backup workloads, and richer response actions beyond SIGKILL. The enterprise maturity report (level 4/20 path, priority patches, license) is on the landing page for teams that need a paper trail:

Landing + docs: https://hartwell-labs.pl/talus-process-monitor/
Full docs hub: https://bartoszosiej.github.io/Docs/
Repo: https://github.com/BartoszOsiej/talus-process-monitor

If you build something on top of it — or it saves you from a real incident — I want to hear that story in the comments.

Externum: a typed language that transpiles to Python and Bash — and its own benchmark caught two real bugs

Bartosz Osiej — Sat, 19 Sep 2026 16:35:22 +0000

TL;DR

Externum is a statically-typed language I've been building that compiles one program three ways: to plain readable Python, to standalone Bash (a real set -euo pipefail script, no interpreter dependency), and to a .exbc bytecode artifact that runs on a small VM without shipping the source. The compiler is written mostly in Externum itself. This post is about the design trade-offs of multi-target transpilation, what the benchmark actually proved (and what my first, wrong benchmark claimed), and the two real VM bugs the benchmarking process exposed — root-caused and fixed within a day.

Try it in the browser first: playground (no install). Repo: github.com/BartoszOsiej/externum · pip install externum · MIT.

Why transpile to other languages at all

Writing a new language is easy; the hard question is: what does your user run when you're not there? Every compiled language answers with "a binary for each OS × architecture you support." That's a support burden a solo maintainer cannot carry — so Externum never answers it. Instead it leans on runtimes that already exist everywhere:

Python is on every server, laptop, and CI image on earth. Transpiling to plain CPython source means the user ships text files, can read and debug the output, and inherits the entire ecosystem for free.
Bash is in every Unix. If your program's backend compiles to a portable script, "installation" means scp + chmod +x.
The bytecode VM answers the third question: what if the user wants to distribute their tool without shipping source? Compile once to .exbc, hand the artifact to the VM — the source never leaves your machine.

None of this is a new insight (Lua did the "embed everywhere" thing decades ago), but making all three targets first-class, same-source outputs is the part I wanted.

What the same program looks like on every target

def fact(n: Int) -> Int:
    if n <= 1:
        return 1
    return n * fact(n - 1)

print("6! =", fact(6))

externum demo.ext --target python produces ordinary Python you could ship as-is:

def fact(n):
    if n <= 1:
        return 1
    return n * fact(n - 1)

print("6! =", fact(6))

--target bash produces a real script — functions become bash functions with local params, recursion works, defaults become ${2:-default}:

#!/usr/bin/env bash
set -euo pipefail
fact() { local n="$1"; if [ "$n" -le 1 ]; then printf '%s\n' 1; return 0; fi
         printf '%s\n' "$(( n * $(fact $(( n - 1 )) ) ))"; return 0; }
echo "6! = $(fact 6)"

And --target bytecode writes a .exbc artifact (magic EXBC + version + payload) that externum run demo.exbc executes without ever seeing the source. Constructs a target can't express (lists/dicts/classes in bash) produce warnings, never silent empty output — the old bash target once "compiled" by emitting nothing, and an empty file with exit code 0 is the kind of lie that costs someone a weekend.

The benchmark: including my own false start

I benchmarked the arithmetic loop (2M iterations, identical output verified across implementations) with hyperfine. My first measurement was wrong — I'd invoked the CLI without a subcommand, which transpiles and prints the generated code instead of running it. That produced a flattering 4.5×-faster-than-CPython number, which I very briefly believed before noticing the output wasn't the program's output. HN would have found that in minutes; putting a wrong number in a README is how a Show HN dies.

The honest numbers (i7-4610M, hyperfine, methodology + repro):

Path	Time	vs Externum
`externum run` (full pipeline)	551 ms ± 42	1.00×
Compiled artifact (compile once, run many)	458 ms	1.20× faster
CPython (idiomatic `for range`)	340 ms ± 10	1.62× faster
Bash (`$(( ))`, no forks)	6.16 s	11.2× slower

So: the Python target costs ~1.6× over hand-written CPython — the price of a typed source and a portable multi-target story, not magic. Against Bash, same-source wins by an order of magnitude. The VM path is ~30× slower than the transpile paths and that's fine: it exists for run-without-source distribution, not for CPU-bound loops.

The two bugs the benchmark caught

Building the benchmark was the best decision of the release, because it immediately fell into two holes:

Module-level x += 1 never stored the value. The bytecode compiler's augmented-assignment path loaded the variable with LOAD_GLOBAL but stored with STORE_VAR — writing into a frame nobody ever read. The loop variable never incremented; the VM spun in a silent infinite loop. Worse, the operator map keyed on "+" while the parser delivers "+=", so every augmented op except += would have silently executed as addition.
Parenthesized right-hand sides became variable names. The compiler couldn't strip outer parens, so (a + b) % m compiled to an attempt to load a global literally named "(a + b) % m".

Neither was caught by CI, because the existing VM tests didn't use those constructs — a good reminder that coverage measures what you wrote, not what users will. Both are now root-caused, fixed, regression-tested (v4.2.0), and the VM runs the benchmark identically to CPython. I filed them as issues before fixing — #21 and #22 — because "benchmark caught real bugs, here's the postmortem" is worth more than the appearance of never having bugs.

What I'd do differently

Benchmark before bragging. The false 4.5× number almost shipped because I measured the wrong command. Every number in the README is now reproducible from the repo.
Empty output is a bug, not a feature gap. The old bash target's silence was worse than a crash. Anything a target can't express must warn loudly at compile time.
Self-hosting is a forcing function. Writing the compiler in the language it compiles means every language wart is personally painful, immediately.

The roadmap from here: a JS target (the natural next runtime that's already everywhere), more stdlib, and keeping the honest-limits section of the README as current as the features list.

Repo: github.com/BartoszOsiej/externum · Playground: bartoszosiej.github.io/externum · pip install externum · MIT, ~380 tests

Detecting ransomware with eBPF in Rust

Bartosz Osiej — Fri, 18 Sep 2026 12:14:51 +0000

Detecting ransomware with eBPF in Rust

Title: Detecting ransomware with eBPF in Rust
Target: ~1000 words, B1-safe English, working-code-first
Build: demo + article for DEV.to / Draft.dev share
Source repo: github.com/BartoszOsiej/talus-process-monitor (MIT)

1. The idea (hook)

Ransomware works in a simple way: it opens your files, encrypts them, and writes them back. Fast. One process can open hundreds or thousands of files within seconds.

You do not need a huge model to spot it. You need to watch one number: how many files a single process opens per second.

This article shows a small eBPF program in Rust that does exactly that. It hooks two syscalls (execve and openat), counts file-open rate per process, and — when the rate is too high — kills the process.

All code comes from a real open-source project: talus-process-monitor (MIT, github.com/BartoszOsiej/talus-process-monitor).

2. What is eBPF in one sentence

eBPF lets you attach small programs to kernel events (syscalls, network packets, timers) without writing or loading a kernel module. The programs run in a sandboxed VM in the kernel. You get kernel-level visibility with low overhead.

In Rust, the library is called aya. aya-ebpf is the runtime for the kernel side. aya manages loading from userspace.

3. Kernel side: a tiny eBPF program

We define one "event" struct. Both kernel and userspace must agree on the layout, so it uses #[repr(C)]:

#[repr(C)]
pub struct ProcessEvent {
    pub event_type: u8,
    pub pid: u32,
    pub uid: u32,
    pub comm: [u8; 16],     // process name
    pub filename: [u8; 64], // opened file path
}

#[map]
pub static EVENTS: PerfEventArray<ProcessEvent> = PerfEventArray::new(0);

PerfEventArray is the channel between kernel and userspace. Each CPU has its own buffer, so concurrent processes do not block each other.

Next, two tracepoints. These run when a process starts (execve) or opens a file (openat):

#[tracepoint(name = "sys_enter_execve", category = "syscalls")]
pub fn sys_enter_execve(ctx: TracePointContext) -> u32 {
    emit_event(&ctx, EVENT_EXECVE, 0)
}

#[tracepoint(name = "sys_enter_openat", category = "syscalls")]
pub fn sys_enter_openat(ctx: TracePointContext) -> u32 {
    emit_event(&ctx, EVENT_OPENAT, 1)
}

The main work happens in emit_event. First we read PID and UID of the current process:

let pid = (bpf_get_current_pid_tgid() >> 32) as u32;
let uid = bpf_get_current_uid_gid() as u32;

Then we read the filename argument from the tracepoint args. The tracepoint layout is (common fields, filename, flags, mode), so the filename pointer sits at a fixed offset:

let ptr_size = core::mem::size_of::<*const c_char>();
let filename_offset = 16 + filename_arg as usize * ptr_size;

if let Ok(filename) = unsafe { ctx.read_at::<*const c_char>(filename_offset) } {
    if !filename.is_null() {
        // bpf_probe_read_user safely copies userspace memory
        if let Ok(bytes) = unsafe {
            bpf_probe_read_user_str_bytes(filename.cast::<u8>(), dst)
        } { /* copy into event.filename */ }
    }
}

Finally, we push the event into the buffer:

EVENTS.output(ctx, &event, 0);

One note about eBPF: you cannot use normal Rust std function calls. No memcpy, no memset, no format!. The code uses hand-written byte loops (raw_copy) to avoid LLVM builtins. This is a common eBPF gotcha:

unsafe fn raw_copy(dst: *mut u8, src: *const u8, len: usize) {
    let mut i = 0;
    while i < len {
        *dst.add(i) = *src.add(i);
        i += 1;
    }
}

4. Userspace: the detection engine

On the userspace side we read events off the perf buffer and keep a 1-second sliding window of open events per PID:

self.windows.entry(ev.pid).or_default() // VecDeque<Instant>

let cutoff = now - Duration::from_secs(WINDOW_SECS); // 1s
while window.front().is_some_and(|t| *t < cutoff) {
    window.pop_front();
}
window.push_back(now);
let opens_now = window.len();

If opens_now reaches the threshold (default 50 opens in 1 second), we fire an alert:

if self.threshold > 0 && stats.window_opens == self.threshold {
    stats.alerts += 1;
    outputs.push(Output::Alert(Alert { /* pid, comm, opens */ }));
    if self.auto_kill {
        let result = kill_process(ev.pid);
        outputs.push(Output::Action(ResponseAction { /* ... */ }));
    }
}

kill_process is a plain kill(2) with SIGKILL:

fn kill_process(pid: u32) -> bool {
    let rc = unsafe { libc::kill(pid as i32, libc::SIGKILL) };
    rc == 0
}

SIGKILL cannot be caught. The offending process stops immediately. That is the full "detect and respond" loop: hook → count → alert → kill.

5. Run it

Requirements: Linux kernel 5.8+, root (or CAP_BPF + CAP_SYS_ADMIN), Rust nightly and clang.

# Build
./build.sh

# Monitor only (no killing)
sudo target/release/process-monitor --alert-threshold 50

# EDR mode: detect and kill
sudo target/release/process-monitor --alert-threshold 50 --auto-kill

Test it with a loop that opens many files fast:

sudo process-monitor --alert-threshold 3 --auto-kill
# in another terminal:
for i in $(seq 1 100); do touch /tmp/f$i; done

The process that runs the loop violates the threshold and gets SIGKILL.

6. Limits and next steps

This heuristic has false positives (a backup tool also opens many files fast) — that is why a configurable threshold and a lower default matter. Real-world improvements from the same repo:

Shannon entropy scoring on filenames: encrypted/randomized names have high entropy.
Network egress tracing (connect, sendto): catch data exfiltration.
File-extension tracking: mass .enc / .locked writes.

The project also ships a small online-trained MLP model (no external deps) that turns raw event features into score: benign / suspicious / ransomware.

7. Summary

eBPF gives you kernel-level tracing without kernel modules.
Rust + aya makes the whole pipeline safe to build and maintain.
A 1-second sliding window on openat rate is a cheap, real ransomware signal.
Responding with SIGKILL turns a monitor into an EDR-style agent — 30 lines of Rust.

Full source code: github.com/BartoszOsiej/talus-process-monitor
Follow me on DEV.to for the next part: network egress detection with eBPF.

Try it on your machine

Talus is open source (MIT) — community edition includes the TUI, real-time eBPF tracing, and the ransomware heuristic.

If you want the full version — web dashboard, auto-kill response, SIEM exports (Kafka / ClickHouse / Memgraph) — Talus Enterprise is $50 one-time, perpetual: Get Talus Enterprise

Activation: talus license activate <KEY>

bip-calendar

Bartosz Osiej — Wed, 16 Sep 2026 17:14:15 +0000

Build-in-public: 30-day prompt calendar

Source for bip-draft.yml — the workflow picks Day N = (day-of-year mod 30).
One section per day; each draft gets auto-enriched with yesterday's commits.
Voice rule: drafts are scaffolding — rewrite at least one sentence in your own words before posting.

Day 1 — Show the stack

Screenshot/diagram of the project constellation (linux-aegis, talus, externum, fortis, quantum-shield, NV2). One line each: what problem it kills. End: "which one should I deep-dive first?"

Day 2 — Number drop

Post one real metric (192 externum tests, boot log timing, benchmark ops/sec). Explain why that number was hard to get. Never fake precision — say "measured on my machine, config in repo".

Day 3 — The in-tree war story

How linux-aegis ships as four patches against upstream instead of a DKMS out-of-tree blob. Why "compiles in-tree, boots in QEMU from CI" was the whole battle.

Day 4 — Teaser frame

"One of my projects compiles to Python, Bash AND a native binary from the same source. Guess why the Bash backend is the weird one." Answer in the next post.

Day 5 — Dev-log snippet

Paste a 5-line terminal capture (talus catching a simulated churn burst, NV2 frame times). Caption: what the viewer is looking at in one sentence.

Day 6 — Anti-hustle take

Build in public ≠ posting daily dopamine. I automate drafts and syndication precisely so the writing time goes into the work. Short, honest, no threads-of-threads.

Day 7 — Weekend build

What got shipped this week across all repos (the workflow's commit list makes this trivial). One paragraph max, links to entity home.

Day 8 — Explain like I'm five

eBPF in 3 sentences for non-kernel people: syscall syscall syscall — police inside the kernel watching every door. Then one line on why that's fast.

Day 9 — Tooling shoutout

Name one OSS tool that saved you hours this week (crier, git-cliff, libbpf). Genuine recommendation, no affiliation — good-faith networking.

Day 10 — Design decision

Why quantum-shield derives per-chunk keys instead of one global nonce. The bug class it prevents, in plain language.

Day 11 — Fail post

Something that broke this week and the fix. The more mundane the better — reliability porn is boring, debugging stories are not.

Day 12 — Writing corner

Line from The Stitcher Trilogy + one sentence on stitching horror with systems-brain discipline. Books and code are the same skill: constraints.

Day 13 — Screenshot Saturday

Best visual of the week (NV2 voxel render, root page CRT aesthetic, terminal UI). Let the image do the work.

Day 14 — Question to builders

Ask a real question you have (CO-RE portability across 6.x? ML-KEM key rotation UX?). Answer every reply — questions are the cheapest engagement there is.

Day 15 — Milestone marker

Tag/release shipped? Post the changelog's best three lines. git-cliff makes this a copy-paste.

Day 16 — Myth-busting

"You need a CS degree / a budget / a team to build systems software." You need a kernel tree, QEMU and stubbornness. Show the CI boot log as proof.

Day 17 — Architecture candy

One Mermaid diagram (fortis boot chain or NV2 pipeline). Caption: "every arrow is a link in a trust chain".

Day 18 — Workflow flex

The pipeline itself: article → git push → 9 platforms. "I don't have a marketing team; I have GitHub Actions." Link the repo.

Day 19 — Contrarian take (polite)

"Most 'post-quantum ready' tools are marketing until ML-KEM is in the default path." One argument, one caveat, invite pushback.

Day 20 — Reading list

Three things you actually read this week (patch series, paper, blog). One sentence each on what changed in your head.

Day 21 — Weekly wrap

Commits + what's next week. Consistency beats intensity — this is the post that compounds.

Day 22 — Author life

KDP dashboard moment, a review, or the process of writing book 2's ending. Writers on dev Twitter are rare; use that lane.

Day 23 — Mini-tutorial

One actionable tip (e.g., "add llms.txt to your site in 10 minutes"). Pure value post; nothing asked back.

Day 24 — Progress bar

NV2_ENGINE frame time over the month, or externum test count trend. Small chart, big credibility.

Day 25 — Behind the name

Why the projects are named what they're named (aegis, talus, fortis). Names are free branding; tell the story.

Day 26 — Security PSA

One habit that actually helps devs (verify signatures, zeroize keys, pin CI base commits). No fear-mongering, one concrete command.

Day 27 — Collab bait

"linux-aegis needs SELinux-stacking test scenarios — if you've done LSM stacking, I'd love your take." Specific asks get specific help.

Day 28 — Tech/genre crossover

"The Stitcher is a crime-horror trilogy written like a distributed system: state, failure modes, irreversible operations." Post the good line.

Day 29 — Open roadmap

Public TODO for the quarter. Accountability post; people return to check if you did it.

Day 30 — Gratitude + links

Shout out people who replied/reshared this month. End with the entity home link. The 30-day loop restarts tomorrow.

Building a Solana-like validator in Rust: what PoH, Tower BFT and Sealevel actually force you to think about

Bartosz Osiej — Tue, 15 Sep 2026 15:52:48 +0000

TL;DR

TrustNode is a from-scratch Solana-style cluster in Rust: a verified Proof-of-History clock, Tower BFT-style consensus, a Sealevel-like parallel execution engine, gossip, and erasure-coded block recovery. The point was never to clone Solana — it's that these three subsystems force concrete, painful design decisions that generic "blockchain in Rust" tutorials skip. This is what they actually force.

The PoH clock is a scheduling problem, not a hash chain

The naive description — "hash a counter, publish a chain of hashes" — is one line. The real problem is that the clock sources events (TickHeight, sequential slot heights) and the validators re-derive them locally to trust the chain. When it breaks, it breaks as ordering: two validators disagree on which tick a transaction belonged to, and the whole ledger forks at that point.

What actually mattered in the implementation:

Batching ticks, not hashing every transaction. Hash a counter on each tick, but let a batch of entries commute into one tick. Constant re-hashing per-transaction kills throughput and makes the clock the bottleneck.
The clock must be derivable from the ledger. If "slot N belongs to slot N" isn't an independent statement any node can recompute from the block alone, you've built a chain that needs a trusted signer — the exact thing you were trying to cryptographically remove.
Verifier side must match generator side bit-for-bit. Off-by-one in the tick batching turns up as a consensus failure weeks later, not a compile error.

Lesson: in a PoH system the clock is the consensus substrate. Get the pure function right first; consensus is downstream of it.

Tower BFT is a voting game at fixed heights

Tower BFT simplifies PBFT by anchoring votes to the PoH slot height. The trick (and the trap) is that votes happen at heights, and each validator commits to "I have not voted against this fork above slot X for Y slots." The consequence that's easy to miss until you implement it:

Vote lifetime is a number you have to choose. How many slots does a lock hold? Too short and liveness collapses (validators flip-flop, the fork battle never ends); too long and the network can be bricked.
Commit vs. finalize are different states. Reaching "commit" as a local statement is easy; broadcasting finalization so other nodes can rely on it is where cloudblocks appear.
The lock mechanism is per-validator bookkeeping. Track highest lock height, refuse to vote below it, and explain that in tests — because half the bugs turn out to be "validator voted against its own lock."

Lesson: BFT flavors differ in where they put the voting rules, not in whether they have them. Implementing one in your own repo makes the whitepaper read like a checklist instead of a mystery.

Sealevel parallelism lives or dies on account locks

Parallel execution is the marketing line; the implementation is "which accounts does this instruction touch, and can I prove they don't overlap." The real work is:

Static account-readset/writeset extraction. Every instruction declares accounts before execution. If it doesn't, you can't schedule safely — so the API forces it.
Overlap detection decides throughput. Two programs touching disjoint accounts run in parallel; any overlap serializes. Most of the performance cliff lives in a naive overlap check (collision on account keys, not program IDs).
The price of conflict is determinism. Any scheduler that reorders conflicting instructions must be reproducible across all validators, or the same block executes differently on different machines.

Lesson: "parallel VM" is 20% scheduling and 80% proving it's deterministic while parallel.

What I'd build differently

Real transaction processing over RPC is the current frontier in the repo (commits land almost daily). The honest retro:

Boot the consensus before the clock. I built PoH first because it looks like the foundation. In hindsight the vote/lock rules are the design core; the clock is just the substrate they sit on.
Fuzz the ledger reconstruction. Erasure-coded recovery looks simple until a node survives with 2-of-4 shards and has to rebuild without trusting what it already has.
Determinism tests on the scheduler early. Portable scheduling is the difference between a demo and a network.

Repo

TrustNode — PoH clock, Tower BFT, Sealevel-style execution, gossip + erasure coding, real transaction processing over RPC (Rust, MIT).

eBPF verifier limits are a design constraint: what CO-RE field offsets and bounded loops taught me

Bartosz Osiej — Tue, 15 Sep 2026 15:52:16 +0000

TL;DR

Working on talus-process-monitor (Rust userspace + libbpf/C eBPF) I kept bumping into the same three walls: CO-RE field offsets shifting between kernel versions, the verifier refusing anything that looks like an unbounded loop, and map access patterns that get rejected at load time. All three are design constraints, not compiler annoyances. This post is what changed in my approach once I stopped fighting them.

CO-RE relocation is a promise you have to verify

Portable BPF (Compile Once - Run Everywhere) means the kernel rewrites your field accesses based on its own BTF. In theory: compile once, run on kernel 6.x. In practice I chased two classes of bugs:

struct file layout differences — an offset that's valid on kernel A and wrong on kernel B. The relocation did its job; I had assumed a field meant what it meant.
Unavailable BTF — if the target kernel doesn't ship BTF, relocation fails at load with a cryptic error. It's a deployment check, not a code bug.

What made this tractable: a verification matrix in CI — the same source compiled and loaded against a set of kernels, with the load result asserted. When a field offset drifts, the pipeline turns red before a cluster does.

Body of the lesson: "portable" is a claim that must be tested per-kernel, or it's just hope. A build that passes on one kernel is a demo, not portability.

The verifier forbids unbounded loops. That's fine; it teaches you state machines.

The verifier allows bounded loops (with a maximum iteration count) and rejects anything unverifiable. If you want to scan "all entries in this hash map" you get rejected at load time. The productive response is to stop thinking "iterate until done" and think "fixed horizon, amortized":

Lease the map. Instead of iterating the whole map per event, keep a fixed-size sliding window of state and, on overflow, process the oldest batch — a bounded, verifier-friendly step.
Folding state into the map entry. Store the running score in the entry being updated, so decisions don't require iterating unrelated entries.
Push the unbounded part userspace. The kernel probe exports a summary; the Rust side does the arbitrary-loop reasoning.

This mirrors how real agents behave: kernel-side reaction is quick and bounded; the risky/flexible analysis happens outside the hot path.

Map access patterns decide load-time rejection

Two patterns get rejected at unexpected places: holding an entry pointer across a perf output call, and nested lookup while a lookup key is pinned. The verifier tracks what you are allowed to do while a value pointer is live. Restructure: copy the fields you need into stack-local values, then emit events. It's the difference between "loads everywhere" and "loads only when the code is shaped right."

Verification has to live in CI, not in your head

The current talus trunk carries a verification document (field-offset matrix, per-kernel load expectations) plus CI that compiles and asserts. The single highest-value commit this project got was not a feature — it was the CI job that turned "should work on this kernel" into a machine-checked statement.

Repo

talus-process-monitor — Rust + libbpf/C eBPF endpoint security agent with a MeMLP neural detection engine; verification matrix lives in VERIFICATION-EBPF.md.