DEV Community: Kazuru

Path Consistency in Kubernetes DNS Stacks: Do Resolvers Agree Under Adversarial Conditions?

Kazuru — Sat, 18 Jul 2026 16:03:04 +0000

Most Kubernetes nodes do not have one DNS. They have a path: pod stub / libc, often systemd-resolved on the host, sometimes NodeLocal DNSCache, then CoreDNS, then upstream. The security question that matters to operators is not which recursive binary won a paper bake-off. It is:

Does hop N on my path accept something hop N+1 would reject?

That is path-consistency. Existing differential fuzzers mostly answer a different question (peer-consistency). This post introduces StackDiff: a lab harness for the path question, with an honest scope about what plain containers can and cannot measure.

This is a methodology post. No findings tables, no CVE counts, no Klein/SAD reproduction, and not a claim that a full Kubernetes path is already instrumented.

Path vs peer

Effective cluster posture is the weakest agreeing hop, not the strongest row in a comparison table.

Threat model

Every profile declares three fields before it counts:

Field	Meaning
Adversary position	`on-path` / `off-path` / `malicious-but-trusted-upstream` / `none` (smoke)
Adversary capability	What they can manipulate: response content, timing, races, ICMP, and so on
Win condition	What success means here, for example one hop caches what another rejects

Every profile also pins DNSSEC posture (matched vs deliberately_mismatched):

"dnssec_posture": {
  "mode": "matched",
  "unbound": "off-lab-zone",
  "dnsmasq": "off",
  "notes": "Matched non-validating so Unbound defaults cannot manufacture a divergence"
}

Unbound validates by default; dnsmasq does not unless configured. An unpinned mismatch manufactures fake Class A “findings” that are really config accidents.

Path-consistency win: disagreement along the path so the cluster’s effective posture becomes the weakest agreeing hop. Smoke profile P-SMOKE-AGREE uses position none and matched non-validating DNSSEC. Divergence on the smoke axes is a harness failure, not a win.

Scope / isolation

Containers share a kernel. That matters for some DNS attacks and not others.

Klein targets the Linux kernel’s shared prandom generator (UDP source ports, IPv6 flow labels, IPv4 ID). The paper (arXiv:2012.07432) shows the attack can run locally across users and across containers on the same host. Shared-kernel Docker does not isolate it. Klein-class profiles are deferred to Firecracker / Kata / full VMs.

SAD DNS (CVE-2020-25705) uses ICMP rate limiting as a side channel. Two kernel changes matter, and they are not the same thing:

Primary mitigation: Linux randomized the ICMP global rate limiter (b38e7819cae946e2edf869e604af1e65a5d241c5), mainline 5.10+ with wide LTS backports.
Isolation improvement: msgs-per-sec token state moved from host-wide to per-netns between v6.11 and v6.12 (b056b4cd9178f7a1d5d57f7b48b073c29729ddaa). That changes whether two containers share the bucket, not whether the side channel was already noised.

Layer	Plain Docker?	This release
Application-layer outputs (RCODE, RRset, flags, hang/crash)	Valid	In scope
Klein-class shared `prandom`	Not isolated	Deferred
SAD DNS-class ICMP side channel	Randomization ≠ netns isolation	Deferred until kernel pin

Ubuntu 24.04 and many enterprise kernels are often still v6.11-shaped for the msgs-per-sec bucket. Always record uname -r and the distro package. Prefer full commit URLs.

Related work

Tool	Venue	Question
ResolFuzz (Bushart & Rossow)	ESORICS 2023	Do recursive resolvers diverge on mutated inputs?
ResolverFuzz (Zhang et al.)	USENIX Security 2024	Query–response fuzzing and differential clustering; real cache-poisoning-class bugs with CVE follow-through

StackDiff does not replace either tool. It asks a path-consistency question under pinned application-layer profiles.

Architecture (pair mode)

The public pin tests resolver pairs under identical conditions so the oracle can be trusted before anyone treats divergences as security-relevant. A full Kubernetes path (stub → node-local → CoreDNS → upstream) is a different measurement unit. Pair mode asks whether two path-role stand-ins agree; it does not claim the whole chain is instrumented.

Unbound and dnsmasq are those stand-ins: dnsmasq approximates local forwarder/cache behavior (NodeLocal DNSCache / systemd-resolved); Unbound approximates a recursive hop. Smoke keeps Unbound forward-only against the same lab authority as dnsmasq, with matched non-validating DNSSEC.

Class	Meaning	Rule
A	Documented / RFC-allowed disagreement	Report; do not hype
B	Emergent, security-relevant	Root-cause and disclosure first
C	Timing, nondeterminism, harness bug	Fix harness; never publish as finding

Smoke gate

Both resolvers must return RCODE=NOERROR, the same answer RRset containing 203.0.113.10 for agree.lab.stackdiff. A, and neither side may hang or hard-error. Any mismatch on those axes is Class C / stop. AA/RA are informational only.

Profile	Resolvers	RCODE	RRset	Hang/crash	Class
P-SMOKE-AGREE	Unbound ↔ dnsmasq	agree	agree	none	pass

On this forward-only path, dnsmasq often sets aa=true while Unbound sets aa=false for the same answers. That is expected noise, not a smoke failure.

Lab pin

Field	Value
Repo	dns-stack-diff-harness
Tag	`blog-dns01-2026-07`
Host	Ubuntu 24.04.4 LTS (`stackdiff-lab`), QEMU/KVM
`uname -r`	`6.8.0-134-generic`
Kernel package	`linux-image-6.8.0-134-generic` `6.8.0-134.134`
Docker / Compose	`29.1.3` / `2.40.3`
Run	`smoke-20260718T125325Z`
`pass` / divergences	`true` / `0`
Manifest	`artifacts/smoke-20260718T125325Z/manifest.json`
Manifest SHA-256	`6804627105cd22b51b35e9df1c713f2fe26c5c4d67abb81bfdd2064be99e0560`

This host is v6.11-shaped for the ICMP msgs-per-sec bucket. Do not claim per-netns isolation here. Cite the pin (uname -r and the committed manifest SHA-256), not main plus whatever Docker Desktop shipped. The published uname_a uses the public alias stackdiff-lab.

Reproduce

git clone https://github.com/kazuru-chidumbwe/dns-stack-diff-harness
cd dns-stack-diff-harness
git checkout blog-dns01-2026-07
# Verify the frozen pin (exact hash of the committed file):
sha256sum artifacts/smoke-20260718T125325Z/manifest.json
# expect: 6804627105cd22b51b35e9df1c713f2fe26c5c4d67abb81bfdd2064be99e0560

docker compose -f deploy/compose.yaml up -d --build
make smoke
# Your new artifacts/smoke-* run will have a different SHA (timestamps differ).
# What should match the pin: pass=true and oracle.divergence_count=0

Needs Docker Compose and Python 3.12+. Lab DNS only.

What this post is not claiming

New CVEs or “N exploitable divergences”
Klein under Docker, or SAD DNS without a pinned kernel story
A replacement for ResolFuzz or ResolverFuzz
That pair mode already is a full stub → node-local → CoreDNS path

It claims a path-consistency instrument (pair-validated first), an explicit isolation boundary, and a smoke gate that is green on the pin above. The harness is public on that pin; this post is methodology only. If you want harness updates, watch dns-stack-diff-harness on GitHub.

A Differential Test Harness for Native vs. Generic XDP: Methodology and Baseline

Kazuru — Tue, 14 Jul 2026 03:34:29 +0000

Native XDP and generic SKB-mode XDP are not the same thing in practice. The same BPF program can pass the verifier and still behave differently depending on which mode the kernel uses, this could be a different verdict, different frame bytes, or different metadata. This post ships three things: an open differential test harness, a fixed eleven-packet corpus, and a simple way to classify the differences it finds. A tagged release lets anyone reproduce the virtio/veth baseline on Linux 6.8.

The operational risk is straightforward. A firewall or rate-limiter validated only under native XDP can fall back to generic mode on an unsupported driver, a veth port, or after a reload. You keep the same bytecode, but behaviour can change, often without a clear error line.

What this release includes:

A harness loop: corpus → inject on the RX path → native vs generic sweep → xdpdump capture → compare.py manifest, comparing both the captured frame bytes and the XDP verdict (PASS/DROP/TX/REDIRECT).
A deterministic corpus with eleven embedded test IDs (0xA001–0xA005, 0xA007–0xA00C; 0xA006 is intentionally omitted as a reserved gap in the generator).
An operational divergence taxonomy (Class A / B / C).
A virtio/veth smoke gate on Linux 6.8; now gating on frame bytes and verdict agreement that shows the full path is reproducible end to end.

Scope for this post: native vs generic XDP on the virtio_vm profile only (five BPF programs, pinned manifests). This is part 1 of 2; it establishes the harness and an instrument-validity baseline; a follow-up post covers bare-metal divergence results. Physical NIC results are not part of this baseline.

Ordinary conformance checks stop at “did the program load?” Differential testing asks a sharper question: given identical input packets, do the backends produce the same observable outcome at the hook?

Background: native vs generic XDP

Both modes load the same BPF object. They diverge at the hook point and in how the packet is represented.

Feature	Native XDP	Generic XDP (SKB)
Hook point	Driver ingress (`ndo_xdp`, before `sk_buff`)	`netif_receive_skb()` path (`xdpgeneric`)
`sk_buff`	No — works on the driver frame / `xdp_buff`	Yes — packet is SKB-backed
`data_meta`	Depends on driver and headroom	Often NULL or reduced headroom
VLAN tags	As presented at driver ingress (unless RX VLAN offload strips early)	Same offload confounds; path still differs
Fragments	Driver-dependent layout	May be linearised or presented differently
Checksum	Hardware offload may apply before the hook	Software path is more common
Typical throughput	NIC-limited (tens of Mpps class)	Lower (single-digit Mpps class on the same hardware)

Generic XDP exists so programs can run where drivers lack native support. That convenience costs the early-hook semantics people often assume when they test on one NIC and deploy on another.

Hardware SmartNIC signed offload is out of scope for this harness.

Corpus (eleven packets)

Each frame carries a test ID in the TCP/UDP source port, ICMP id, or payload tail so compare.py can pair captures without relying on timing.

Test ID	Packet	Exercises	`prog_pass_drop` expected
0xA001	IPv4 TCP SYN	Basic L3/L4 parse	PASS
0xA002	IPv6 TCP SYN	Non-IPv4 ethertype (program passes non-IPv4)	PASS
0xA003	802.1Q VLAN	Single tag	PASS
0xA004	QinQ	Double VLAN	PASS
0xA005	IPv4 fragment	Fragment / incomplete L4	PASS (a non-first fragment carries no TCP header, so the `sport == 0xA005` drop branch is never reached — the drop path is effectively dead against this corpus)
0xA009	ICMP echo	Non-TCP/UDP	PASS
0xA008	UDP zero checksum	UDP / checksum edge	PASS
0xA007	TCP FIN/ACK	TCP flags	PASS
0xA00A	TCP zero payload	Empty payload	PASS
0xA00B	MTU-sized fill	Large frame	PASS
0xA00C	DSCP/ECN	IP TOS field	PASS

Coverage spans L2 (VLAN/QinQ), L3 (IPv4/IPv6/frag/TOS), L4 (TCP/UDP/ICMP), a checksum edge, and an MTU fill. Companion programs isolate other behaviours: prog_metadata_test (data_meta headroom), prog_vlan (802.1Q rewrite), prog_l3_modify (TTL decrement), and prog_redirect (same-port XDP_REDIRECT).

What the comparator measures

compare.py compares two things per test ID: the frame bytes, and the XDP verdict.

Pairing — pull the test ID out of each captured frame (payload tail, TCP/UDP source port, or ICMP id, in 0xA000–0xA0FF).
Capture point — sweeps use xdpdump --rx-capture=exit, so we see the frame after the program runs. (Default xdpdump captures at entry only.)
Frame fingerprint — SHA-256 of the captured bytes. A test ID is equivalent: true only when both backends captured it and the fingerprints match. If an ID shows up on one backend but not the other, that is a divergence.
Verdict — the XDP action: PASS, DROP, TX, or REDIRECT. xdpdump prints this in its text output (xdp_prog()@exit[DROP]), not in the -w pcapng frame. So the sweep runs a second xdpdump -x pass, and compare.py records a verdict and verdict_match per test ID plus a top-level verdict_divergence_count. This is independent of the bytes: if one mode drops a packet the other passes without changing the frame, the fingerprint misses it — the verdict catches it.

One axis is still not measured: context metadata. data_meta, ingress_ifindex, and rx_queue_index live in xdp_md, and never show up in the frame or in xdpdump's text. Two backends could disagree there while the bytes and the verdict both match. Reading it needs a small metadata-echo BPF program, which is planned for the bare-metal follow-up. (Class C — an observation limit, not a bug.)

A note on determinism: these programs are safe to compare byte-for-byte. prog_pass_drop does not touch headers, packets only traverse ingress RX (no routing), and veth injection does not rewrite TTL or IP ID. Header-mutating programs (prog_l3_modify, prog_vlan) do change bytes, and the exit capture reflects those changes.

Three pitfalls, named once: inject on a peer interface (the RX path), not with tcpreplay onto the attach NIC; detach XDP between backend runs; label every manifest by profile.

Divergence taxonomy

Class	Definition	Action
A	Difference described in kernel docs or known backend semantics (for example documented `data_meta` absence in generic mode).	Record it; do not treat it as a harness bug.
B	Same corpus and controlled NIC config; difference is not documented but reproducible on standard hardware.	Investigate; consider a kernel/driver report.
C	Caused by uncontrolled setup (offload left on, wrong inject path, capture race, mixed profiles) — or by a measurement limit of the harness.	Fix the environment or document the limit; exclude from “surprise” analysis.

Harness architecture

On the virtio_vm profile, topology-veth.sh creates veth-a / veth-b, moves veth-a into netns xdpequiv-inj, and attaches XDP on veth-b in the host namespace. Injection on veth-a puts packets onto veth-b on the RX path — where native vs generic semantics actually differ.

generate_corpus.py → corpus.pcap
        │
        ▼
inject.py (netns xdpequiv-inj, iface veth-a)
        │
        ▼
veth peer → veth-b [XDP: native | generic]
        │
        ▼
xdpdump → captures/output_<backend>_pass_drop.pcap
        │
        ▼
compare.py → manifests/run_manifest_virtio_vm_pass_drop.json

Lab profile for this post

Profile	Topology	Hardware	Entry point
`virtio_vm`	veth + netns inject	Any Linux VM / host	`sudo make topology && sudo make sweep-virtio` or `bash scripts/smoke.sh`

scripts/smoke.sh wraps corpus + build + topology + sweep and checks a minimum case count — treat it as the pass/fail gate. make sweep-virtio runs one program; bash scripts/sweep-all-virtio.sh sweeps all five blog programs on veth.

Results

We ran the harness on the virtio_vm profile (Linux 6.8.0-134-generic, veth + netns inject) across five programs:

Program	Cases paired	Verdict (both backends)
`prog_pass_drop`	11 / 11	PASS
`prog_metadata_test`	11 / 11	DROP
`prog_vlan`	11 / 11	PASS
`prog_l3_modify`	11 / 11	PASS
`prog_redirect`	11 / 11	REDIRECT

Pinned manifests live in the repository as manifests/run_manifest_virtio_vm_<program>.json.

Zero byte divergences means native and generic produced identical exit-capture bytes for these programs on this topology. Zero verdict divergences means they also returned the same XDP action for every packet. So both modes agree on both axes — but only here. This says nothing about other NICs, and the context axis is still unmeasured.

Two program-specific notes:

prog_pass_drop comes back PASS on every test ID. That is because the corpus never triggers the program's DROP branch. The branch fires on TCP sport == 0xA005, but case 05 is a non-first IP fragment with no TCP header — the bytes read at the L4 offset are never 0xA005. So the drop path is dead against this corpus. A packet that actually triggers it is left to the bare-metal follow-up, which rebuilds and re-verifies the corpus anyway. This is worth stating plainly: verdict capture works, and on this corpus there is simply no drop to catch yet.

prog_metadata_test comes back DROP on every test ID, on both backends. The frame fingerprint alone could never have shown that — the program does not touch the payload, so the bytes match either way. The verdict axis is what surfaces it. The two modes agree on the action; they may still differ on data_meta headroom itself, which we do not capture, so treat that as unmeasured.

Two observation limits remain for this baseline:

prog_redirect: both backends return REDIRECT and the exit-capture bytes match, but the harness captures on the attach interface only. Full equivalence would also require confirming the packet reached the redirect destination with matching bytes — a Class C limit for this program.
VLAN offload: the corpus includes 802.1Q and QinQ, but the harness does not yet verify whether RX VLAN offload strips tags before XDP sees them (more likely under generic mode). prog_vlan_probe ships for this check, but its output is not part of this baseline.

Validation

Smoke gate (`prog_pass_drop`)

On Linux 6.8.0-134-generic (lab VM, virtio/veth profile):

Metric	Result
Corpus cases paired	11 / 11
Capture fingerprint mismatches (native vs generic)	0
Verdict mismatches (native vs generic)	0 (all PASS)
`scripts/smoke.sh`	PASS

The gate now checks both axes: the fingerprints must match, and verdict_divergence_count must be 0. That closes an earlier hole. For a non-mutating program like prog_pass_drop, the frame bytes are identical whether the packet is passed or dropped — so a byte-only gate would stay green even if the two modes disagreed on the action, which is the difference that matters most. It is still a backstop on a trivial topology, not a claim of universal equivalence.

Comparator sensitivity (synthetic)

Four synthetic self-tests exercise compare.py with no kernel required:

comparator-selftest.py — same test ID, different post-hook bytes (a TTL change). Expect divergence_count: 1.
comparator-missing-tid-test.py — a test ID present on only one backend. Expect a divergence.
comparator-blindspot-demo.py — identical bytes on both backends. Expect divergence_count: 0 (byte agreement alone does not prove context agreement).
comparator-verdict-selftest.py — same test ID and identical bytes, but opposite verdicts (PASS vs DROP). Expect divergence_count: 0 and verdict_divergence_count: 1.

The last test is the point: it proves the verdict axis catches a disposition mismatch that the byte fingerprint cannot. Together the four cover both axes the comparator measures, and document the one it does not (context).

Run the full validation bundle:

bash scripts/comparator-sensitivity.sh   # self-test + optional live probes
# or: make validate-comparator
bash scripts/sweep-all-virtio.sh         # all five programs on veth

Live backend probes (informational)

The repository also ships prog_metadata_test, prog_vlan, prog_l3_modify, prog_redirect, and prog_vlan_probe (an 802.1Q visibility probe). On the 6.8 veth run, all five sweeps showed 0 byte divergences and 0 verdict divergences. The actions seen — identical on both backends — were: pass_drop PASS, metadata_test DROP, vlan PASS, l3_modify PASS, redirect REDIRECT. The context axis stays unmeasured until the bare-metal follow-up.

Example manifest excerpt (prog_pass_drop, smoke gate):

{
  "profile": "virtio_vm",
  "kernel": "6.8.0-134-generic",
  "backends": ["native", "generic"],
  "corpus_sha256": "…",
  "program_sha256": "…",
  "divergence_count": 0,
  "verdict_divergence_count": 0,
  "cases": [
    {
      "test_id": 40961,
      "fingerprints": { "native": "a1b2c3…", "generic": "a1b2c3…" },
      "equivalent": true,
      "verdict": { "native": "PASS", "generic": "PASS" },
      "verdict_match": true
    }
  ]
}

(test_id 40961 = 0xA001.) Full manifests for all five virtio programs are in the repository.

Run it yourself

https://github.com/kazuru-chidumbwe/xdp-backend-equiv-harness

git clone https://github.com/kazuru-chidumbwe/xdp-backend-equiv-harness.git
cd xdp-backend-equiv-harness
git checkout blog-x01-2026-07

sudo apt-get install -y clang llvm libbpf-dev python3-scapy xdp-tools make \
  linux-tools-common linux-headers-$(uname -r)
# xdpdump ships in xdp-tools (Ubuntu/Debian). If missing: build from https://github.com/xdp-project/xdp-tools

bash scripts/smoke.sh
bash scripts/comparator-sensitivity.sh
bash scripts/sweep-all-virtio.sh

Troubleshooting — smoke.sh exits non-zero when:

xdpdump or clang is missing;
topology cannot create the veth/netns pair (usually a stale veth-a — rerun sudo make topology);
fewer than 11 paired test IDs land in the manifest;
the sweep or comparator fails, including a verdict mismatch.

If you see Native and generic XDP can't be active at the same time, make sure both xdp off and xdpgeneric off ran between backend captures (current harness/sweep.sh handles this). Use sudo where shown; kernel 6.8+ matches the tagged lab gate.

Outputs: manifests/run_manifest_virtio_vm_*.json.

Differential Testing Revealed What Conformance Testing Missed: A Case Study with Open-Source eMRTD Libraries

Kazuru — Tue, 07 Jul 2026 21:06:27 +0000

Conformance suites tell us whether a library passes its own tests. They do not tell us whether two independent implementations make the same decision when presented with identical protocol traffic. ICAO Doc 9303 defines how an e-passport should behave. But the open-source library you choose determines what your application actually experiences. Libraries pass unit tests. Integrators pass interoperability tests. At some point, we stopped asking a much simpler question: if two independent implementations receive exactly the same protocol traffic, will they make the same security decision?

We set out to find an answer. Our approach was a controlled experiment built around a deterministic synthetic protocol profile, with no passport on our desks, no NFC reader, and no RF variables to chase. We replayed the same protocol exchange against two widely used wire-tier eMRTD readers: gmrtd in Go and JMRTD in Java.

What we found was not dramatic, but it was revealing. PACE failed during the initial negotiation. BAC then completed successfully. For an application that merely checks whether a secure session exists, there was no explicit indication that a protocol fallback had occurred. Both libraries produced the same observable behaviour under the same profile.

The experiment was also entirely reproducible. We could rerun it later the same afternoon and obtain the same result, backed by the same traces and run metadata.

BAC, PACE, and why we bothered with differential testing

If you have shipped TLS, you already know what negotiation failure feels like at the integration layer. eMRTD access control is the same shape of problem on a contactless chip.

BAC (Basic Access Control) is the older path: session keys from MRZ data. PACE (Password Authenticated Connection Establishment) is what newer documents advertise in EF.CardAccess before authentication, and what auditors increasingly expect terminals to prefer when it is on offer. Most chips still speak both. That is normal.

The interesting part is reader behaviour when PACE fails. Does the stack stop and report? Or does it try BAC and hand your application something that looks like a clean open session?

Conformance testing asks whether each library passes its own checklist. Differential testing fixes the chip behaviour and asks what each library tells the application. We are interested in the second question.

What we were trying to learn

The hypothesis, in plain language: if two independent implementations see identical protocol traffic, should a typical application caller see the same outcome?

We deliberately kept the first cut small. Two libraries, not five. One synthetic downgrade: PACE advertised, first PACE APDU returns 6FFF, BAC mutual authentication still works. One smoke run per library. This essay is one concrete case per stack, not a prevalence study.

How the experiment is set up

The chip is a JSON profile. A simulator answers APDUs from that profile in-process, with no silicon and no RF for this test. Each driver calls the real library negotiation path against the same byte stream. Whatever comes back, whether return value, session fields, or APDU log, gets written to a trace file.

The profile we used is called pace-then-bac-downgrade. The important fields look like this:

{
  "id": "TC-AC-01",
  "condition": "pace_fail_then_bac",
  "injection": {
    "pace_fail_on": "first_pace_apdu",
    "pace_sw": "6FFF"
  }
}

EF.CardAccess advertises PACE before authentication (our profile models this via card_access_hex). The first PACE step dies with 6FFF. BAC still completes. That is the entire adversarial condition.

We also score each run for whether a naive integration would notice the downgrade. Score 0 means the failure never has to surface to code that only checks "did it open?" Score 2 means the caller cannot proceed without handling the failure. For this post, score 0 is the whole story.

Running the experiment

The test case is TC-AC-01. We performed one execution per library. We cared about the JSON trace: run_id, the APDU arrays, bac_success, observability_score, and whatever error surface each library actually exposes.

On the wire, both readers should tell the same chip story. MSE:Set AT starts PACE; the chip returns 6FFF; GET CHALLENGE and EXTERNAL AUTHENTICATE still finish with 9000. The BAC ciphertexts differ run to run because each library generates its own random numbers. The failure point and the fallback should not differ.

Each driver writes logs/<run_id>.json. At pin blog-b10-2026-07, run_id uses microsecond UTC time plus a monotonic sequence suffix — pattern TC-AC-01-{library}-YYYYMMDDTHHMMSS.microsecondsZ-NNNNNN (for example TC-AC-01-gmrtd-20260707T135005.482913Z-000001). We captured smoke traces the afternoon we drafted this post; a colleague reran make smoke on a fresh lab clone at the same pin and got the same outcome (observability_score: 0 on both drivers) with different run_id values, as expected.

What showed up on the wire

gmrtd

gmrtd records the PACE failure on the session object. It does not fail the call your service is likely to treat as the success boundary.

docEx, apduLog, err := reader.ReadDocument(password, atr, ats)
fmt.Printf("ReadDocument err: %v\n", err)
// >>> nil

fmt.Printf("PACE err: %v\n", docEx.Session.PaceErr)
// >>> [DoPACE] doApduMseSetAT error: ... MSE:Set AT failed (Status:6fff)

fmt.Printf("BAC success: %v\n", docEx.Session.BacResult != nil && docEx.Session.BacResult.Success)
// >>> true

PaceErr is populated. The APDU log shows 6fff before the BAC commands. err is nil. If your handler only checks the return value, you log a successful read after a failed PACE and move on.

From our gmrtd smoke trace (logs/TC-AC-01-gmrtd-*.json):

C: 0022c1a412800a04007f0007020204020483010184010d
R: 6fff

C: 0084000008
R: 4608f919887022129000

C: 0082000028d7b3b9d55cb313556804d6afedd55db24f0e6389dc7403dbd4d4be510d784711fcafd7dfd68a387628
R: 46b9342a41396cd7d74fff620ba529aa76ed1d79623747d5383fd073b453010e3a6c7e2c59e3ea3e9000

Observability score: 0.

JMRTD

JMRTD is louder at the library boundary. It throws PACEException on 6FFF. Production glue is often quieter.

PACEException paceFailure = null;
try {
    service.doPACE(bacKey, paceInfo.getObjectIdentifier(),
        PACEInfo.toParameterSpec(paceInfo.getParameterId()));
} catch (PACEException e) {
    paceFailure = e;  // SW = 0x6fff
}
service.sendSelectApplet(false);
service.doBAC(bacKey);

We have seen this pattern enough times to treat it as the default risk, not a corner case: catch, maybe log at DEBUG, call doBAC(), return authenticated: true. The experiment models that wrapper on purpose.

From our JMRTD smoke trace (logs/TC-AC-01-jmrtd-*.json):

C: 0022c1a40f800a04007f00070202040204830101
R: 6fff

C: 00a4040c07a0000002471001
R: 9000

C: 0084000008
R: 4608f919887022129000

C: 008200002892e5c592d2995c4f76a0e0b7f71e8d915f28e27a5a6bc11aa5706ddc781e05cbd3f6534575ebc19b28
R: 46b9342a41396cd798d2cc8b293b4fb78abfd26d4ef5bd5bd8475bf0f290ed59325904a018b7d5419000

Same chip. Different API shape. Same gap if the application only asks whether the session opened. Observability score: 0 with the catch-and-continue wrapper.

Why we think integrators should care

When PACE fails and BAC succeeds, the stack has accepted a weaker mechanism than the chip advertised. Your middleware may record authenticated: true and never store that PACE was attempted and rejected. SIEM rules built on session success will not see it. Policy that says "use PACE when EF.CardAccess offers it" cannot enforce what your API never surfaces.

If you have ever searched a vendor codebase for doBAC after a failed doPACE, you know the feeling. The README says the library supports PACE. Your wrapper might still treat BAC success as mission accomplished. Audit the tag you pinned, not the marketing page.

A fix that is boring on purpose

The failure mode is implicit downgrade. The fix we care about is equally boring: do not fall back unless fallback is an explicit policy decision.

On gmrtd that means surfacing PaceErr on the return path, not burying it on the session struct. On JMRTD it means rethrowing PACEException instead of catch-and-continue. In pseudocode the rule is simply: if PACE failed and policy does not allow BAC fallback, return an error; do not silently open BAC and call it success.

We wired a thin middleware layer in the experiment repo to show the before and after. Baseline drivers score 0. Mitigated drivers force the caller to handle PACE failure. Nothing clever, just separating protocol outcome from transaction success.

The same story elsewhere

Passports are a convenient place to run this because the open source readers exist and the specification is public. The pattern is not passport-specific. Long-lived hardware with short-lived software on top shows up in PIV, national eID, payment terminals, anywhere a secure element outlives the middleware version you pinned last quarter. TLS cipher negotiation and SSH KEX fallback rhyme with the same question: which mechanism actually ran?

What this is not

Synthetic traces only, with no RF lab, no real chip silicon, no live PKD or CRL infrastructure. Two named libraries at one deterministic condition, smoke depth, pinned reproduction commit. We are describing behaviour divergence, and we are not claiming a deployed exploit.

Run it yourself

This is the first place in the essay we point at the codebase.

https://github.com/kazuru-chidumbwe/emrtd-differential-harness

Checkout tag blog-b10-2026-07 (commit ef15b10, 7 July 2026). That pin is what this post describes; main may move on without changing the essay's claims.

git clone https://github.com/kazuru-chidumbwe/emrtd-differential-harness.git
cd emrtd-differential-harness
git checkout blog-b10-2026-07
bash scripts/bootstrap-vendor.sh
export GOTOOLCHAIN=auto
make smoke

You should get JSON traces with observability_score: 0 on both baseline drivers. Look in logs/ — the run_id field inside each file matches its filename. On Ubuntu 24.04 with Go 1.25+ (GOTOOLCHAIN=auto), Java 17, and Maven, make smoke finished in under a minute on a warmed lab VM where vendors were already bootstrapped. A cold first clone pays extra time for bootstrap-vendor.sh and compiling JMRTD from vendor source; budget several minutes, not seconds.

One practical wrinkle: the jmrtd-0.5.2 artifact on Maven Central is empty for our build. The bootstrap script compiles JMRTD from vendor source. Budget a few extra minutes the first time.

MIT license. If you extend the work, cite the run_id from your trace.

Closing

Two mainstream OSS passport readers. One synthetic downgrade. Both complete BAC after PACE fails. Both stay silent to a naive caller.

If that matters in your stack, rerun the pin before you ship. The traces are public. The check takes minutes. We are not asking you to trust our summary — we are asking you to run the same profile and read your own run_id.

Further reading: ICAO Doc 9303 · gmrtd · JMRTD · Avoine et al., ePassport protocol survey · BSI TR-03110

Synthetic test environment only. No physical travel document was used. Results apply to gmrtd and JMRTD at TC-AC-01 smoke depth, tag blog-b10-2026-07.

DEV Community: Kazuru

Path Consistency in Kubernetes DNS Stacks: Do Resolvers Agree Under Adversarial Conditions?

Path vs peer

Threat model

Scope / isolation

Related work

Architecture (pair mode)

Smoke gate

Lab pin

Reproduce

What this post is not claiming

A Differential Test Harness for Native vs. Generic XDP: Methodology and Baseline

Background: native vs generic XDP

Corpus (eleven packets)

What the comparator measures

Divergence taxonomy

Harness architecture

Lab profile for this post

Results

Validation

Smoke gate (prog_pass_drop)

Comparator sensitivity (synthetic)

Live backend probes (informational)

Run it yourself

Differential Testing Revealed What Conformance Testing Missed: A Case Study with Open-Source eMRTD Libraries

BAC, PACE, and why we bothered with differential testing

What we were trying to learn

How the experiment is set up

Running the experiment

What showed up on the wire

gmrtd

JMRTD

Why we think integrators should care

A fix that is boring on purpose

The same story elsewhere

What this is not

Run it yourself

Closing

Smoke gate (`prog_pass_drop`)