<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Verifier on viveksb007</title><link>http://viveksb.dev/tags/verifier/</link><description>Recent content in Verifier on viveksb007</description><generator>Hugo -- 0.147.8</generator><language>en-us</language><lastBuildDate>Sat, 20 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="http://viveksb.dev/tags/verifier/index.xml" rel="self" type="application/rss+xml"/><item><title>How the BPF Verifier Works</title><link>http://viveksb.dev/2026/06/how-the-bpf-verifier-works/</link><pubDate>Sat, 20 Jun 2026 00:00:00 +0000</pubDate><guid>http://viveksb.dev/2026/06/how-the-bpf-verifier-works/</guid><description>&lt;p>In a &lt;a href="http://viveksb.dev/2026/05/bpf-load-c-to-kernel/">previous post&lt;/a> we followed
BPF code from C source all the way to a fully-resolved bytecode stream handed to
the kernel. But the kernel does not just run that bytecode. First it has to be
convinced the program is safe. That job belongs to the &lt;strong>verifier&lt;/strong>, and it is
the reason you can load your own code into the kernel&amp;rsquo;s hottest paths — every
network packet, every system call — without the risk of crashing the machine.&lt;/p></description></item></channel></rss>