TSI: bind(port 0) + listen() lands the VMM proxy on a different ephemeral port than the guest — ephemeral listeners unreachable

Abierto
  • ¿Algo no está bien?
#818 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
c, python, rust
Área
networking, operating-systems

Línea de trabajo

Start with net/tsi/af_tsi.c:tsi_listen(), src/devices/src/virtio/vsock/tsi_stream.rs:try_listen(), and TsiListenRsp in src/devices/src/virtio/vsock/packet.rs. Trace how port 0 is passed and how the VMM's bound address is represented, then run the supplied Python repro and fixed-port control. Done means guest and VMM use the same ephemeral port and the listener accepts connections through the guest-reported address.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Environment

  • libkrun 1.19.4 (Arch package libkrun 1.19.4-1), libkrunfw 5.5.0-1,
    crun-based krun 1.29.1-1
  • Host: Arch Linux x86_64, kernel 6.12.91, KVM; rootless podman 5.x with pasta
  • Guest: python:3.12-slim (bookworm, glibc 2.36)
  • Networking: default — no NIC, so implicit TSI with TsiFlags::HIJACK_INET
    (tsi_hijack on the guest kernel command line)
  • Verified still present in current main (2.0 dev):
    TsiListenRsp { result: i32 } in src/devices/src/virtio/vsock/packet.rs
    is identical there — no address is communicated back in either version.

Summary

bind(port 0) followed by listen() under TSI leaves the listener
unreachable at its own port, including for the process that created it:

  1. Guest app calls bind(127.0.0.1:0); the guest kernel assigns port X.
  2. listen() sends TSI_LISTEN to the VMM with the recorded request
    address (port 0) — net/tsi/af_tsi.c:tsi_listen() sends tsk->bound_addr,
    which still contains port 0.
  3. The VMM (src/devices/src/virtio/vsock/tsi_stream.rs:try_listen()) binds
    that address in the VMM process's own netns, where bind(0) gets a
    different port Y from that netns's ephemeral allocator.
  4. TsiListenRsp returns only a result code — Y is never communicated
    back    , so the guest keeps reporting X in getsockname().

Result: connect(127.0.0.1:X) gets ECONNREFUSED. The listener is alive at
port Y, unreachable and unknown.

Minimal repro (bare krun container; tested 3/3)

cat > t.py <<'EOF'
import socket, time
s = socket.socket(); s.bind(('127.0.0.1', 0))
port = s.getsockname()[1]; s.listen(1)
print('bound:', port)
time.sleep(0.5)
c = socket.socket(); c.settimeout(5)
c.connect(('127.0.0.1', port))   # -> ConnectionRefusedError
EOF

podman run --rm --runtime=krun \
    --annotation krun.ram_mib=1024 --annotation krun.cpus=2 \
    --mount type=bind,src=$PWD/t.py,target=/t.py \
    python:3.12-slim python3 /t.py

Output:

bound: 43859
ConnectionRefusedError: [Errno 111] Connection refused

Control: the same script with a fixed port
(bind(('127.0.0.1', 45677)), connect to 45677) succeeds — fixed-port binds
do not diverge, which confirms the mechanism.

Direct proof of the divergence

Run the same ephemeral listener inside a --network host krun container and
inspect the host side while the guest sleeps on accept():

guest: bound 127.0.0.1:53603 (X)
host:  ss -ltn  →  LISTEN 127.0.0.1:45551 (Y — assigned by the VMM's netns)
connect to X → refused; connect to Y → accepted, guest accept() fires

Real-world impact

debugpy (python -m debugpy --listen 0.0.0.0:5678 …) always creates a
127.0.0.1:0 endpoints listener whose adapter child connects back, so every
debugpy session dies after 30 s with
RuntimeError: timed out waiting for adapter to connect. Reproduced in a
bare krun container with debugpy alone. Anything else using ephemeral
listeners is similarly affected.

Suggested fix directions

Return the actually-bound address/port in TsiListenRsp and have the guest
update the socket's local address; or have the guest request a concrete port
for the shadow bind (it already knows X). We currently carry a userspace
workaround (LD_PRELOAD rewriting port-0 binds to concrete ports) and are
happy to contribute a VMM/kernel fix if this direction sounds right.

Related: #819 — same investigation, TSI locking bug

Lenguaje dominante
Rust
Estrellas
2.8k
Forks
279
Merge medio
5 d 18 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de libkrun/libkrun

Todos los issues de libkrun/libkrun

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.