Description
While looking through the vAccel implementation, I noticed a collision issue in pkg/unikontainers/vaccel.go. The idToGuestCID function maps the 64-char container ID to a vsock Guest CID by summing the character values and doing a modulo 97:
val := (sum % 97) + 3
Because this limits the CID space to only 97 possible values, we hit the Birthday Paradox pretty hard. With just 12 running vAccel containers, there's a 50% chance of a CID collision. At 20-30 containers, a collision is almost guaranteed.
If two containers get assigned the same vsock CID, their vAccel RPC communication will interfere with each other and break.
Steps to reproduce
You can verify this statically without even running a container. If you generate a few standard 64-character container IDs and pass them through idToGuestCID(), you'll get collisions very quickly.
For example, both of these container IDs result in Guest CID 59:
7c0a766c0569f883ea6d29b59f73e62e13845e18c39278e1e9ba7b710931425560542bd0f913ed3a3a893132dc9726d8a58bcb0035dad42b9c241807fc73ce46
Proposed Fix
We should replace the ASCII sum with a proper hash function (like hash/fnv). Using a 32-bit FNV-1a hash would expand the CID space to over 2 billion, which completely eliminates the collision risk for standard node deployments.
Description
While looking through the vAccel implementation, I noticed a collision issue in
pkg/unikontainers/vaccel.go. TheidToGuestCIDfunction maps the 64-char container ID to a vsock Guest CID by summing the character values and doing a modulo 97:val := (sum % 97) + 3Because this limits the CID space to only 97 possible values, we hit the Birthday Paradox pretty hard. With just 12 running vAccel containers, there's a 50% chance of a CID collision. At 20-30 containers, a collision is almost guaranteed.
If two containers get assigned the same vsock CID, their vAccel RPC communication will interfere with each other and break.
Steps to reproduce
You can verify this statically without even running a container. If you generate a few standard 64-character container IDs and pass them through
idToGuestCID(), you'll get collisions very quickly.For example, both of these container IDs result in Guest CID
59:7c0a766c0569f883ea6d29b59f73e62e13845e18c39278e1e9ba7b710931425560542bd0f913ed3a3a893132dc9726d8a58bcb0035dad42b9c241807fc73ce46Proposed Fix
We should replace the ASCII sum with a proper hash function (like
hash/fnv). Using a 32-bit FNV-1a hash would expand the CID space to over 2 billion, which completely eliminates the collision risk for standard node deployments.