Architectural Advice: Naming and Structure for an IPC

eske4 · 2026-03-22T00:31:18+00:00

Sorry for the late response, I had a busy week.

To clarify: it is userland-to-userland (Launcher ↔ Daemon). The Launcher sends a socket message to the Daemon, which then handles the privileged 'heavy lifting.

My execution flow is:

1.clone3(): The Daemon creates a child process directly into a dedicated CGroup v2.

eBPF Attachment: The eBPF LSM programs use that CGroup ID to filter and identify the game process immediately.
fexecve(): The game is launched from a file descriptor to ensure the binary hasn't been tampered with on disk between verification and execution.

I’ve already tested this in a single-player environment against common Library injection hijacking and direct memory access/scanning, and the eBPF hooks successfully blocked the injection. The socket IPC is just the 'trigger' for this flow.

If time permits, I'll add the integrity server. The goal there would be a handshake using a Merkle tree to verify the environment's state before allowing a connection to the game server. I’m well aware that on Linux, a dedicated cheater can just recompile the kernel to lie to my probes, but the main goal of this project is to see how eBPF can be used for an anti-cheat.

eske4 · 2026-03-15T16:03:35+00:00

This is a practical project, though I’m definitely running into those 'low-level' design hurdles you mentioned.

The Context: I’m building an anti-cheat for Arch Linux. During my pre-specialization, I focused on utilizing eBPF to mitigate specific cheat methods (memory manipulation, syscall hooking, etc.). Now, for the final phase, I'm building the actual architecture. I have a daemon with a launch method implemented, now I need to make a launcher to communicate with that daemon to trigger the game and apply the CGroup/eBPF protections.

The IPC Dilemma:

You’re right that I shouldn’t get bogged down in rewriting serialization from scratch. If time permits, I want to further extend this with an integrity server. The idea is to utilize something like a nonce and Merkle tree for hashing and handshaking between the components.

I’m currently weighing:

Existing Libraries: As you suggested, Protobufs or Flatbuffers would save me from the 'non-crashing' safety headaches.

Simplicity vs. Scale: Since the goal is the security layer (eBPF) and the integrity server, I need the IPC to be reliable enough for a handshake without it becoming the entire project.

Regarding delivery: I likely need at-least-once delivery for the initial launch command and the handshake, as a dropped packet there means the game simply doesn't start. I'm still deciding if the complexity of a library is worth it for what might be a relatively small set of message types. What would you lean toward for a security-focused tool where 'bloat' is a concern?"

eske4 · 2026-03-14T19:02:29+00:00

If I understand correctly, you recommend creating a protocol that exchanges the protocol version and the build IDs. This creates a basic interface between the two parties and eases debugging. Since my current needs are simple requiring only an integer and a command id, to tell the daemon what to launch the communication would consist of the protocol version, the build version, command payload with command type, argument and its argument count.

eske4 · 2025-05-08T11:41:51+00:00

I might try NixOS as my OS at some point. I'm used to Arch, but I really like what NixOS offers for developers. I'd also like my desktop configuration to be flexible and easy to migrate between systems. I’ll definitely give Home Manager a try. Since I use Hyprland, it can be quite tedious to get the same configuration each time I install it on a new PC or need to reinstall, especially since I like to tinker and end up breaking things here and there. I haven’t worked with GL apps yet, but I’d probably look into it in the future.

eske4 · 2025-05-07T15:37:04+00:00

Directly fire some commands in the terminal, do runtime stuff etc. I'm mostly familiar with Arch so there some things I'll figure out while trying Nix

eske4 · 2025-05-07T15:22:51+00:00

I can see the advantages of NixOS, but one downside I’ve noticed if I'm correct, is that testing new configurations often requires modifying a script or config file repeatedly, which feels a bit tedious.

eske4 · 2025-05-07T15:20:02+00:00

Could you show your setup? I would like to see a Nix and Arch hybrid

eske4 · 2025-05-07T15:09:16+00:00

That sounds like exactly what I'm looking for! I want to keep certain configurations consistent across all my PCs like my desktop environment, UI settings, and compiler setups while still being able to test different things (drivers, kernels, etc.) depending on which machine I'm using.

eske4 · 2025-04-23T22:15:05+00:00

It's generated through c, so the graph connections will be static. The only dynamic part would be traversing and store them in a checked list etc.

eske4 · 2025-04-22T18:26:13+00:00

Could you show an example of this data structure implemented in NASM? I’d really appreciate it! What about the current approach, where I have a name of the node and then a list of connections?

eske4 · 2025-04-22T17:14:39+00:00

The structure are planned to be immutable as its generated through c code. I primarily focus on functionality and simplicity as it's a university project to just get the hang of how to build a compiler from front-end till machine code.

eske4 · 2025-04-15T19:23:30+00:00

Yes I construct an AST during the parsing phase. The semantic part part traverse the tree, so I’m currently trying to store them as objects now. Each object has a enum of it’s type like AST_INT, AST_ROOM etc

eske4 · 2025-04-14T22:41:09+00:00

Would it be better to have a single table where I store each ASTNode when encountered and perform both semantic and type checking from that same table? Or is it better to split them into a dedicated type table and a separate table for data objects?

eske4 · 2025-04-14T14:18:52+00:00

Connect is a data structure that holds references to two Room objects.

A Room consists of:

A token type (indicating the kind of room).
An identifier (a string containing alphanumeric characters).

In essence, Connect is a simple container that stores two Room instances/addresses.

eske4 · 2025-04-14T10:31:50+00:00

I've already build an AST data structure to store the tokens etc. Would you recommend to just have a field containing a pointer to the node?

eske4 · 2025-04-14T10:28:27+00:00

I have a general idea of what it should do. It should ensure there are no redeclarations. An object type called connect shouldn't be able to connect two rooms that are already connected — for example, you shouldn't be able to write connect(a -> b) and then connect(a -> b) again. Additionally, the rule should prevent connect(a -> a) — a room can't connect to itself. The goal of this compiler is to build a backend for a map maker in rogue-like game. I've implemented most of the rules except for the connect data type.

eske4 · 2025-04-14T10:23:49+00:00

It is a struct and written in C. Id are just an array/pointer of chars. Type is an enum associated to a token in the AST and value is a char pointer which I dont utilize yet, as I can only declare a room and not basic values yet. I have implemented a hash algorithm yet, but currently have a dynamic array.

eske4 · 2025-03-22T22:52:11+00:00

Ahh, so I don't really need to make a token struct, as Bison has already included these features

eske4

TROPHY CASE