Archiviazione di massa USB sul livello di file

StackOverflow https://stackoverflow.com/questions/6022715

Domanda

La sfida : ho un dispositivo a mano Linux, che registra i dati e lo memorizza sul disco. Dovrebbe scambiare questi dati con un'applicazione Windows tramite USB. Quando questi dati sono accessibili dall'utente - ad.g. tramite USB-Mass-Storage - Deve essere crittografato. Dovrebbe funzionare fuori-the box, con una varietà di sistema operativi, anche per le sessioni terminali Citrix, ecc.

Il piano : creo un file-system nello spazio utente con fusibile e offrirlo a Windows tramite memoria di massa. Ogni volta che Windows accede a un file, ottengo un callback e crittografa i dati al volo. Inoltre, possiamo avere un contenuto dinamico - E.G. Quando una password viene scritta in un file, viene visualizzato più contenuti.

Il problema : quando si utilizza il gadget di memoria di massa (ad es. g_file_storage ) Accetta solo file o Dispositivi a blocchi - ma nessun file-systems (directory). Perché?

.

[...] Fornisce un'interfaccia semplice per leggere e scrivere settori di dati, molto simile all'interfaccia di basso livello utilizzata per accedere a qualsiasi disco rigido [...]. I sistemi operativi possono trattare l'unità USB come un disco rigido e può formattarlo con qualsiasi file system che desiderano. (da wikipedia )

Quindi non c'è possibilità di avere un file system dinamico tramite memoria di massa ... e questo sembra essere il motivo, perché il mio telefono cellulare Android non monta tutti i dati sul telefono, quando lo collego a PC.

Opzioni :

    .
  • Crea un ' Dispositivo di blocco in Userspace ' - simile al fusibile (Hai bisogno di un driver inverso-grasso, Quando voglio offrire i file dinamicamente)
  • Implementa il mio server NBD per creare un dispositivo di blocco (è necessario anche un driver di grasso inverso?)
  • Salva i file crittografati in una partizione e passano questa partizione al gadget di memoria di massa (il problema sarebbe la performance e la mancanza di interazione dinamica)
  • Non offrire un dispositivo di stomaggio di massa e attenzione per altre idee (ETH Over USB)

    Al momento, solo l'ultima opzione sembra essere realistica - o hai un altro consiglio per me?

    Sarei grato!

    Charly

È stato utile?

Soluzione

Il protocollo di archiviazione di massa USB è un protocollo del dispositivo a blocchi; Non funziona a livello di file o directory. L'host di Windows prevede di visualizzare un filesystem VFAT grezzo esposto dal driver G_Mass_STORAGE e renderà scrive e si legge ai metadati VFAT come appropriato per capire come sono strutturate le directory.

A causa di ciò, è non convincente esporre un filesystem di fusibili per l'host di Windows. Dovresti emulare VFAT, assegnando blocchi nel filesystem virtuale ai metadati e ai dati, e poiché l'host di Windows è libero di cache qualsiasi dati o metadati che legge, una volta assegnato alcuni metadati o dati non possono modificare (quindi le modifiche a I dati del fusibile non possono essere riflessi nel filesystem di Windows). L'host di Windows può anche ritardare e riordino scrive su entrambi i metadati e i dati - è tutto il vero casino se si tenta di emulare.

Ora, ci sono alcune cose che puoi fare:

    .
  1. È possibile scrivere un driver personalizzato IFS sul lato Windows per interagire con il dispositivo Linux su un protocollo personalizzato che funziona a livello file / directory.
  2. È possibile trattare il dispositivo USB come porta Ethernet virtuale e parlare CIFS all'host Windows
  3. Puoi in qualche modo creare un layout VFAT statico sul tempo di connessione per esporre all'host Windows; I dati non ancora decifrabili possono restituire gli errori I / O per evitare i dati crittografati crudi della memorizzazione nella cache dell'host Windows.
  4. Puoi solo crittografare un dispositivo di blocco grezzo utilizzando DM-Crypt e esporre questo intero dispositivo di blocco (crittografato come un pezzo) a Windows.
  5. È possibile implementare un mtp gadget.

    Questi approcci sono dotati dei propri problemi:

      .
    1. Richiede un driver di Windows da installare e da firmare da Microsoft ecc. Non è possibile utilizzare su una macchina senza accesso amministrativo per installare il driver.
    2. non avvia l'autoplay; L'utente dovrebbe sfogliare il browser di rete per accedere ai file. Le impostazioni del firewall possono interferire. Potrebbe avere un sovraccarico significativo.
    3. molto complesso. La gestione degli aggiornamenti dei metadati sul backend potrebbe essere estremamente difficile. Gli eventi sorprendenti scollegati possono essere devastanti. Il comportamento di Windows sulla ricezione di un errore IO potrebbe essere un problema se l'utente tenta di accedere a un file bloccato.
    4. Non è disponibile alcuna crittografia a livello di file, ma altrimenti dovrebbe funzionare bene.
    5. Non sono sicuro esattamente quanto il supporto per i file non multimediali ha MTP; Il supporto non è così diffuso come supporto di memoria di massa.

Altri suggerimenti

Potrebbe interessarti sapere che Android, che in precedenza si è esposto come dispositivo di archiviazione di massa USB all'host, è invece in funzione come un dispositivo MTP (come a nido d'ape).

Detto questo, qualcuno ha già implementato la tua opzione 1, anche se con il "dispositivo" e "host" un po 'invertito. qemu ha un hack folle chiamato vvfat che è in grado di creare un dispositivo di blocco falso che alla VM sembra come contiene un filesytem VFAT solo da una directory / filealbero sull'host.Richiede una scansione ricuperabile completa prima di iniziare, dipende dai dettagli di come scrivere i sistemi di filesystem e cade se modifichi in modo indipendente i file mentre è in uso, ma (in qualche modo) riesce (a volte) il lavoro.

Potrebbe essere possibile tradurre il protocollo NBD su USB e USB "Bit-Bang" per apparire all'host USB come dispositivo di archiviazione di massa USB.

    .
  • NBD e USB MSAS Storage sono entrambi dispositivi a livello di blocco, quindi potrebbe essere possibile tradurre un protocollo sull'altro. Tuttavia, ciò richiederebbe quasi certamente la programmazione, come non penso che questo esista. Tuttavia, http://travisgoodspeed.blogspot.com/2012 /07/emulating-usb-devices-with-python.html sembra abbastanza utile per il lato USB e https://itbucket.org/hirofuchi/xnbd/wiki/home dovrebbe darti un buon esempio per il lato client NBD.
  • Usando VFAT significa che Windows può vederlo come un'unità disco USB normale, senza driver.
      .
    • Come suggerisce un altro poster, il modulo VVFAT di Qemu potrebbe essere utilizzato per automatizzare un po 'di questo.
    • La crittografia del traffico richiederebbe il tunneling del traffico NBD tramite SSH o OpenVPN.

      La configurazione finale assisterà qualcosa del genere: 

      +---------------------------------+                +------------------+
| data collection device          |                | client device    |
| +----------------+              |                |                  |
| | collected data |              |                |  SSH -> NBD      |
| | -> linux fs    |              |                |         client   |
| +--+-------------+--------+     |                |         |        |
| -> | qemu vvfat           | SSH +-{some network}-+         V        |--> client PC
|    | run NBD inside the VM|     |                | USB Mass Storage |    USB port 
+----+----------------------+-----+                +------------------+
      .

Guardando le opzioni, prenderei in considerazione l'utilizzo di Ethernet-Gadget e di eseguire l'autoconfigurazione IP nel dispositivo, quindi eseguire Samba per esportare il filesystem sull'host Windows.Questo ti darebbe il livello di controllo che ti serve.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top