Forum Linux.embarqué Cryptsetup: help !!!

Posté par Vanou le 04 avril 2016 à 09:07. Licence CC By‑SA.

Étiquettes :

avr.

2016

Bonjour,

Je souhaiterais installer cryptsetup sur une cible ARM avec un linux sans biensur utiliser apt-get ou autre programme d'installation.
Pour ce faire J'ai déjà cross compilé sur mon hôte avec l'option arm-linux-gnueabihf, libgpg-error, libgcrypt, lvm2 et pour finir cryptsetup. La compile s'est bien passée, j'ai donc cryptsetup disponible sur mon hôte.

Maintenant je me trouve bloqué pour passer a l'étape suivante qui consiste a exécuter cryptsetup depuis ma cible.
Auriez vous une idée ? Quelles sont les autres étapes nécessaires ?

Merci d'avance

# Le soucis c'est ?

Posté par TheBreton le 04 avril 2016 à 12:30. Évalué à 1.

Bonjour, je ne comprend pas trop ton soucis. Maintenant que tu dispose d'un executable au format de ta cible quel est le soucis :
-tu ne sait pas comment le transférer sur ta cible ?
-> Perso sur mes cibles j'ai souvent un ethernet (montage nfs), ou un port usb (je dédie une partie de ma mem emmc en usb mass storage device), ou une carte SD (copie de fichier dessus), ou une liaison série (picocom ou minicom pour le transfert) ou les fonctions de transfert uboot
-Cela ne marche pas sur ta cible
-> Il ne manquerait des library sur ta cible par hasard ? Tu as un message d'erreur ?
-Autre : ?
- [^] # Re: Le soucis c'est ?
  
  Posté par Vanou le 04 avril 2016 à 12:56. Évalué à 1.
  
  Merci pour ta réponse.
  Dans ma cross compile, je n'ai pas renseigné --prefix
  . Est ce grave ?
  Et puis Je ne sais pas ou récupérer l'exécutable cryptsetup sur mon hôte et surtout si le seul exécutable suffirait?
  Pour ce qui est du transfert, pas de soucis j'ai un nfs monté.
  - [^] # Re: Le soucis c'est ?
    
    Posté par benja le 04 avril 2016 à 13:30. Évalué à 1. Dernière modification le 04 avril 2016 à 13:34.
    
    Et puis Je ne sais pas ou récupérer l'exécutable cryptsetup
    
    find / -type f -name crypsetup
    Ensuite tu fais un file et un readelf -d dessus pour voir si t'as bien du code ARM et pour connaître les bibliothèque à installer au besoin. Par contre pour les dépendances fichiers/configurations, inspire toi de la doc. J'espère quand même que tu n'as pas essayé de faire un make install sans changer de prefix*… sinon bonjour l'état de ton hôte là :D
    
    Est-ce que tu as utilisé un sdk particulier ? Car tu n'as pas indiqué avoir compilé de libc non plus. De plus mon crypsetup dépend aussi de pcre et udev, je suppose que tu as désactivé leur prise en charge à la compilation ?
    
    Pourquoi ne passerais-tu pas par un truc tout automatisé genre buildroot ?
    
    *: pour être plus correcte, il faut laisser le prefix standard (pour que les programmes aillent chercher leur fichiers dans les paths standards) mais utiliser un truc genre DESTDIR=/répertoire_de_staging pour faire le make install… Ça dépend un peu de chaque programme et il faut donc un peu étudier la question au cas part cas (= lire le Makefile), mais bon je suppose qu'un truc aussi essentiel que cryptsetup support ce genre de use-case. Deusio, comme tu n'installes quand même pas sur la cible, ça sera plus simple de tout faire à la main…
    - [^] # Re: Le soucis c'est ?
      
      Posté par Vanou le 04 avril 2016 à 14:55. Évalué à 1.
      
      Oups, je n'ai pas changé le prefix (pas renseigné) !
      
      Si je dois recompiler, quel prefix mettre ?
      Doit il être du style : --prefix=/usr
      Dois-je mettre le même prefix pour cryptsetup et toutes les dépendances que j'ai citées au début de mon post ? Pourrais-tu me renvoyer vers un tuto ?
      
      J'ai un SDK perso, et avec mon SDK je compile le noyau pour ma cible ARM. Mon kernel se charge depuis l'Hôte vers la RAM cible à l'aide de TFTP et s'exécute sur la cible et mon filesystem se monte sur ma cible. Le kernel ne se trouve pas sur une flash ou une carte SD. Mon NFS permet ensuite de communiquer avec l'hôte. Dans mon SDK j'ai compilé la libc, mais prce er udev ne me disent rien.
      
      Ou puis-je trouver un buildroot tout automatisé pour ma cible ARM ? Je précise j'ai bien recompilé mon noyau avec le module DM-CRYPT.
      - [^] # Re: Le soucis c'est ?
        
        Posté par benja le 04 avril 2016 à 18:25. Évalué à 1. Dernière modification le 04 avril 2016 à 18:26.
        
        Le "prefix" sert généralement à trois choses: 1) enregistrer en dur dans ton programme où il va être installé et où il peut rechercher ses resources, documentation, etc. (p.e. une icone dans "$prefix/share/icons/monprogramme.png"). 2) au moment de faire "make install", l'endroit où vont être installés le programme fraichement compilé et ses resources 3) au moment du configure, déduire l'endroit où sont installés les dépendances/bibliothèque/includes.*
        
        Bref dans ton cas, ça n'a pas beaucoup d'importance, car:
        1) cryptsetup n'a pas l'air d'utiliser un fichier de configuration cannonique (tu spécifies tout sur la ligne de commande)
        2) tu ne veux surtout pas installer sur le système qui compile. Sauf éventuellement si tu veux faire un staging afin de faire facilement une archive à transfèrer (dans ce cas cf. mon précédent commentaire, il faut que le préfix corresponde à l'endroit où tu veux l'installer sur la cible + le buildsystem doit supporter quelque chose de similaire à un DESTDIR qui va servir de "super" préfix).
        3) tu as déja du règler le problème pour réussir à compiler - tu linke en statique - tes libairie seront installées dans un répertoire connu par le linker dynamique (/etc/ld.so.conf sous linux…) - tu cross compile, tu as déja du patcher le build-system pour avoir quelque chose de potable (barrer la mention inutile).
        
        Illustration du point 3: dans ton cas il se pourait que ce soit gpgme. Généralement tu peux souvent "overrider" cela avec un argument de type --with-gpg-error=/usr/local ou bien encore avec un ac_XXX=valeur (regarde la gueule du config.log pour avoir le nom de la variable). Généralement cela marche bien dans le cas non-cross compilation. Par contre, dans le cas de la cross-compilation, c'est parfois plus compliqué car le path des bibliothèque que tu linke n'est pas le même que le path sur la cible finale, ce qui peut poser problème lorsque la dite bibliothèque n'est pas installée dans un endroit standard (cf. encore le ld.so.conf, LD_RUN_PATH et compagnie, man ld.so pour les détails). Si tu compiles en statique tu n'auras pas ce problème bien entendu. Ça peut même être plus intéressant si tu as peu de programmes qui utilisent la même bibliothèque car le code non utilisé va être supprimé. C'est pourquoi busybox lie en statique une libc dans un seul binaire, comme ça seul les objets de la libc vraiment utilisés sont repris. Par contre si tu as beaucoup de programmes différents, ben ce gain de place disparait pour devenir négatif. Bref à toi de voir…
        
        À part cela, as-tu trouvé ton binaire et arrives-tu à le lancer sur ta cible ? Car amha le plus simple pour arriver à te faire progresser c'est d'y aller pas à pas pour que tu comprennes bien comme cela fonctionne…
        
        Pour conclure sur buildroot, c'est une sorte de méta systeme de build, un peu comme portage de gentoo si tu connais. Ça compile toutes les dépendances de "paquets" que tu peux sélectionner via une interface de configuration et au finale ça peut générer un filesystem complet voir même une image à flasher. Ça supporte plus que probablement d'utiliser une toolchain "custom" à la place d'en construire une, c'est prévu pour être relativement facilement modifiable. En fonction de ce que tu veux faire, cela peut être intéressant d'investir en compétences là dedans, histoire de gagner du temps par la suite. Il y a d'autres outils similaire à buildroot, je n'en connais personnellement aucun, à part le truc de openwrt qui est basé (si je ne me trompe pas) sur buildroot.
        
        Pour info, c'est quel genre de cible ? Ton kernel c'est un kernel vanilla ? T'as compilé ta toolchain toi même ou bien c'est un truc proprio ? Peut-être que ta board est déja complètement supporté par buildroot (ou qu'un support complèt n'est plus très loin à ajouter)…
        
        *: Pour être complet, généralement tu as la possibilité de modifier spécifiquement certains endroits de recherche qui, par défaut, seraient calculés à partir de "prefix", p.e. (j'invente) --sysconfdir=/etc, --datapath=/opt/share.
        
        [^] # Re: Le soucis c'est ?
        
        Posté par Vanou le 05 avril 2016 à 00:13. Évalué à 1.
        
        Meci pour toutes ces infos c'est tres complet.
        J'utilise un raspberry pi et la toolchain est propriétaire.
        
        Il ya qq chose que je ne saisis pas bien. J'ai bien utilise la commande ./configure --enable-static --host=arm-linux-gnueabihf --prefix=addr-ip-target:/mnt/cryptsetup
        Je ne suis pas sur du préfix. Vais je directement retrouver mon executable cryptsetup sur la cible dans ce cas la ?
        Si C'est le cas, dois je compiler toutes les dependances avec le meme prefix ? Ou bien seul le prefix avec la cible est necessaire pour cryptsetup?
        Autre question, jusqu'ici j'avais compile avec le prefix par défaut et pour cible arm. Est ce normal' que j'arrive a lancer cryptsetup depuis mon hote? Ca ne devrait pas fobctionner .
        
        [^] # Re: Le soucis c'est ?
        
        Posté par benja le 05 avril 2016 à 01:23. Évalué à 1. Dernière modification le 05 avril 2016 à 01:28.
        
        En gros le préfix ne sert qu'au configure.
        Le configure va typiquement créer un fichier config.h et divers Makefiles. Dans le config.h seront définies des macro du préprocesseur qui permettent à la compilation de connaître la "configuration". Par exemple la macro HAVE_MATH_H sera définie si le script configure a détecté le fichier math.h. Tu auras aussi des constantes utilisées par ton programme, tel que les chemins d'accès. Tout ça c'est gèré par autotools, voir https://github.com/mbroz/cryptsetup/blob/master/configure.ac .
        
        Le préfix va aussi aider à détecter les bonnes bibliothèques. mais dans le cas de la cross compilation, ça ne peut pas marcher car tes bibliothèque cross-compilées ne sont pas installées dans un répertoire standard. I.e. tu veux que ton préfix vaut /usr mais tes bibliothèques sont installées dans /cross/usr/lib/… Ça peut parfois marcher si t'arrives à passer --sysroot=/cross dans les CFLAGS et LDFLAGS (y a peut-être une autre méthode…), Dans ce cas là, le compilateur va traduire de manière transparente les chemins de recherche. En gros les deux approches sont possibles, cela dépends surtout de comment est prévue ta toolchain.
        
        Deuxième point, on peut voire dans ce configure.ac que cryptsetup utilise pkg-config. Là, le prefix joue probablement une influence seulement si tu ne spécifie pas toi-même un chemin de recherche pour pkg-config. Si tu lance ./configure --help, tu devrais retrouver l'option qui te permette de spécifier le chemin de recherche des fichiers pkg-config. Ce sont ces fichiers .pc qui vont dire où sont les bilbiothèques à installer.
        
        Bref, oublie le préfix pour l'instant. Relance ./configure et fais super attention aux valeurs qu'il donne pour
        1) le compilateur. normalement ça serait un truc du genre gcc=/tonsdk/bin/arm-linux-gnueabihf-gcc
        2) les chemins des bibliothèque détectées.
        
        Vais je directement retrouver mon executable cryptsetup sur la cible dans ce cas la ?
        
        non. le configure va substituer le préfix dans les règles du Makefile, ce qui peut avoir (ou non) une incidence lors du "make install". Mais jamais cela ne va faire une copie via ssh ou que sais-je… (c'est théoriquement pas impossible, mais personne ne s'amuse à le faire).
        
        --enable-static
        
        ok ça c'est bon.
        
        Est ce normal' que j'arrive a lancer cryptsetup depuis mon hote?
        
        Ça dépend… ;-) Il y a moyen d'utiliser qemu avec bin-fmt pour pouvoir lancer de manière transparente un programme d'une autre architecture sous linux. Dans ton cas, cela me semble peu probable que tu aies configuré ton système de la sorte. Si tu lance le programme "file" sur ton binaire (ou "objinfo" ou readelf…) tu seras fixé sur l'architecture de ton binaire.
        
        Bon je remets un couche avec buildroot. Amha tu vas gagner pas mal de temps. Au pire tu n'es pas obligé d'utiliser le rootfs (image SD), tu peux te contenter de copier les binaires qui devront se retrouver quelque part dans un répertoire build. Ça supporte visiblement bien raspberrypi <3:
        https://github.com/buildroot/buildroot/tree/master/board/raspberrypi
        et il y a un paquet cryptsetup
        https://github.com/buildroot/buildroot/blob/master/package/cryptsetup/cryptsetup.mk
        
        Sinon une autre option, c'est de te faire un chroot, armv6 raspbian pour Rpi 1&2, armv7 debian armhf pour le Rpi 3, que tu lances via qemu+binfmt. Ensuite tu fais une compilation "standard" dedans. C'est juste assez lent… cf. https://wiki.debian.org/EmDebian/CrossDebootstrap#QEMU.2Fdebootstrap_approach
        
        Et une dernière option, comme la précédente tu fais un chroot et tu le partage via nfs pour ensuite faire le chroot sur ton Rpi. Ça sera probablement plus rapide qu'avec qemu et sans bug du à la cross-compilation ou à qemu.
        
        [^] # Re: Le soucis c'est ?
        
        Posté par Vanou le 11 avril 2016 à 13:28. Évalué à 1.
        
        Merci.
        J'ai vérifié, l'éxécutable se trouve sous /usr/sbin.
        Par contre lorsque je fais un file sur cet exe, il a été compilé en x86 ?!
        Je ne comprends pas, mon compilateur est bien renseigné sous mon PATH.
        De plus lorsque je lance arm-linux-gcc --version, j'obtiens bien la version. Ce qui prouve que mon compilo arm est bien présent et visible.
        Pourtant quand je lance le ./configure --enable-static --host=arm-linux-gnueabihf , je vois que checking arm-linux-gnueabihf no (pour info je n'ai pas renseigné le prefix)
        
        Aurais-tu des pistes ?
        Merci d'avance
        
        [^] # Re: Le soucis c'est ?
        
        Posté par Vanou le 11 avril 2016 à 16:21. Évalué à 1. Dernière modification le 11 avril 2016 à 21:54.
        
        Voici les commandes que j'ai exécutées:
        
        export PATH=/toolchains_for_arm/bin:$PATH # libgpg-error-1.19 cd $OUTPUT_DIR/libgpg-error-1.9 sudo ./configure --enable-static --host=arm-linux-gnueabihf sudo make clean sudo make sudo make install # libgcrypt 1.5.2 cd $OUTPUT_DIR/libgcrypt-1.5.2 sudo ./autogen.sh sudo ./configure --enable-static --host=arm-linux-gnueabihf sudo make clean sudo make sudo make install #LVM cd $OUTPUT_DIR/LVM2.2.02.98 export ac_cv_func_malloc_0_nonnull=yes c_cv_func_malloc_0_nonnull=yes ac_cv_func_realloc_0_nonnull=yes sudo ./configure --host=arm-linux-gnueabihf --enable-lvm1_fallback --enable-fsadm --with-clvmd --with-cluster=internal --with-pool=internal --with-user= --with-group= --with-device-uid=0 --with-device-gid=6 --with-pool=none --with-cluster=none --with-snapashots=none --with-mirrors=none sudo make clean sudo make sudo make install # cryptsetup 1.6.1 cd $OUTPUT_DIR/cryptsetup-1.6.1 sudo ./configure --host=arm-linux-gnueabihf --build=arm-linux --enable-static sudo make clean sudo make sudo make install file /usr/sbin/cryptsetup
        
        => ELF 64-bit LSB executable, x86-64 !!!
        
        [^] # Re: Le soucis c'est ?
        
        Posté par benja le 11 avril 2016 à 21:28. Évalué à 1.
        
        Normalement ton make install a du l'installer dans /usr/local/sbin vu que c'est le préfix par défaut. Tu ne dois pas non plus compiler en root ! (Fais un chown -R monuser: pour remettre les permissions des fichiers qui ont été créés pendant la compilation).
        
        Es-tu sûr que le configure/make s'est bien terminé ? (echo $? doit afficher 0 si tu le lances juste après les dites commandes).
        
        Est-ce que ton cross compilateur s'appelle bien gcc et non, p.e., arm-linux-gnueabihf-gcc ? Sinon fais aussi un export CC=arm-linux-gnueabihf-gcc (idem export CXX=arm-linux-gnueabihf-gcc++ si crypsetup utilise du c++). cf. sortie de ls /toolchains_for_arm/bin/gcc

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.