| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the UDP and Ethernet shim IPCPs. The unicast and broadcast
IPCPs can now directly attach to a "legacy" socket. We adopt Saltzer's
Point-of-Attachment terminology, also advocated in Day's "Patterns in
Network Architecture". The "poa" component manages these
PoA's with one management thread, one link monitoring thread and one
thread per attached point.
For Ethernet PoA's the irm connect and enroll can resolve the
destination IPCP or Layer name with a broadcast name query over the
attached PoAs (first reply wins). UDP PoA's require a destination IP
address or FQDN.
attach to a local endpoint (required both server and client side):
irm ipcp poa attach name a udp 10.0.0.1
irm ipcp poa attach name a udp 10.0.0.1:3435
irm ipcp poa attach name a udp [::1]:3435
irm ipcp poa attach name a eth dev eth0
irm ipcp poa attach name a eth dev eth0 ethertype 0xA000
release a PoA (refused while it carries a flow):
irm ipcp poa detach name a udp 10.0.0.1:3435
irm ipcp poa detach name a eth eth0
list an IPCP's PoAs:
irm ipcp poa list name a
connect to a peer, by name or at an address:
irm ipcp connect name b dst a
irm ipcp connect name b dst a eth
irm ipcp connect name b dst a eth dev eth0
irm ipcp connect name b dst a udp 10.0.0.1:3435
irm ipcp connect name b dst a udp peer.example.com:3435
disconnect by peer name, no address:
irm ipcp disconnect name b dst a
irm ipcp disconnect name b dst a component mgmt
enroll has the same shape as connect:
irm ipcp enroll name b layer lr autobind
irm ipcp enroll name b layer lr autobind eth dev eth0
irm ipcp enroll name b layer lr autobind udp 10.0.0.1:3435
the IRMd config file attaches PoAs and names peers the same way:
udp = [ "10.0.0.1", "10.0.0.1:3436" ]
eth = [ "eth0", {dev="eth1", ethertype=0xA007} ]
enrol={dst="LAN", eth={dev="eth0"}}
conn=[{dst="lan3", eth={}}, {dst="lan4", udp="10.0.0.1:3435"}]
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend re-key delivery beyond the locally-initiated watermark path:
Handle peer-initiated re-key requests, allowing one request and one
response per flow at a time. The client side wins if both ends try to
re-key at the same time. Caches the peer certificate to support
cert-less authenticated/signed re-keys.
After a rekey, the initiator promotes first (timer) and starts sending
under the new key. The responder observes the new key (peer_synced)
and then the responder promotes. The responder will self-decide to use
the new keys if it exhausted the older set in the case where it never
sees the peer (unidirectional flow).
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-key each encrypted flow's batch root periodically so a long-lived
flow never exhausts or over-uses a single root. The IRMd re-runs the
OAP exchange with the peer IRMd over the flow-update relay. The
per-flow re-keying state is tracked in the registry (reg_flow).
A re-key delivers one root seed from the OAP exchange. keyrot
immediately HKDF-expands it into 128 node keys (KR_NODES_SZ = 128 × 32
B) and wipes the root. Then each of the 128 node keys is itself a root
→ HKDF-expanded into 64 (2^KEY_NODE_BITS) leaf keys, forked per
direction; each leaf key is the actual AEAD key, good for 2^20 packets
(the low counter bits are its nonce/seq). If the number of keys runs
low, a re-key will be triggered (KEY_REKEY_WATERMARK).
The rekey is signalled out of band to the application. The rbuff ACL
is generalized into a flags word, so an RB_REKEY bit rides alongside
the access RB_RD/RB_WR and FLOWDOWN/FLOWPEER bits. The RD and WR bits
are revised ditching the fcntl historical weirdness. The seed is
pulled via flow_read/flow_write, installed with crypt_rekey(). TX
holds the old epoch until the peer is observed on the new one (or a
grace deadline elapses), promoted from both the read and write paths
so a recv-mostly flow still advances.
Also fix the FLOW_ACCEPT and FLOW_ALLOC handlers, which on a key-buffer
allocation failure returned from inside the cleanup-push region: that
leaked the reply message and skipped both the stack-key scrub and the
cleanup pop.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows bypassing the IPCP for local processes that share the same
packet pool, lowering latency between processes to comparable levels
as Unix sockets (RTT in the order of a microsecond).
For local processes, no IPCPs are needed:
$ irm b prog oping n oping
$ oping -l
Ouroboros ping server started.
New flow 64.
Received 64 bytes on fd 64.
The direct IPC can be disabled with the DISABLE_DIRECT_IPC build
flag. Note that this is needed for rumba 'local' experiments to
emulate network topologies. Without this flag all processes will just
communicate directly.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
| |
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the flow encryption option (cypher_s) from the qosspec.
The configuration file is configured in the security options (default
/etc/ouroboros/security/). For this poc, encryption can be disabled
client or server side by putting an enc.cfg file. If that file is
present in the client folder, the client will require encryption. If
that file is present on the server side, the server will require
encryption and reject non-encrypted flows.
Encryption is now configured outside of any application control.
Example: /etc/ouroboros/security/client/oping/enc.cfg exists:
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd(DB): Generated ephemeral keys for 87474.
irmd/oap(PP): OAP_HDR [caf203681d997941 @ 2025-09-02 17:08:05 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: [91 bytes]
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/client/oping/enc.cfg does not exist:
irmd(II): Allocating flow for 87506 to oping.
irmd(DB): File /etc/ouroboros/security/client/oping/enc.cfg does not exist.
irmd(DB): File /etc/ouroboros/security/client/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [e84bb9d7c3d9c002 @ 2025-09-02 17:08:30 (UTC) ] -->
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
Example: /etc/ouroboros/security/server/oping/enc.cfg exists:
irmd(II): Flow request arrived for oping.
irmd(DB): IPCP 88112 accepting flow 7 for oping.
irmd(II): Encryption enabled for oping.
irmd(DB): File /etc/ouroboros/security/server/oping/crt.pem does not exist.
irmd(II): No security info for oping.
irmd/oap(PP): OAP_HDR [3c717b3f31dff8df @ 2025-09-02 17:13:06 (UTC) ] <--
irmd/oap(PP): Certificate: <none>
irmd/oap(PP): Ephemeral Public Key: <none>
irmd/oap(PP): Data: <none>
irmd/oap(PP): Signature: <none>
irmd(WW): Encryption required but no key provided.
The server side will pass the ECRYPT to the client:
$ oping -l
Ouroboros ping server started.
Failed to accept flow: -1008
$ oping -n oping -c 1
Failed to allocate flow: -1008.
Encryption on flows can now be changed at runtime without needing to
touch/reconfigure/restart the process.
Note: The ECRYPT result is passed on via the flow allocator responses
through the IPCP (discovered/fixed some endianness issues), but the
reason for rejecting the flow can be considered N+1 information... We
may move that information up into the OAP header at some point.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds initial implementation of peer authentication as part of
flow allocation. If credentials are not provided, this will be
accepted and logged as info that the flow is not authenticated.
Certificates and keys are passed as .pem files. The key file should
not be encrypted, else the IRMd will open a prompt for the password.
The default location for these .pem files is in
/etc/ouroboros/security. It is strongly recommended to make this
directory only accessible to root.
├── security
│ ├── cacert
│ │ └── ca.root.o7s.crt.pem
│ ├── client
│ │ ├── <name>
│ │ | ├── crt.pem
│ │ | └── key.pem
│ │ └── <name>
| | ├──...
| |
│ ├── server
│ │ ├── <name>
│ │ | ├── crt.pem
│ │ | └── key.pem
│ │ └── <name>
| | ├── ...
| |
│ └── untrusted
│ └── sign.root.o7s.crt.pem
Trusted root CA certificates go in the /cacert directory, untrusted
certificates for signature verification go in the /untrusted
directory. The IRMd will load these certificates at boot. The IRMd
will look for certificates in the /client and /server directories. For
each name a subdirectory can be added and the credentials in that
directory are used to sign the OAP header for flows at flow_alloc() on
the client side and flow_accept() on the server side.
These defaults can be changed at build time using the following
variables (in alphabetical order):
OUROBOROS_CA_CRT_DIR /etc/ouroboros/security/cacert
OUROBOROS_CLI_CRT_DIR /etc/ouroboros/security/client
OUROBOROS_SECURITY_DIR /etc/ouroboros/security
OUROBOROS_SRV_CRT_DIR /etc/ouroboros/security/server
OUROBOROS_UNTRUSTED_DIR /etc/ouroboros/security/untrusted
The directories for the names can also be configured at IRMd boot
using the configuraton file and at runtime when a name is created
using the "irm name create" CLI tool. The user needs to have
permissions to access the keyfile and certificate when specifying the
paths with the "irm name create" CLI tool.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
| |
This makes the IRMd a bit simpler, and we only need to do the lookup
to resolve the name for a hash on the server side only once. The
logging is also symmetric now:
irmd(II): Allocating flow for 93317 to unicast.1.
irmd(II): Flow request arrived for unicast.1.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a full revision of the IRMd internal implementation.
The registry is now a proper subcomponent managing its own internal
lock (a single mutex). Some tests are added for the registry and its
data structures. Some macros for tests are added in <ouroboros/test.h>.
Flow allocation is now more symmetric between the client side (alloc)
and server size (accept). Each will create a flow in pending state
(ALLOC_PENDING/ACCEPT_PENDING) that is potentially fulfilled by an
IPCP using respond_alloc and respond_accept primitives. Deallocation
is split in flow_dealloc (application side) and ipcp_flow_dealloc
(IPCP side) to get the flow in DEALLOC_PENDING and DEALLOCATED state.
Cleanup of failed flow allocation is now properly handled instead of
relying on the sanitizer thread. The new sanitizer only needs to
monitor crashed processes.
On shutdown, the IRMd will now detect hanging processes and SIGKILL
them and clean up their fuse mountpoints if needed.
A lot of other things have been cleaned up and shuffled around a bit.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
|
| |
Some definitions/enums were different between the library and IRMd
(flow_state, ipcp_state). This moves them to common ground.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
| |
|
|
|
|
|
| |
Slow but steady.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
|
|
Rename internal data structures so it's clear that they are the IRMd
representation of these objects for management purposes.
Split functionality for these objects off and and move them to their
own source files.
Rename internal functions of the IRMd to reflect this, with some small
refactoring.
Signed-off-by: Dimitri Staessens <dimitri@ouroboros.rocks>
Signed-off-by: Sander Vrijders <sander@ouroboros.rocks>
|
