Intel porta USB4STREAM su Linux: backup e streaming via cavo USB4

Una semplice connessione USB4 potrebbe trasformarsi in un canale diretto tra due computer Linux, senza IP, senza socket e senza configurare interfacce di rete. Intel sta lavorando a una novità che punta proprio a questo obiettivo: trasferire dati grezzi tra host collegati tramite cavo Thunderbolt o USB4 usando un device character, ovvero tramite un file che consente la comunicazione a basso livello con l’hardware, accessibile dal filesystem. La funzionalità si chiama USB4STREAM e dovrebbe entrare nel kernel Linux 7.2 attraverso il nuovo driver thunderbolt_stream.

L’idea nasce da una constatazione molto pratica. In numerosi scenari tecnici il networking tradizionale introduce complessità inutile: stack TCP/IP, configurazioni SSH, firewall, DHCP, routing e servizi aggiuntivi che servono solo per spostare dati da una macchina all’altra. Intel prova quindi a sfruttare direttamente USB4/Thunderbolt come canale raw bidirezionale. In pratica il collegamento fisico diventa una sorta di bus dati host-to-host accessibile con le normali primitive read e write.

USB4 e Thunderbolt già consentono tunneling di protocolli come PCI Express e DisplayPort. La differenza, qui, è che Linux espone un’interfaccia estremamente minimale: il nodo /dev/tbstreamX. Qualsiasi software capace di leggere o scrivere su file descriptor può trasferire dati sull’altro host senza modifiche applicative. Intel non introduce un nuovo framework applicativo complesso, ma un meccanismo volutamente essenziale.

Come funziona USB4STREAM nel kernel Linux

Dal punto di vista architetturale, USB4STREAM utilizza tunnel interni verso Thunderbolt/USB4 per trasferire pacchetti tra host: il sistema evita completamente il passaggio nello stack networking del kernel.

Il lavoro porta la firma di Mika Westerberg, storico maintainer del sottosistema Thunderbolt Linux: le patch sono già finite nel branch “next” del repository Thunderbolt e, salvo ritardi nella merge window prevista per metà giugno, dovrebbero approdare nel kernel Linux 7.2.

Non si tratta comunque di una connessione “plug and play” automatica nel senso consumer del termine: prima di utilizzare uno stream bisogna configurarlo tramite ConfigFS, il filesystem virtuale usato dal kernel Linux per l’esposizione e la gestione dinamica di oggetti configurabili.

La configurazione avviene creando directory dentro /sys/kernel/config/thunderbolt/stream/. Ogni stream possiede identificativi chiamati HopID, usati dal fabric Thunderbolt per instradare i dati tra endpoint. Una volta completata la configurazione, il device appare come un file speciale: strumenti classici Unix come dd, cat, tar e gzip funzionano immediatamente senza modifiche.

Per esempio, un backup raw di un’unità NVMe può attraversare direttamente il cavo USB4. Ecco la configurazione sui due host coinvolti nella comunicazione avviata con l’utilità dd per la copia dei file:

• host1: dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k
• host2: dd if=/dev/tbstream0 of=/tmp/backup.img bs=256k

Backup di emergenza e recovery senza rete

Uno degli scenari più concreti riguarda la gestione delle procedure di ripristino Linux: chi gestisce infrastrutture sa bene quanto sia scomodo predisporre funzionalità di networking dentro initramfs minimali. Bisogna includere moduli NIC, utility SSH, configurazioni IP e spesso gestire incompatibilità hardware.

USB4STREAM elimina quasi tutto questo: se due macchine possiedono porte USB4 o Thunderbolt compatibili, basta collegarle con un cavo certificato e creare lo stream. A quel punto il trasferimento funziona direttamente a livello file descriptor.

Intel menziona esplicitamente backup di emergenza eseguiti tramite initramfs, il file system temporaneo caricato all’avvio del sistema operativo prima del caricamento completo del kernel Linux. L’approccio ha diversi vantaggi tecnici: meno superficie d’attacco, meno dipendenze software e latenza ridotta. Inoltre si evita completamente il traffico di rete tradizionale, utile soprattutto in sistemi isolati o durante le attività di risposta agli incidenti (incident response).

USB4 già supporta velocità teoriche fino a 40 Gbps, mentre Thunderbolt 5 arriva a 80 Gbps bidirezionali e fino a 120 Gbps in modalità Bandwidth Boost. In condizioni reali entrano ovviamente in gioco controller, DMA engine, qualità del cavo e implementazione firmware.

Streaming video diretto tra sistemi Linux e condivisione di webcam

Tra gli esempi più curiosi forniti da Intel compare la condivisione di webcam tra computer differenti. Un laptop può acquisire video tramite V4L2 e inviarlo in tempo reale a un desktop attraverso /dev/tbstream0.

Prendiamo in esame questa dimostrazione pratica basata su GStreamer:

• host1: gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080 ! jpegenc quality=90 ! filesink location=/dev/tbstream0
• host2: gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! autovideosink

USB4STREAM non impone un protocollo applicativo specifico: il driver trasporta byte grezzi; codifica, framing e sincronizzazione restano responsabilità dello spazio utente.

Da una parte è un vantaggio enorme perché lascia massima libertà agli sviluppatori. Dall’altra richiede attenzione: non esistono meccanismi integrati di affidabilità, ritrasmissione o controllo di congestione come accade con TCP. Per flussi video o trasferimenti bulk il modello funziona bene. In applicazioni più sensibili alla perdita di dati serviranno livelli applicativi aggiuntivi.

Perché USB4STREAM potrebbe interessare davvero gli amministratori Linux

Un’innovazione di primo piano come USB4STREAM intercetta esigenze concrete: recovery rapide, imaging di sistemi, trasferimenti offline, acquisizione video diretta e comunicazioni host-to-host senza dipendenze di rete.

Come abbiamo visto in precedenza, un amministratore Linux può usare strumenti Unix standard senza apprendere API proprietarie o framework dedicati: il cavo USB4 diventa un collegamento dati trasparente integrato nel ben noto modello Unix/Linux “everything is a file“.

Se il supporto entrerà davvero in Linux 7.2, è probabile che nei mesi successivi compaiano utilità più evolute, wrapper automatici e integrazioni con ambienti di disaster recovery. Si potrebbero persino realizzare sistemi RPC (Remote Procedure Call, cioè chiamate remote tra processi) o filesystem distribuiti utilizzando /dev/tbstreamX come canale di comunicazione dati.

La sensazione è che Intel abbia scelto volutamente una strada minimale: fornire un trasporto raw affidabile e lasciare alla comunità Linux il compito di costruire il resto.