`idToGuestCID` generates frequent vsock CID collisions due to limited output space

オープン
  • 何か問題がありますか？
#688 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

  • #895 @Cicada1107 による — マージされずにクローズ

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
54/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
backend, networking

調査の方向性

pkg/unikontainers/vaccel.go の idToGuestCID から始め、pkg/unikontainers/unikontainers.go の Exec から qemu.go、firecracker.go、cloud_hypervisor.go へとその使用箇所を追跡します。現在の vhost-vsock CID の制約を確認し、選択したハッシュ化またはリトライの挙動をどのように検証すべきかを特定します。完了条件は、報告されたアナグラムのケースに対するカバレッジを含め、予測可能な CID 衝突によって並行コンテナが失敗しなくなることです。

索引モデルが issue の本文から書いたものです。

説明

HW accel Monitors Stale

Description

The idToGuestCID function in pkg/unikontainers/vaccel.go generates vhost-vsock Context Identifiers (CIDs) by summing the ASCII values of a container ID and applying mod 97. This restricts the entire output space to just 97 possible CIDs (range [3, 99]).

Since standard container IDs (e.g., from containerd) are 64-character hex strings, this constrained output space leads to frequent collisions. In a multi-container vAccel deployment, the probability of a CID collision exceeds 50% with just 13 concurrent containers.

When a collision occurs, the hypervisor passes the duplicate guest-cid to the kernel, which rejects the binding with EADDRINUSE. Because urunc does not currently implement collision detection or retry logic during the Exec phase, the container initialization fails.

Furthermore, because the hashing mechanism relies on a simple character sum, container IDs that are anagrams of each other (which is common with hex-encoded strings) will deterministically collide.

Root Cause

  • pkg/unikontainers/vaccel.go does the (sum % 97) + 3 math.
  • pkg/unikontainers/unikontainers.go calls it during container Exec().
  • The hypervisors (qemu.go, firecracker.go, cloud_hypervisor.go) then pass this blindly to the kernel.

Reproducer for Anagram Collisions

def id_to_guest_cid(id_str):
    return (sum(ord(c) for c in id_str) % 97) + 3

id1 = "abcdef0123456789" * 4
id2 = "9876543210fedcba" * 4

# Both IDs share the same character distribution
assert id_to_guest_cid(id1) == id_to_guest_cid(id2) # Evaluates to 29

Proposed Solution

Replace the character sum with a non-cryptographic hash (e.g., hash/fnv) over the container ID, and map it to the full available vhost-vsock CID range ([3, 1<<32 - 1]).

Alternatively, if CIDs must be strictly deterministic and collision-free across arbitrary host states, implement a probe-and-retry mechanism to verify CID availability before executing the VMM.

主要言語
Go
スター
308
フォーク
222
平均マージ
2日 12時間
マージ済み PR（30日）
42

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

urunc-dev/urunc のほかの issue

urunc-dev/urunc の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。