ouroboros/src/ipcpd/local/main.c, branch 0.24.0

ipcpd: Add flow-update relay

2026-06-29T06:32:58+00:00

This adds an ipcp_flow_update() call to relay opaque messages between the two IRMds (carried by FLOW_IRM_UPDATE messages), which passes it back up to the peer IRMd via ipcp_flow_update_arr(). The broadcast layer does not implement this. Needed for periodic re-keying of encrypted flows via OAP. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Pass MTU from IPCP to process for FRCT

2026-05-20T06:17:06+00:00

FRCT needs to know the MTU for fragmentation. The MTU is now passed from the layer serving the flow to the process as part of flow allocation. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Fix rejected flow allocation on local

2026-03-14T10:23:32+00:00

When the server rejects the flow, the local didn't send the flow_alloc response back to the IRMd, causing the irmd and client to time out instead of being notified of the failed allocation immediately. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Update copyright to 2026

2026-02-18T06:54:56+00:00

Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Add per-user packet pools

2026-02-13T08:22:28+00:00

The IRMd will now check the user UID and GID for privileged access, avoiding unprivileged users being able to disrupt all IPC (e.g. by shm_open the single pool and corrupting its metadata). Non-privileged users are now limited to a PUP (per-user pool) for sending/receiving packets. It is still created by the IRMd, but owned by the user (uid) with 600 permissions. It does not add additional copies for local IPC between their own processes (i.e. over the local IPCP), but packets between processes owned by a different user or destined over the network (other IPCPs) will incur a copy when crossing the PUP / PUP or the PUP / GSPP boundary. Privileged users and users in the ouroboros group still have direct access to the GSPP (globally shared private pool) for packet transfer that will avoid additional copies when processing packets between processes owned by different users and to the network. This aligns the security model with UNIX trust domains defined by UID and GID by leveraging file permission on the pools in shared memory. ┌─────────────────────────────────────────────────────────────┐ │ Source Pool │ Dest Pool │ Operation │ Copies │ ├─────────────────────────────────────────────────────────────┤ │ GSPP │ GSPP │ Zero-copy │ 0 │ │ PUP.uid │ PUP.uid │ Zero-copy │ 0 │ │ PUP.uid1 │ PUP.uid2 │ memcpy() │ 1 │ │ PUP.uid │ GSPP │ memcpy() │ 1 │ │ GSPP │ PUP.uid │ memcpy() │ 1 │ └─────────────────────────────────────────────────────────────┘ This also renames the struct ai ("application instance") in dev.c to struct proc (process). Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Replace rdrbuff with a proper slab allocator

2026-01-26T06:50:33+00:00

This is a first step towards the Secure Shared Memory (SSM) infrastructure for Ouroboros, which will allow proper resource separation for non-privileged processes. This replaces the rdrbuff (random-deletion ring buffer) PoC allocator with a sharded slab allocator for the packet buffer pool to avoid the head-of-line blocking behaviour of the rdrb and reduce lock contention in multi-process scenarios. Each size class contains multiple independent shards, allowing parallel allocations without blocking. - Configurable shard count per size class (default: 4, set via SSM_POOL_SHARDS in CMake). The configured number of blocks are spread over the number of shards. As an example: SSM_POOL_512_BLOCKS = 768 blocks total These 768 blocks are shared among 4 shards (not 768 × 4 = 3072 blocks) - Lazy block distribution: all blocks initially reside in shard 0 and naturally migrate to process-local shards upon first allocation and subsequent free operations - Fallback with work stealing: processes attempt allocation from their local shard (pid % SSM_POOL_SHARDS) first, then steal from other shards if local is exhausted, eliminating fragmentation while maintaining low contention - Round-robin condvar signaling: blocking allocations cycle through all shard condition variables to ensure fairness - Blocks freed to allocator's shard: uses allocator_pid to determine target shard, enabling natural load balancing as process allocation patterns stabilize over time Maintains existing robust mutex semantics including EOWNERDEAD handling for dead process recovery. Internal structures exposed in ssm.h for testing purposes. Adds some tests (pool_test, pool_sharding_test.c. etc) verifying lazy distribution, migration, fallback stealing, and multiprocess behavior. Updates the ring buffer (rbuff) to use relaxed/acquire/release ordering on atomic indices. The ring buffer requires the (robust) mutex to ensure cross-structure synchronization between pool buffer writes and ring buffer index publication. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Update DHT for unicast layer

2025-08-06T10:34:15+00:00

This is a rewrite of the DHT for name-to-address resolution in the unicast layer. It is now integrated as a proper directory policy. The dir_wait_running function is removed, instead the a DHT peer is passed on during IPCP enrolment. Each DHT request/response gets a random 64-bit ID ('cookie'). DHT messages to the same peer are deduped, except in the case when the DHT is low on contacts. In that case, it will contact the per it received at enrolment for more contacts. To combat packet loss, these messages are not deduped by means of a 'magic cookie', chosen at random when the DHT starts. The DHT parameters (Kademlia) can be set using the configfile or the IRM command line tools: if DIRECTORY_POLICY == DHT [dht_alpha (default: 3)] [dht_k (default: 8)] [dht_t_expire (default: 86400)] [dht_t_refresh (default: 900)] [dht_t_replicate (default: 900)] This commit also adds support for a protocol debug level (PP). Protocol debugging for the DHT can be enabled using the DEBUG_PROTO_DHT build flag. The DHT has the following message types: DHT_STORE, sent to k peers. Not acknowledged. DHT_STORE --> [2861814146dbf9b5|ed:d9:e2:c4]. key: bcc236ab6ec69e65 [32 bytes] val: 00000000c4e2d9ed [8 bytes] exp: 2025-08-03 17:29:44 (UTC). DHT_FIND_NODE_REQ, sent to 'alpha' peers, with a corresponding response. This is used to update the peer routing table to iteratively look for the nodes with IDs closest to the requested key. DHT_FIND_NODE_REQ --> [a62f92abffb451c4|ed:d9:e2:c4]. cookie: 2d4b7acef8308210 key: a62f92abffb451c4 [32 bytes] DHT_FIND_NODE_RSP <-- [2861814146dbf9b5|ed:d9:e2:c4]. cookie: 2d4b7acef8308210 key: a62f92abffb451c4 [32 bytes] contacts: [1] [a62f92abffb451c4|9f:0d:c1:fb] DHT_FIND_VALUE_REQ, sent to 'k' peers, with a corresponding response. Used to find a value for a key. Will also send its closest known peers in the response. DHT_FIND_VALUE_REQ --> [2861814146dbf9b5|ed:d9:e2:c4]. cookie: 80a1adcb09a2ff0a key: 42dee3b0415b4f69 [32 bytes] DHT_FIND_VALUE_RSP <-- [2861814146dbf9b5|ed:d9:e2:c4]. cookie: 80a1adcb09a2ff0a key: 42dee3b0415b4f69 [32 bytes] values: [1] 00000000c4e2d9ed [8 bytes] contacts: [1] [a62f92abffb451c4|9f:0d:c1:fb] Also removes ubuntu 20 from appveyor config as it is not supported anymore. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Refactor ipcp main struct

2025-07-23T13:07:59+00:00

The ipcpi (IPCP instance) is now cleanly tucked away within its source file instead of exposed all over the place. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Mitigate race in wait_req_arr and wait_resp

2024-02-26T07:59:15+00:00

The wait_flow_req_arr and wait_flow_resp functions are there to ensure the responses of the IRMd to flow allocation requests arrive in the correct order. These functions use a mutex: alloc_lock. After these functions return, the IPCP will switch to it's own (usually read-write) lock. In the local IPCP, this leaves room for a race where the state of the flow is accessed in alloc_resp before it is updated in wait_flow_req_arr. This race is only visible in the local IPCP, as the other IPCP have to send information between these calls, but it is theoretically possible when using any IPCP for local IPC. In the ipcpd-local, it happens ~0.01% to ~0.03% of flow allocations. This mitigates the problem in the ipcpd-local by adding a 1ms wait to the flow allocation if this race is detected. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

irmd: Fix flow deallocation timeout

2024-02-26T07:59:15+00:00

The timeout was set to a value calculated as abstime for a cond_wait instead of a timeout, causing flows to linger in the IPCP. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders