[ Blog_Posts ]

Debugging the Ubuntu 6.8 Kernel in GDB & QEMU — Without Rebuilding It

Attach GDB to a stock Ubuntu 6.8 x86-64 kernel in QEMU, set a breakpoint, and watch nothing happen. The kernel is running fine. The bug isn't in the code — it's that KASLR moved the kernel and your symbols didn't. How to fix it without a rebuild.

2026-09-07 Harrison Guo 4 min read kernel x86_64 ubuntu qemu gdb kaslr linux debugging

Building & Debugging a Custom ARM64 Linux Kernel — Yocto, QEMU, GDB

Rebuild an ARM64 Linux kernel with Yocto, boot it in QEMU, and step through it in GDB — on a laptop, no hardware. The workflow is the easy part; the part nobody tells you is why GDB can't find your source and how to fix it.

2026-09-06 Harrison Guo 5 min read kernel arm64 yocto qemu gdb linux debugging embedded

Cache Miss, TLB Miss, False Sharing — Three Killers Your Profiler Won't Name

top shows 100% CPU. perf shows the truth. Two threads doing identical work run in 841ms or 8118ms depending on one thing your profile never mentions: where their data sits in memory. Cache misses, TLB misses, and false sharing, with real code and real numbers.

2026-09-06 Harrison Guo 6 min read cpu cache tlb false-sharing perf performance memory-model coretracer

eBPF on Linux — kprobe vs fentry: Hooking Internals & What Production Observability Misses

kprobe and fentry both hook kernel functions from eBPF, but they install differently, cost differently, and hand you arguments differently. A source-level comparison, grounded in a real eBPF project, plus why the choice is a production cost — not trivia.

2026-09-06 Harrison Guo 9 min read ebpf kernel linux observability kprobe fentry tracing bpf

From Real Mode to Protected Mode — What the GDT and IDT Actually Define

Every x86 machine boots in 16-bit real mode and switches to protected mode in its first moments of life. That switch is a GDT, an IDT, one bit in CR0, and a far jump — and those tables are where ring 0 vs ring 3 actually comes from. Walked through real bootloader assembly.

2026-09-06 Harrison Guo 7 min read x86 protected-mode gdt idt bootloader assembly kernel low-level

How x86 Conditional Jumps Really Work — EFLAGS, Not Operands

ja, jb, je, jl don't read your operands. They read bits in EFLAGS that some earlier instruction wrote — and it isn't always the cmp you think. Once you see that in GDB, reverse engineering and crash-dump triage stop being guesswork.

2026-09-06 Harrison Guo 6 min read x86 assembly eflags gdb pwndbg reverse-engineering debugging

Store→Load Reordering: x86 vs ARM64, and the Bug Intel Was Hiding

The same lock-free C program runs clean on Intel for hours and fails on ARM64 in a minute. The source is identical. This is store→load reordering — why x86's TSO hides it, why ARM64 exposes it, and what a fence actually does — with a real litmus test and its numbers.

2026-09-06 Harrison Guo 8 min read memory-model x86 arm64 concurrency lock-free reordering tso

The Approval Prompt Is Not the Sandbox

Codex ships 43,591 lines of sandboxing across four platform backends, and treats enforcement and approval as two separate axes. Pi ships none and says so in its README. Both are defensible. What is not defensible is the assumption in between, where a dialog box gets mistaken for a boundary. A source-level look at what your coding agent can actually do to your machine.

2026-09-04 Harrison Guo 8 min read agent-security sandboxing seatbelt landlock openai-codex pi-agent prompt-injection trust-boundary coding-agents

Three Agent Harnesses, One Loop

Claude Code's agent loop is 1,729 lines. Codex's is 983. Pi's is 794. Three teams, three languages, no shared code, and the loop lands in the same place every time. What does not converge is where each one puts its boundary, and that turns out to be the whole design. A source-level read of two harnesses that are now open, against one that leaked.

2026-09-01 Harrison Guo 12 min read agent-harness claude-code openai-codex pi-agent agent-architecture source-analysis ai-engineering coding-agents

Your Model File Is Untrusted Input

Sixty-five bytes are enough to kill llama.cpp. Not by corrupting memory, by handing the GGUF loader a tensor dimension of zero and letting a bounds check divide by it. The check was already there and looked correct. Zero is a legal dimension the format is supposed to support, which is why rejecting it was never the fix. A note on two crashes I fuzzed out of the loader, what the review changed, and why a downloaded model deserves the suspicion you give a downloaded executable.

2026-08-26 Harrison Guo 8 min read gguf llama.cpp fuzzing libfuzzer addresssanitizer parser-security trust-boundary ai-infrastructure local-llm

[ Blog_Posts ]

[ Connect_With_Me ]