DEV Community: Adam Weber

eBPF

Adam Weber — Sun, 25 Jan 2026 20:32:39 +0000

After spending the last few posts working through character drivers and proc entries, I decided it was time to take the plunge into eBPF. I'd heard the name thrown around in every security and observability discussion, but honestly had no idea what it actually was or why everyone seemed so excited about it. This post documents my first real encounter with eBPF and what I learned building a minimal process execution tracer.

What Even Is eBPF

eBPF stands for extended Berkeley Packet Filter, which is a confusing name because it does way more than just filter packets now. The core idea is that you can inject code into the running kernel without writing a traditional kernel module. That code runs in a sandboxed environment where the kernel verifies it's safe before loading it. If your BPF program would do something dangerous, it just fails to load instead of kernel panicking your system.

Coming from kernel modules where a bad pointer dereference means instant death, this felt almost too good to be true. You get kernel-level visibility and performance without the danger.

The Two-Part Architecture

What caught me off guard initially was that an eBPF program isn't just one file. It's actually two separate programs working together:

The kernel-side BPF program, written in restricted C and compiled to BPF bytecode. This is the code that runs inside the kernel when events happen.

The userspace loader, which is a normal C program that loads the BPF bytecode, attaches it to kernel hooks, and reads the data back out.

This split makes sense after I thought about it. The kernel-side code has to be heavily restricted for safety, so you can't just printf() or write to files from kernel space. The userspace program handles all the normal I/O and orchestration.

Building the Execve Tracer

I started with the simplest useful thing I could think of: tracing process execution. Every time a process calls execve() to start a new program, I wanted to see it.

The kernel-side code hooks into a tracepoint called tp/syscalls/sys_enter_execve. When that fires, my BPF program grabs the process ID and command name, then writes them to a ring buffer. The ring buffer is basically shared memory between kernel and userspace that both sides can access safely.

The userspace program loads this BPF code into the kernel, polls the ring buffer for events, and prints them to the terminal. Simple enough in theory.

The Compile Process

This is where things got interesting. The BPF program gets compiled with Clang to BPF bytecode, producing a .bpf.o file. That's not a normal executable, it's an ELF object file containing BPF instructions. The section names in that ELF file tell the loader what type of program it is and where to attach it.

For example, SEC("tp/syscalls/sys_enter_execve") creates an ELF section with that exact name. When the userspace program opens the .bpf.o file, libbpf parses those section names to figure out "oh, this is a tracepoint program that should attach to sys_enter_execve."

It's a clever way to encode metadata using standard ELF features instead of inventing something new. Listen to me I sound like I know what I'm talking about.

Testing It

After getting everything compiled, I ran the tracer with sudo (BPF programs need root to load). Then in another terminal I just ran normal commands: ls, ps, cat. They mostly all showed up as bash, until you run something like vim.

What really hit me was how lightweight this felt compared to kernel modules. No rebooting. No risking a kernel panic. If the BPF program had a bug, it just wouldn't load (believe me I found out). The kernel's verifier checks every instruction before allowing it to run.

Ring Buffers and Communication

The ring buffer deserves its own mention because it's the bridge between kernel and userspace. It's a fixed-size circular buffer that prevents memory issues. When it fills up, old events get overwritten. This ensures you're never allocating unbounded kernel memory or writing to invalid addresses.

The kernel-side code reserves space, writes the event, and submits it. The userspace code polls for new events and processes them. The whole thing is lock-free for most operations, which keeps it fast.

Why This Matters

eBPF is the foundation of modern system observability and security tools. Every major EDR (Endpoint Detection and Response) product uses it. Tracing tools like bpftrace are built on it. Understanding how to write BPF programs means understanding how these tools work under the hood.

For GhostScope specifically, this opens up the ability to watch syscalls, trace file operations, monitor network connections, and generally observe system behavior in ways that weren't practical before. All without maintaining a risky kernel module.

What's Next?
Not quite sure, stay tuned to find out.

Debugging a Filesystem Module: When Reference Counting Goes Wrong

Adam Weber — Wed, 07 Jan 2026 16:34:52 +0000

As I've been working my way through Linux kernel development,I decided it was time to tackle something that seemed simple on the surface: write a minimal filesystem module. How hard could it be to mount a filesystem that contains a single file you can cat? Turns out, pretty educational.

The Goal

I wanted to build the smallest possible virtual filesystem. No disk backing. No persistence, just cat a static file that is generated by the module.The whole thing should live in RAM, expose one file called "hello" that returns some text.

Seems like the next natural step. I mean, how different could it be?

The First Attempt

I started by doing what seemed obvious: create a superblock in fill_super, manually allocate inodes for the root directory and my hello file, create dentries for them, link everything together. Standard VFS stuff. The code compiled. The module loaded. I could mount it. I could even cat the file and see my message.

Then I tried to unmount.

[  337.050239] gs_fs: superblock kill called
[  337.050258] ------------[ cut here ]------------
[  337.051811] BUG: Dentry still in use (1) [unmount of gs_fs gs_fs]
[  337.053385] WARNING: CPU: 0 PID: 72 at fs/dcache.c:1590 umount_check+0x56/0x70

The kernel was not happy. "Dentry still in use" means I left references dangling somewhere. The VFS couldn't clean up properly because something was still holding onto my hello file's dentry.

Down the Rabbit Hole

The error message told me exactly what was wrong but not why. I had to understand the lifecycle of dentries and inodes and their reference counting, and how the VFS expects you to clean up during unmount.

First theory: maybe I needed to implement evict_inode. So I added a proper super_operations struct with an evict callback that calls truncate_inode_pages_final() and clear_inode(). That's the standard pattern for cleaning up inodes (so it seems to me, correct me if I'm wrong PLEASE!).

Nope.

Second theory: maybe it's how I was creating the dentries. I was using d_alloc_name() to manually create the dentry for my hello file during mount. That gives you a dentry with a reference count, and there's no automatic mechanism to drop it. The VFS doesn't know about dentries you create manually like that (again, PLEASE set me straight if that's not the case).

But here's the thing, I wasn't just randomly guessing. I started looking at how other simple filesystems do it. And that's when I found simple_fill_super(). Probably should start reading more of the kernel docs, I guess?

The Kernel's Helper Functions

Turns out the kernel has a bunch of helper functions specifically for pseudo-filesystems like mine. simple_fill_super() takes an array of file descriptors and sets up all the dentries, inodes, and reference counting for you automatically. It handles the lifecycle properly.

So I refactored to use it:

static int gs_fs_fill_super(struct super_block *sb, struct fs_context *fc)
{
    static const struct tree_descr files[] = {
        { HELLO_FILENAME, &gs_hello_fops, 0444 },
        { "" }  // Sentinel
    };

    sb->s_op = &gs_fs_super_ops;
    return simple_fill_super(sb, GS_FS_MAGIC, files);
}

Mounted it. Cat'd the file. Worked great. Tried to unmount.

Nope.

The Real Problem

At this point I was getting frustrated. I had the right helpers. I had proper cleanup. What was I missing?

Then I looked more carefully at my kill_sb function:

static void gs_fs_kill_sb(struct super_block *sb)
{
    pr_info("gs_fs: superblock kill called\n");
    kill_anon_super(sb);  // This was the problem
}

I was using kill_anon_super() because I saw it in some example somewhere and it seemed reasonable. Anonymous superblock, right?

When you use get_tree_nodev() with simple_fill_super(), you need to use kill_litter_super() instead. kill_litter_super() knows how to properly clean up structures created by simple_fill_super(). It handles all the dentries and inodes that got set up by that helper.

Changed one line:

static void gs_fs_kill_sb(struct super_block *sb)
{
    pr_info("gs_fs: superblock kill called\n");
    kill_litter_super(sb);  // Fixed
}

Perfect!

Why This Matters

This bug taught me more about the VFS than any amount of documentation reading could have (entirely speculation here, as I can't actually read). I had to dig into:

How dentries cache the filesystem namespace
How reference counting prevents premature cleanup
Why the kernel provides helper functions and when to use them
How different superblock types need different cleanup strategies

The kernel has these subtle API pairings all over the place. Use get_tree_nodev()? Pair it with kill_litter_super(). Use simple_fill_super()? Make sure your super_operations are set up properly. The compiler won't catch these mismatches because they all compile just fine. You only find out at runtime.

A valuable set of lessons taught by getting my hands dirty.

What's Next

Now that I have a working minimal filesystem, the obvious next steps are:

Implement write support
Add subdirectories
Make files appear on-demand via .lookup

Not sure I'll continue on the filesystem path or divert, but we'll see.

Minimal Character Driver

Adam Weber — Mon, 08 Dec 2025 20:18:42 +0000

In the last post I spent some time messing around with proc entries. That was a really good first step because it forced me to understand how the kernel exposes simple debug surfaces to userspace without dealing with any actual device semantics. But the next step in this journey is getting into something that behaves like a real device, something I can open from userspace and talk to. That means writing a character driver.

At first you might be thinking, isn’t this the same thing as making a proc entry? Both expose a "file", right? But once you start writing it, the difference becomes obvious. A proc entry is just a virtual file owned entirely by the procfs layer. It’s for state dumps, metrics, small control knobs. A character driver is an actual device. It shows up in /dev. You open() it. You write() to it. The kernel gives it a major and minor number. Userland treats it like a real hardware-backed device, even if the thing behind it is just your code and a chunk of RAM.

The Minimal Device

I wanted to start with the smallest possible character driver that still works like the real thing. Something that loads as a module, registers a device number, and shows up in /dev so userspace can interact with it. No hardware. No complicated concurrency. Just the basics.

Here’s the flow the kernel expects:

Allocate a major/minor number for the device.

Initialize a cdev and register it with the kernel.

Create a class so udev has something to hook into.

Create the actual device node so it appears under /dev.

Implement the basic file operations: open, release, read, write.

That’s it. Once that scaffolding is in place you’ve got a real Linux device. It's really nice to know that it's just a bunch of call backs set in the proper structure and your'e done.

The Code

I wrote a tiny driver called gs_char. It exposes a small 256 byte buffer. Whatever you write into it gets stored in kernel memory. When you read from it, you get the last thing you wrote. It’s not fancy, but that’s not the point. The point is understanding how the kernel expects a character device to behave.

The file operations look almost exactly like what you’d expect coming from userland. read() copies data from the kernel buffer out to userspace. write() copies data from userspace back into the kernel buffer. Nothing magic.

The initialization code is where the important stuff happens. alloc_chrdev_region() gives you a major/minor. cdev_add() tells the kernel about your driver. class_create() and device_create() make sure the device node shows up in /dev without you having to run mknod manually (in theory, not practice for me, more later). After that you can load the module and immediately see:

/dev/gs_char

And that part would honestly be really satisfying.

Testing It

With the module loaded inside QEMU, my /dev/gs_char entry was not created. Sad face. It seems though that at first glance I thought something was wrong with my module, but then quickly realized I didn't have anything running to handle the device entries. So a quick mknod later and I'm up and running.

echo "hello kernel" > /dev/gs_char
cat /dev/gs_char

And the driver prints out the open, read, write, and close messages using pr_info, so you get a nice trace in dmesg showing each step.

Why This Matters

This little driver is the doorway into all the real kernel work I want to do. Understanding the lifetime of a device, how file operations work, and how major/minor numbers get managed, it becomes way clearer how subsystems behave. This is also where a lot of the kernel’s design patterns start becoming familiar. You stop thinking of drivers as weird special things and you start seeing them as normal kernel code with a few well-defined entry points. A point that's always amazed me since my first OS class. That the operating system and the compilers are just pieces of software themselves. They just have a very special role.

What's next I don't know. Stay tuned!

Babies first /proc entry

Adam Weber — Mon, 08 Dec 2025 17:02:25 +0000

Over the last couple of posts in this series I’ve been digging deeper into building small kernel modules against mainline, getting them to run cleanly under QEMU, and slowly building up the muscle memory for day-to-day kernel work. Up to this point I’ve only been dealing with pr_* output or simple tracepoints or kprobes, so I figured the next logical step was to expose data from a module to user space. As I understand it the easiest place to start with that is the proc filesystem.

This post walks through creating a small read-only /proc entry using the modern, accepted interfaces in the Linux kernel. No deprecated APIs, no shortcuts, and nothing that would get laughed out of a patch review. Hopefully.

Understanding /proc at a high level

The important thing to remember is that nothing in /proc actually lives on disk. The proc filesystem is a virtual filesystem created by the kernel. When you read a file in /proc, the kernel runs code that generates the content on the fly.

That makes proc files useful for state dumps, diagnostics, or anything where you want to give user space a quick window into whatever your module is doing.

The modern way of creating proc entries uses two pieces:

proc_create() with a set of struct proc_ops

The seq_file API, usually through the single_open() helper

This is the pattern that upstream kernel developers expect. Older APIs still exist in tree history, but you should not use them in new code. As I understand it.

The module

Here’s the complete module. This creates a /proc/gs_proc_demo entry that returns a message plus the current value of jiffies.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>

#define PROC_NAME "gs_proc_demo"

static int gs_proc_show(struct seq_file *m, void *v)
{
    seq_printf(m, "hello from %s\n", PROC_NAME);
    seq_printf(m, "jiffies: %lu\n", jiffies);
    return 0;
}

static int gs_proc_open(struct inode *inode, struct file *file)
{
    return single_open(file, gs_proc_show, NULL);
}

static const struct proc_ops gs_proc_ops = {
    .proc_open    = gs_proc_open,
    .proc_read    = seq_read,
    .proc_lseek   = seq_lseek,
    .proc_release = single_release,
};

static int __init gs_proc_init(void)
{
    proc_create(PROC_NAME, 0, NULL, &gs_proc_ops);
    pr_info("%s: loaded\n", PROC_NAME);
    return 0;
}

static void __exit gs_proc_exit(void)
{
    remove_proc_entry(PROC_NAME, NULL);
    pr_info("%s: unloaded\n", PROC_NAME);
}

module_init(gs_proc_init);
module_exit(gs_proc_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("adam");
MODULE_DESCRIPTION("Proc filesystem demo");

A couple of quick notes that helped me understand what’s going on:

single_open() sets up the seq_file context and ensures your show() callback runs exactly once per read. That means you don’t need to think about offsets or partial reads.

Your show() function should never call printk. You write to the seq_file using seq_printf(). In general it seems that one should never call printk, and instead should use the pr_* macros.

The contents are generated every time user space reads the file. Nothing is cached.

Building against mainline

Same workflow as the earlier modules:

make -C /path/to/torvalds/kernel M=$PWD modules

Boot into your QEMU VM that’s running the same kernel image.

Insert the module:

insmod gs_proc_demo.ko

Read from the proc entry:

cat /proc/gs_proc_demo

Output looks something like:

hello from gs_proc_demo
jiffies: 12345678

Remove it:

rmmod gs_proc_demo

Why this matters

Creating a /proc entry is one of those small steps that teaches you several deeper kernel development concepts at the same time: how the VFS layer works, how seq_file buffers output safely, how live kernel data is exposed to user space, and how kernel modules interact cleanly with filesystem interfaces.

It’s also one of the first things you’ll run into when reading real-world kernel code. Most subsystems have at least one proc entry for debugging or state dumping. Being comfortable with this pattern means you’re finally out of “hello world” territory and starting to write modules with actual interfaces.

Next up? I don't know honestly, maybe a quick comparison of /proc, sysfs, and debugfs, and where each one is appropriate.

Thanks for reading and as always if you've any suggestions I'd love to hear them.

Tainting the kernel

Adam Weber — Wed, 03 Dec 2025 19:10:54 +0000

Introduction

In this post, I continue documenting my journey as I pivot into Linux kernel development. This week I spent time understanding how to instrument the kernel using tracepoints and kprobes. My goal was to observe process lifecycle events in a running kernel and eventually build a small out-of-tree module that hooks into these events.

I ran into a few unexpected issues, including missing symbols, build environment mismatches, and understanding how tracepoint definitions propagate through the kernel build system. This post walks through the concepts, what I tried, what worked, and what I learned.

What I Was Trying To Do

Access a specific tracepoint (like sched_process_exit) from an out-of-tree module.

Experiment with registering a probe that fires when processes exit.

Validate the behavior in a QEMU guest running a kernel built from mainline sources.

The bigger purpose being to learn kernel instrumentation, understanding how trace events are plumbed, exploring debugging tooling, etc.

Understanding How Tracepoints Work

Tracepoints are static instrumentation sites built directly into the kernel code.

They expose a small, stable ABI for things like scheduler events, block I/O, filesystem operations, etc.

They are declared with macros that generate a struct named _tracepoint.

Accessing a tracepoint from a loadable module requires that the tracepoint symbol exists in the kernel’s symbol table.

Tracepoint symbols do not always exist in Module.symvers for out-of-tree modules. In fact it seems that most don't as they're not exported.

Some tracepoints depend on config options.

If the kernel was not built with tracing support enabled (like CONFIG_TRACEPOINTS, CONFIG_SCHEDSTATS, or CONFIG_EVENT_TRACING), the symbols may not be exported.

While this was interesting to learn, it seems that more often than not these are not exported for external modules. This makes sense for safety, while it was edifying to go down this route ultimate it did not end up meeting my needs.

Kprobes as an Alternative

Kprobes allow attaching dynamic probes to almost any kernel function.

Unlike tracepoints, kprobes do not require kernel config flags or static declarations. In fact if you are building external modules you might run into compilation issues if certain flags are set for instrumentation.

They work even when the kernel was not built with full tracing options.

They can be registered from an out-of-tree module with minimal prerequisites.

This module does the following:

Defined a struct kprobe

Set the symbol name (for example, "do_exit" or "release_task")

Registered pre-handlers and post-handlers

Added pr_info logging for validation

Kprobes are incredibly flexible but less stable than tracepoints.

They depend on internal function names which can change across kernel versions.

The Build Environment Problem I Hit

I'm building the kernel on a host machine.

I'm loading the module into a QEMU VM running a kernel built from a checkout of the mainline source tree.

I found that most tracepoint symbols are not exported. Leaving my module to have issue in linking.

Running grep __tracepoint_sched_process_exit Module.symvers returned nothing, which was the clue.

This was were I decided to use kprobes, which avoid the symbol export issue entirely.

Results

The kprobe fired reliably during process teardown.

I print small debugging messages, found in dmesg.

So I learned:

Getting the tracepoint symbol exported in an out-of-tree module is not a thing that, while possible with kernel source modification, should be done. Perhaps this whole idea of an out-of-tree module that can instrument internals is doomed from the beginning. But hey, this is how we learn. I'd love to hear a more experienced perspective on this.

Exported symbols appear in Module.symvers. This is what something called modpost seems to use.

Key Lessons Learned

Tracepoints depend heavily on kernel config and build environment.

Kprobes are powerful when you just need visibility.

Further understanding the kernel build system (Module.symvers, CONFIG options, modules_prepare).

Instrumentation is a good entry point for learning kernel internals.

What’s Next

I think I might go back toward doing a basic character driver, syscall, or /proc creation. I'm not sure, but if you have a suggestion I'd love to hear it. Stay tuned.

Kernel Module Dev Environment

Adam Weber — Fri, 28 Nov 2025 19:05:13 +0000

I’ve been poking at kernel development recently; partly for fun, partly for career growth, partly because I want to understand the layers I’ve leaned on for years.

This post continues that thread: small, incremental steps, written as reminders to myself and hopefully helpful to anyone taking a similar path.

This time, I wanted to get a kernel module development environment working end-to-end. Nothing glamorous. No drivers. No deep dives into subsystems. Just:

Build the kernel
Boot QEMU with it
Build a module
Insert it
Watch it say hello
Remove it

As usual, half the battle is just wiring together all the moving pieces correctly. So this post documents what I did, what worked, and what I want to remember later.

Step 1

Set up a dedicated folder for modules

First lesson: keep module work isolated so you don’t end up polluting the kernel tree.

mkdir -p ~/kernel/hello
cd ~/kernel/hello

Good fences make good neighbors.

Step 2

Write the simplest possible module

Kernel modules are surprisingly small once you strip away the noise. Here’s the entire thing:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("AWs.");
MODULE_DESCRIPTION("Hello world kernel module");
MODULE_VERSION("0.1");

static int __init hello_init(void)
{
    pr_info("Hello: module loaded!\n");
    return 0;
}

static void __exit hello_exit(void)
{
    pr_info("Hello: module unloaded!\n");
}

module_init(hello_init);
module_exit(hello_exit);

It loads, prints a message, and unloads. Found in console output as well as dmesg.

One thing I wanted to remind myself here:
Userland logging is not kernel logging.

Use pr_info() instead of printf(). Muscle memory is strong, but so is printk. Note to self, explore the rest of the pr_* macros.

Step 3

Use the kernel’s build system.

Create a Makefile:

obj-m += hello.o

KDIR := /path/to/your/kernel/source
PWD := $(shell pwd)

all:
    $(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
    $(MAKE) -C $(KDIR) M=$(PWD) clean

Setting KDIR to my source path.

Step 4

Build it

make

Once I got everything lined up correctly I got:

hello.ko

Step 5

Get the module into QEMU (virtio-fs)

The nicest way to test that I could find was adding the following to my qemu alias. There is almost certainly a better way to do this, such that I won't have to modify it for other modules.

-fsdev local,id=mods,path=~/kernel-dev/hello,security_model=none \
-device virtio-9p-pci,fsdev=mods,mount_tag=mods

Then inside the VM:

mkdir -p /mnt/mods
mount -t 9p -o trans=virtio mods /mnt/mods

Mounting the hosts modules folder

Step 6

Insert the module

Inside the VM:

insmod /mnt/mods/hello.ko

Confirm with dmesg

dmesg | tail

in which I found

Hello: module loaded!

Along with a warning about polluting the kernel.

finally remove it.

rmmod hello

and again:

dmesg | tail

I observed

Hello: module unloaded!

What this means for me:

I built my own kernel
I booted it
I built a module against it
I loaded that module into the kernel
I then unloaded it from the kernel

This is my pipeline for future kernel work. If you have experience let me know any tips or changes you think I should make.

What I’m doing next:

Probably /proc/hello or a sysfs attribute. Maybe standing up a minimal character driver.

The working dev environment was the real milestone.

If you’re doing your own kernel experiments, I’d love to hear what you’re building.

Panic in the sandbox

Adam Weber — Wed, 26 Nov 2025 18:05:42 +0000

Day 1 — Trying to get the QEMU kernel sandbox going

Time to setup the environment for kernel development. Rather than risk shooting myself in the foot on my bare host, I decided to: build a custom kernel + minimal user land, and boot it inside QEMU.

What I thought would be a straightforward path — went somewhat astray, or at least was different than what I'd expected it would be.

What I did

Clone a recent upstream Linux kernel source tree.

Installed dependencies (compiler, build tools, kernel-dev libs, etc.).

QEMU

Configure the kernel (make defconfig), enabled built-in drivers I expected to need (make kvm_guest.config). Which the built in configs for kvm was nice to find instead of having to menuconfig and change them all myself, or write config snippets and merge them with merge_config

init

Built a minimal root filesystem using BusyBox + a tiny initramfs / minimal userland. This provided a good refresher of how booting the kernel works.

Launched QEMU: point it to the kernel image, attach the rootfs, set console/serial, etc.

What I expected

A quick "hello world" environment. Boot → get a kernel log on serial → minimal root shell → experiment with loading modules / tinkering / debugging — all safely sandboxed, without risking my host’s stability.

What followed was… a lot of head-scratching.

Mostly I spent a ton of time digging through forums and reading posts about how the systems worked, but it really wasn't all that bad. Starting with some kernel panics as init wasn't built properly or I was pointing to the wrong bzImage. Once I got all the pieces properly laid out it all worked perfectly. A nice safe environment where I don't have to worry about crashing my daily driver.

What’s next

Build and test a trivial kernel module, load it, unload it.

A Simple Binary

Adam Weber — Thu, 20 Nov 2025 13:34:31 +0000

Day 1

I’m starting a project to get back closer to the machine where I love to be. I'm not going to start with anything ambitious, but by coming back to something simple: compiling a tiny C program and inspecting the binary that drops out.

I’ve spent decades building systems where performance, architecture, concurrency, and distributed correctness mattered — but it’s amazing how grounding it can be to step back and revisit the basics. Sometimes the smallest artifacts remind us of the real machinery beneath all the abstractions.

So today’s exercise was straightforward:

#include <stdio.h>

int main(int argc, char ** argv){
    (void)argc;
    (void)argv;
    printf("Hello world!\n");
    return 0;
}

Compile it, and now we have a binary. Nothing special. But it’s a good excuse to remember what actually happens when we run a program.

Programs don’t start at main

Even for a tiny program, the binary is more than just my code. It represents the entire journey:

C source → compilation → linker → assembly → machine instructions
→ stored in an ELF binary → loaded by the OS → environment and runtime initialized → then main() is called

Having spent a good amount of time in a higher level environment, it's good to remind myself of this.

In reality, when the OS runs this binary, it doesn’t jump straight to main. It jumps into _start, which:

Sets up the stack and registers
Prepares arguments and environment
Hooks up the dynamic loader
Transfers control to __libc_start_main
Which finally calls our main

A good reminder of binary internals

Ghidra helped me put this back into focus:

A container of machine code
A structured file format with defined sections (.text, .data, .rodata, etc.)
Metadata telling the kernel how to load it
Instructions designed to map cleanly onto CPU execution flow

It’s a small thing, but seeing that movement from structure → execution never stops being satisfying.

Why start here?

My goal is to grow this project into deeper territory:

Kernel modules
eBPF tracing
Malware analysis
Reverse engineering
System-level telemetry tools

And certainly some rabbit holes I don’t know about...

Starting simple is intentional.

It’s worth resetting my mental model of:

“What is a program, to the OS?”

Rebuilding that mental foundation helps everything else make more sense. At least for me.

Even if I’ve known these things forever, revisiting them cleanly helps switch the brain back into systems mode — away from frameworks, clouds, and abstractions and back into the machine. Snuggled up spooning with the hardware.

What’s next

Next steps will be just as incremental:

Writing my first kernel module again
Loading it with insmod
Reading logs through dmesg

Nothing grand, just onward progress.

This is a slow burn, but a good reminder for me.