Les systèmes de fichiers sur USB

De plus en plus populaires, des périphériques de stockage USB utilisant de la mémoire Flash font leur apparition. Habituellement connus sous la désignation de DiskOnKey, qui est en fait une marque déposée par la société M-System, ces périphériques permettent un stockage d'informations d'une capacité de 8, 16, 32, 64 et bientôt 128 Mo sur un objet de la taille d'un porte-clefs.

Le DiskOnKey offre un gros avantage par rapport à d'autres systèmes de stockage utilisant de la mémoire Flash : il se connecte directement et sans adaptateur sur le port USB de n'importe quelle machine. Il est ainsi possible pour quelques 75 euros (environ 500 FF) de disposer d'un espace de stockage de 32 Mo, robuste, fiable et très peu encombrant. Cet avantage ergonomique se paie très cher si l'on compare le prix de ce type de périphérique avec des systèmes Compact Flash nécessitant l'utilisation d'un périphérique de lecture spécifique (un Compact Flash de 64 Mo coûtant un peu plus de 57 euros, soit environ 375 FF).

Quant aux applications, il s'agit véritablement d'un périphérique de stockage en mode bloc capable d'accueillir un système de fichiers. On pense alors tout naturellement au transport de données sensibles (fichier de clef, documents secrets, etc.) mais également, dans une moindre mesure (en raison de l'espace disponible) de fichiers son Ogg ou MP3, ou encore d'images.

Les tests

Nous avons effectué nos tests avec un PC construit autour d'un Celeron 800 utilisant un contrôleur USB VIA VT82C586B intégré à la carte mère. Le kernel utilisé est le plus récent à l'heure où nous écrivons ces lignes (2.4.16) et le périphérique est un Max Drive 32 Mo fabriqué par Maxell. Un autre périphérique a également été testé sans succès. Il s'agissait d'un EasyKey de 32 Mo qui semblait pourtant parfaitement reconnu par les pilotes du kernel. Nous n'avons cependant pas été en mesure d'accéder au système de fichiers (parfaitement fonctionnel sous Win98) en raison de nombreuses erreurs d'entrée/sortie.

Nous n'avons pas été, non plus, en mesure de trouver la provenance de ce problème et nous avons choisi de nous rabattre sur un modèle fabriqué par une autre société. Pour information, le périphérique était identifié sur le bus USB avec le couple Vendeur / Produit 0x1065 / 0x2136. Il est toutefois probable, au moment où vous lirez ce texte, qu'une nouvelle version du kernel, et donc du support USB, soit disponible et de ce fait, que ce périphérique soit parfaitement reconnu.

Support USB / SCSI

L'intégralité du support USB, contrôleur et périphérique fait entièrement partie du kernel Linux contrairement, par exemple, au support PCMCIA. Voilà pourquoi il est très fortement conseillé de disposer de la plus récente version du kernel. Dans la configuration des sources, vous devrez activer (de préférence sous la forme de modules) le support pour les points suivants :

  • Support for USB

    Pour le contrôleur USB (en fonction du type de contrôleur) :

  • UHCI (contrôleur Intel, VIA, etc.)
  • UHCI Alternate Driver
  • OHCI (Compaq, Imac, OPti, SiS, ALI, etc.)

    Pour le support du stockage :

  • USB Mass Storage
  • USB Mass Storage Verbose Debug (recommandé)

    Note : Par souci d'adaptation à vos futurs achats, nous vous conseillons tout simplement de compiler le support de tous les types de périphériques USB sous la forme de modules. Ainsi, en perdant un peu d'espace disque, vous vous assurez de pouvoir gérer n'importe quel matériel déjà pleinement ou partiellement supporté par Linux.

    Le support de l'USB Mass Storage, qui est impératif ici, agit comme une passerelle entre l'USB et une émulation SCSI. De ce fait, tous les périphériques de ce type reconnus sur le bus USB deviendront des périphériques de stockage SCSI. Il faut donc que votre futur kernel dispose du support permettant la gestion des périphériques SCSI :

  • SCSI support
  • SCSI disk support
  • SCSI generic support
  • Verbose SCSI error reporting

    Encore une fois, une compilation sous la forme de modules est recommandée. Une fois tout cela configuré (sans oublier le support de vos autres périphériques), il ne vous restera plus qu'à lancer la compilation des différents éléments du kernel :

    # make dep clean bzImage modules modules_install
    

    Installation et configuration

    Après avoir redémarré avec le nouveau kernel, il vous faudra charger en premier lieu le support du contrôleur USB. Ici, notre contrôleur VIA VT82C586B est pris en charge par le module usb-uhci :

    # modprobe usb-uhci
    

    Il vous faudra ensuite monter le système de fichiers virtuel concernant l'USB dans le répertoire /proc/bus :

    # mount -t usbdevfs NONE /proc/bus/usb 
    

    Dès lors, vous pourrez obtenir des informations sur votre contrôleur USB et le hub intégré à la carte mère :

    # cat /proc/bus/usb/devices
    
    T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
    B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
    D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
    P:  Vendor=0000 ProdID=0000 Rev= 0.00
    S:  Product=USB UHCI Root Hub
    S:  SerialNumber=e400
    C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
    E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
    

    Le seul périphérique en présence pour le moment est le hub USB (Product=USB UHCI Root Hub). Nous n'avons pas encore branché notre nouveau périphérique. Avant de le faire, chargeons immédiatement le support pour les périphériques de stockage USB :

    # modprobe usb-storage
    

    Le journal système nous informe de la bonne marche de l'opération :

    kernel: Initializing USB Mass Storage driver...
    kernel: usb.c: registered new driver usb-storage
    kernel: USB Mass Storage support registered.
    

    Il nous suffit maintenant de connecter notre Max Drive et de constater sa détection dans le même journal système :

    kernel: hub.c: USB new device connect on bus1/2, assigned device number 11
    kernel: usb-storage: act_altsetting is 0
    kernel: usb-storage: id_index calculated to be: 72
    kernel: usb-storage: Array length appears to be: 74
    kernel: usb-storage: USB Mass Storage device detected
    kernel: usb-storage: Endpoints: In: 0xc43931a0 Out: 0xc43931b4 Int: 0xc43931c8 (Period 1)
    kernel: usb-storage: New GUID 0d7d010000000717150300f0
    kernel: usb-storage: GetMaxLUN command result is 1, data is 0
    kernel: usb-storage: Transport: Bulk
    kernel: usb-storage: Protocol: Transparent SCSI
    kernel: usb-storage: *** thread sleeping.
    kernel: scsi0 : SCSI emulation for USB Mass Storage devices
    [...]
    kernel: SCSI device sda: 64000 512-byte hdwr sectors (33 MB)
    [...]
    kernel: sda: Write Protect is off
    kernel: sda1
    kernel: WARNING: USB Mass Storage data integrity not assured
    kernel: USB Mass Storage device found at 11
    

    Nous avons, bien sûr, éliminé bon nombre de messages de débogage pour ne conserver que le plus intéressant. On apprend alors que le périphérique est détecté, que l'émulation SCSI est mise en place, la taille du support est détectée, et la protection en écriture est levée. On notera qu'avec des kernels moins récents, il était nécessaire de modifier le source du pilote SCSI afin de permettre l'écriture. Cependant, le plus important ici est de relever le message d'avertissement exposant on ne peut plus clairement que l'intégrité des données contenues dans le périphérique n'est pas assurée. Le support de ces périphériques n'est pas à considérer comme stable et des erreurs peuvent survenir et causer la perte de tout ou partie des données stockées. Agissez donc avec la plus grande prudence jusqu'à la stabilisation des pilotes.

    Comme l'indiquent les lignes dans le journal système, un nouveau périphérique est créé: sda1. Autrement dit, nous avons à présent accès à une pseudo-partition d'un pseudo-disque SCSI. Nous pouvons alors monter le système de fichiers :

    # mount -v /dev/sda1 /mnt/dok
    mount: you didn't specify a filesystem type for /dev/sda1
           I will try all types mentioned in /etc/filesystems or /proc/filesystems
    /dev/sda1 on /mnt/dok type umsdos (rw)
    

    Un système de fichiers FAT de type DOS est détecté. On pourra toutefois forcer le support pour VFAT avec l'option -t :

    # mount -v -t vfat /dev/sda1 /mnt/dok
    

    Le système de fichiers a été monté correctement et nous pouvons maintenant lire et écrire sur cette unité de stockage comme avec n'importe quel autre disque :

    # mount
    [...]
    /dev/sda1 on /mnt/dok type vfat (rw)
    

    Ici, le système de fichiers VFAT est celui installé par défaut sur le périphérique par le constructeur. Rien ne vous empêche d'utiliser un système de fichiers davantage approprié pour vos besoins :

    # umount /mnt/dok
    # mke2fs /dev/sda1
    mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
    Filesystem label=
    OS type: Linux
    Block size=1024 (log=0)
    Fragment size=1024 (log=0)
    8000 inodes, 31928 blocks
    1596 blocks (5.00%) reserved for the super user
    First data block=1
    4 block groups
    8192 blocks per group, 8192 fragments per group
    2000 inodes per group
    Superblock backups stored on blocks:
    	8193, 24577
    Writing inode tables: done
    Writing superblocks and filesystem accounting
    information: done
    

    L'utilitaire mke2fs n'oppose pas la moindre résistance puisqu'il croit avoir affaire à un véritable disque SCSI.

    Attention : Formater ce périphérique en ext2 pose néanmoins un problème quant à la compatibilité avec d'autres systèmes. Comme on peut s'en douter, Windows ne comprenant pas ce système de fichiers, il ne saura pas en lire le contenu. Malheureusement, en fonction des pilotes Win32 installés sur l'OS propriétaire, un système de fichier ext2 sera considéré comme un problème d'intégrité des données non récupérables et le système de fichiers VFAT sera installé sans aucun avertissement. Ceci provoquera la perte des informations sur le périphérique de manière irréversible.

    Analyse et conclusion

    Suite aux essais que nous avons effectués, nous n'avons pas rencontré de problèmes concernant l'intégrité des données. Cependant, si le message du support usb-storage est si clair, ce n'est pas pour rien. Concernant la viabilité de ce type de périphérique, on regrettera son coût comparé à d'autres solutions moins ergonomiques.

    Autre grand point négatif, alors même que les systèmes de stockage sur SmartCard tendent à disparaître pour laisser leur place à des cartes intelligentes assurant physiquement une protection des données, ce type de périphérique ne comporte aucune sécurité. Ainsi, la seule sécurité de données sensibles stockées de cette manière repose sur un facteur humain. Il vous reste cependant la possibilité de chiffrer vos fichiers avant l'écriture sur le nouveau média de stockage, mais cela n'empêchera pas la copie.

    L'ajout dans le périphérique d'un processeur permettant le chiffrement des données et contrôlant l'accès en lecture et en écriture aurait été une bonne initiative quitte à augmenter le coût du matériel d'une centaine de francs.

    Le principal atout disparaît ainsi pour toute personne utilisant une application comme GnuPG et désireuse d'avoir à sa disposition ses trousseaux de clefs à tout moment. Peut-être que la prochaine génération de périphériques intégrera un tel système d'authentification ...

    Liens

    * Linux USB
    * Le périphérique original DiskOnKey
    * Le site de Maxell Europe

    Linux Magazine France n° 35 - Janvier 2002