Mojo in Networking, Cyber Defense and Ethical Hacking

General
1

Hi everyone,

I’m Ezra, and I’m currently working on a capstone project for Cisco building a sophisticated Intrusion Prevention System (IPS).

For anyone interested in networking and cyber defense should understand how to utilize Tenmo and mjmelo and definitely other machine learning libraries to develop cyber defense systems for prevention of AI driven and Polymorphic Malwares. If the attack is autonomous the defense should be autonomous.

Most of the Mojo buzz is about AI kernels, but for an IPS, the “Networking” part is just as critical. I’m currently looking at how to bridge the gap between Mojo’s computational speed and real-time packet processing.

Since Mojo aims to be a systems language, I’m interested in how we can move past Python.import_module(‘socket’) and start building native, memory-safe network logic.

Has anyone experimented with using Mojo’s structs and fn to interface with lower-level networking C-libs? I’d love to hear how the community sees Mojo’s role in the future of the “Software Defined Network.”

Cheers,

Trojan Ezra

1 Like
2

I think you would be interested in [stdlib] [proposal] Binary IO API by owenhilyard · Pull Request #4728 · modular/modular · GitHub

My general thought is that Mojo needs to have a solid threading model and async model before we sit down to work on IO, since most of the IO that people should use is async, and that once Mojo has that we can go directly for state of the art. Given the current path of evolution of network cards, one question that we may very well have to answer is “what parts of a program should run on the network card?” Mojo has the ability to express P4 and other network-flavored DSLs as an eDSL, which should make some things a lot easier to do, and then the “big pile of ARM cores” DPUs are pretty easy to target. There are also considerations around Ultra Ethernet and Infiniband since they have their own unique sets of capabilities.

One thing you can be reasonably sure of is that I will campaign pretty hard to not having the old BSD sockets API since it has already broken down pretty badly in high throughput networking due to doubling membw requirements and being generally bad for zero copy. There are much better options that make much better use of the capabilities of modern network cards.

1 Like
3

You mention P4 a eDSL -embedded domain specific language. This is gonna get the Model to run directly on the NIC instead of GPU reliance.

To answer your question “Which part of the model should run on the network card?”

The card’s job is Fast Rejection and Normalization. It handles anything that needs to happen at “wire speed” (the speed of the electricity in the cable).

Packet Signature Match (Known Threats): Using P4-style logic, the card can check every packet against a database of millions of known malicious byte-sequences without sending them to your CPU.

Protocol Parsing: The card identifies “Is this HTTP? Is this custom Trojan traffic?” It breaks the packet into parts so the CPU doesn’t have to waste time doing it.

Volumetric Filtering: If you are being hit by a DDoS (10 million packets per second), the NIC drops them immediately. If this ran on the CPU, the CPU would freeze.

Telemetry Generation: The card captures “Metadata” (Source IP, packet size, timing) and sends that to your AI logic instead of the whole heavy packet.

On the other view “which part should run on the hardware?”

This is where your Mojo AI Logic and Polymorphic Malware detection live. The CPU handles “Stateful” and “Contextual” intelligence.

Polymorphic Analysis: Since polymorphic malware changes its “signature,” a simple hardware match won’t catch it. Your Mojo code uses ML models to look at the behavior (e.g., “This packet looks like encrypted shellcode”).

Stateful Inspection: The CPU remembers the history. “This IP sent a normal packet 5 seconds ago, but now it’s trying to overflow a buffer.”

Rule Updates: When your AI discovers a new threat, it “compiles” a new rule and pushes it down to the Network Card (using that Mojo-as-eDSL approach we discussed).

4

To answer your question “Which part of the model should run on the network card?”

This isn’t a question that I asked, I don’t think any part of a model, aside from possibly something very small living in a dedicated accelerator, will run on a NIC due to resource and compute limits.

This is gonna get the Model to run directly on the NIC instead of GPU reliance.

You won’t do much more than linear regression on a NIC due to compute limitations when trying to do high packet rates. P4 also isn’t natively an eDSL, it’s just that Mojo can express other languages inside of itself.

Using P4-style logic, the card can check every packet against a database of millions of known malicious byte-sequences without sending them to your CPU.

There aren’t any NICs I’m aware of that have enough match table space for that.

Protocol Parsing: The card identifies “Is this HTTP? Is this custom Trojan traffic?” It breaks the packet into parts so the CPU doesn’t have to waste time doing it.

This is not typically how it is done, instead the CPU will get the whole packet but the protocol list will be pre-parsed.

If you are being hit by a DDoS (10 million packets per second), the NIC drops them immediately. If this ran on the CPU, the CPU would freeze.

Plenty of pure software systems can do 10 million pps.

On the other view “which part should run on the hardware?”

Mojo is a systems programming language, so I more mean things like whether you do user authentication or TLS handshakes on the NIC.

5

Owen respecting your role and monotrone computer science background.

I might have some skepticism towards your view that NICs are only limited to linear regression.

Modern NICs and Data Processing Units have higher computational capabilities. An Example is NVIDIA Blue Field 3.

This are the capabilities modern NICs can do that are beyond linear regression -just math.

1. Programmable Data Planes (P4 & eDSLs)

Since you are using P4 and Mojo, you know that NICs are now programmable. They don’t just “pass packets”; they execute match-action pipelines. This allows for:

Stateful Inspection: Tracking connection states at wire speed without hitting the CPU.

Custom Protocols: Defining how packets are parsed and routed at the hardware level.

2. Advanced Machine Learning (In-Network Computing)

Modern DPUs can run much more than linear regression. They are increasingly equipped with Tensor cores or FPGA logic capable of:

Random Forests & Decision Trees: Used for real-time telemetry and identifying “floccinaucinihilipilicated” (worthless) traffic or malicious patterns.

K-Nearest Neighbors (KNN): For anomaly detection in packet headers.

Neural Network Inference: Offloading small, quantized models to detect intrusions at the edge of the network before the traffic even reaches the kernel.

3. Direct Memory Access (DMA) & Zero-Copy

Your requirement for direct DMA access is the key differentiator. By bypassing the legacy BSD sockets and standard kernel interrupts, the NIC performs Zero-Copy operations. This allows the hardware to:

Move data directly from the wire to user-space buffers (where your Mojo/Rust logic lives).

Handle Encryption/Decryption (IPsec/TLS offload) at 100Gbps+ without the CPU breaking a sweat.

Hey Owen let me know your view towards but the table space of network packets is much wíder upto 70million pps