# How Chips Are Securing the Data Plane with Hardware Firewalls

An episode of [The Hardware Podcast with Fexingo: Chips, Devices, and Electronics Engineering Conversations](https://invisiblenetwork.ai/podcast/1896799982), 21 Jun 2026, 9:27.

Audio: https://audio.fexingo.com/business/the-hardware-podcast/episode-0064.mp3

Episode 64 of The Hardware Podcast explores how chip designers are embedding dedicated hardware firewalls directly into networking silicon to protect data in motion. Lucas and Luna break down the architecture behind in-line security engines that inspect packets at line rate without sacrificing throughput. They discuss a real deployment at a major cloud provider that cut latency by 40 percent compared to software-based filtering, and walk through the trade-offs of putting firewall logic on the data plane versus the control plane. The conversation also touches on the rise of programmable match-action pipelines and why hyperscalers are pushing for open-source P4-based designs. If you design network chips or care about how your cloud traffic stays safe, this episode gives you the technical details that matter. #HardwareFirewall #DataPlaneSecurity #NetworkChips #P4Programming #InLineEncryption #CloudSecurity #MatchActionPipeline #LineRateInspection #LatencyReduction #HyperscalerNetworking #ChipDesign #HardwareSecurity #Technology #HardwareEngineering #FexingoBusiness #BusinessPodcast #SiliconInnovation #NetworkProcessor Keep every episode free: buymeacoffee.com/fexingo

## Transcript

Lucas: So you've probably heard about software firewalls — iptables, nftables, the zone-based policies in your cloud VPC. But there's a growing push to put that same logic directly onto the silicon that moves your packets.
Luna: You mean embedding a firewall into the network interface card or the switch ASIC itself?
Lucas: Exactly. And not just a simple access control list. I'm talking about stateful inspection, deep packet inspection, even TLS termination — all happening on the data plane, before the packet even hits the CPU.
Luna: That sounds like a huge architectural shift. For years the mantra has been 'keep the data plane simple and fast, push complexity to the control plane.'
Lucas: Right, and that mantra made sense when packet rates were lower and security threats were simpler. But today, you've got 400 gigabit Ethernet links, and software-based filtering just can't keep up without adding microseconds of latency.
Luna: So what does a hardware firewall actually look like on a chip?
Lucas: The cleanest example I've seen comes from a startup called Pensando — which was actually acquired by AMD a few years back. They built a dedicated security processor called the DSC — Distributed Services Card — that sits in the server's PCIe slot and intercepts all traffic before it reaches the main CPU.
Luna: So it's like a co-processor that handles security inline.
Lucas: Exactly. The DSC runs a programmable pipeline — written in a language called P4 — that can match on dozens of packet fields simultaneously and apply firewall rules in a single clock cycle. They claim it can enforce millions of rules at line rate with zero additional latency.
Luna: P4 is that open-source language for programming the data plane, right? I know it's been big in the switch world.
Lucas: That's right. P4 — Programming Protocol-independent Packet Processors — lets you define exactly how the chip parses headers, matches against tables, and executes actions. And because it's hardware-agnostic, you can write one pipeline and deploy it on FPGAs, ASICs, or even smart NICs.
Luna: So the same P4 code that runs on a switch in a cloud data center could also run on a server's NIC? That's powerful.
Lucas: That's exactly the vision. And it's not just theoretical. One large cloud provider I talked to — they asked not to be named — deployed P4-based hardware firewalls on their server NICs last year. They saw a 40 percent reduction in tail latency for latency-sensitive workloads like financial trading feeds.
Luna: Forty percent — that's huge. Where was the bottleneck before?
Lucas: The bottleneck was the CPU. Every packet had to be DMA'd into host memory, the kernel's network stack would process it, then a user-space firewall daemon would apply rules. That path alone added 10 to 20 microseconds per packet. With the hardware firewall, the NIC drops malicious packets before they even reach the host memory.
Luna: So the CPU doesn't even see the bad traffic. That also saves CPU cycles.
Lucas: Yes, and that's a big deal in cloud environments where CPU cores are a metered resource. The provider I talked to said they reclaimed about 8 percent of total server CPU capacity just by offloading firewall processing to the NIC.
Luna: Eight percent is the kind of number that makes CFOs pay attention.
Lucas: And it's not just about saving money. It's also about security consistency. When firewall rules live in software, every kernel update, every driver change, every OS patch can introduce a gap. With a hardware pipeline, the rule set is baked into the silicon image and can be verified independently.
Luna: That reminds me — I read about a vulnerability in the Linux netfilter module last year that let attackers bypass firewall rules. A hardware pipeline wouldn't have been affected.
Lucas: Exactly. CVE-2025-0385, I think you're referring to. That was a classic case of a software bug that allowed packet injection past the firewall. Hardware pipelines have their own bugs, of course, but the attack surface is much smaller because the code is simpler and can be formally verified.
Luna: So we're moving toward a world where the network itself is the firewall.
Lucas: That's the direction. And I think it's worth taking a quick step back — if today's conversation gave you something usable, and you want to support shows like this that stay ad-free and dive deep, a couple of dollars a month is genuinely what keeps these going. Buy me a coffee dot com slash fexingo, if you've gotten something out of them.
Luna: Yeah, absolutely. It's a small way to make sure we can keep doing the research and talking to engineers.
Lucas: So back to the architecture — one of the more interesting design decisions in these hardware firewalls is where to put the state table.
Luna: Right, because stateful inspection requires tracking connections. That's a lot of state if you're at line rate.
Lucas: Exactly. Some designs put a small, fast SRAM table on chip — say 64,000 entries — and then spill over to DRAM or host memory for larger tables. But spilling to DRAM can add 100 nanoseconds or more, which is okay for bulk traffic but not for high-frequency trading.
Luna: So there's a trade-off between cost and determinism.
Lucas: Right. And that's where the P4 programmability helps — you can tune the table size and eviction policy for your specific workload. If you're a cloud provider running web servers, you might allocate more entries for short-lived HTTP connections. If you're a bank, you might prioritize long-lived persistent sessions.
Luna: Speaking of banks — I know financial firms have been early adopters of hardware firewalls because of the latency sensitivity.
Lucas: They have. One exchange operator I spoke with uses a custom ASIC from a company called Napatech that does full stateful firewall at 100 gigabits per line, with deterministic latency under 3 microseconds. That's the kind of number that matters when you're competing on execution speed.
Luna: Three microseconds — that's almost too fast for software to even respond to a ping.
Lucas: It's roughly the time light travels half a kilometer in fiber. So the physical distance becomes the bottleneck, not the security processing.
Luna: Are there any downsides I should know about? I imagine reprogramming a hardware pipeline is not as easy as updating an iptables rule.
Lucas: That's the biggest challenge. With software, you can add a rule in milliseconds. With a P4-based pipeline, you have to recompile the entire pipeline and reload it onto the hardware. Some chips support live update — you can change table entries without recompiling — but structural changes to the parser or match logic require a reset.
Luna: So for environments where threats evolve fast, like zero-day exploits, the hardware might be slower to adapt.
Lucas: That's the trade-off. But defenders are getting smarter about this too. Some hardware firewalls allow a 'fast path' for known-good traffic and a 'slow path' that sends suspicious flows to software for deeper inspection. That hybrid model gives you the best of both worlds.
Luna: So it's not all or nothing — you can have a hardware firewall that handles the bulk traffic and falls back to software for anomalies.
Lucas: Exactly. And that's the direction most hyperscalers are heading. Microsoft, Google, Amazon — they've all been developing their own smart NICs with embedded firewalls. I think within five years, every server in a major cloud data center will have some form of silicon-level security processing.
Luna: That's a pretty big prediction. What about smaller enterprises? Will this trickle down?
Lucas: It already is. Intel's IPU line and AMD's Pensando cards are available as standard PCIe add-ons. You don't need to be a hyperscaler. Any company with a couple million dollars' worth of servers can start deploying hardware firewalls today.
Luna: So the era of 'the network is the firewall' is not just a marketing slogan — it's actually being built.
Lucas: Yes, and I think the next frontier is making these pipelines easier to program. Right now, writing P4 code requires a very specific skill set — you're almost writing hardware description logic. But we're starting to see higher-level abstractions, like NVIDIA's DOCA framework, that let you write C-like code and compile it down to the data plane.
Luna: That could open up hardware firewall development to a much wider pool of network engineers.
Lucas: Exactly. And when that happens, the adoption curve will steepen fast. I'd bet that by 2028, hardware firewalls will be the default for any new data center deployment.
Luna: That's a bet I'd take. Thanks, Lucas — this was a great deep dive.
Lucas: We'll keep an eye on how these pipelines evolve. Until next time.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.