Comment puis-je bande locale symboles de module du noyau linux sans les casser?

Si je ne --strip-debug ou --strip-unneeded, j'ai l' .ko qui répertorie tous les noms de fonctions avec nm, si je fais juste strip foo.ko j'ai un module du noyau qui refuse de se charger.

Que quelqu'un connait un rapide raccourci comment faire pour supprimer tous les symboles qui ne sont pas nécessaires pour le module de chargement, de sorte que les gens ne peuvent pas désosser l'API:s aussi facilement?

PS: Pour tout ce que vous open source bigots de missionnaires; c'est quelque chose que le grand public ne sera jamais utiliser, en tout cas, donc pas besoin de tourner la question dans un GPL flamme de la guerre.

Si vous voulez vraiment éviter une flamme de guerre, je suggère de ne pas généraliser les gens comme des fanatiques 🙂
Bon point, Tim 🙂 Mieux maintenant? 😀
Si le "grand public" ne verrez jamais votre code pourquoi êtes-vous inquiet au sujet de l'ingénierie inverse?
Peut pas entrer dans les détails, mais considérons, par exemple, que vous avez eu un client ou un partenaire d'affaires qui voulaient faire, disons que l'interopérabilité test avec quelqu'un que vous considérez comme un concurrent, dans leurs locaux, sur leur matériel?
Ou pour le dire d'une autre façon, pourquoi diable voudrais-je être inquiet au sujet du "grand public" reverse engineering mon code?

OriginalL'auteur Kimvais | 2010-05-24

  1. 7

    Avec pas de réponse à mes questions précédentes, voici quelques suppositions qui pourraient également être des indices, et une étape à une réponse:

    De ce que je me souviens, une .ko n'est rien mais une .o fichier résultant de la fusion de toutes les .o les fichiers générés par votre module source, et l'ajout d'une .modinfo section.
    À la fin de tout .ko bâtiment Makefile, il y a un LD appel: à partir de ce que je me souviens, le ld est appelé avec l'option-r, et c'est ce qui le créer .o fichier que le fichier Makefile appels un .ko. Ce fichier résultant n'est pas à confondre avec une archive ou d'un objet de bibliothèque (.un fichier), c'est juste un format d'archivage /de l'emballage multiple .o fichiers: Un objet fusionné est le résultat d'un lien qui produit encore un autre .o module: Mais dans le résultat de ce module, toutes les sections qui pourraient être fusionnées ont été, et tous publics /externe paires qui pourraient être résolus ont été à l'intérieur de ces sections.
    Donc je suppose que vous vous retrouvez avec votre .ko fichier contenant tous les fichiers de votre "local" extern définitions:

    • Ceux qui sont extern parce qu'ils
      sont utilisés pour appeler l'ensemble de l' .o
      les modules de votre .ko (mais ne sont pas
      plus besoin de vous car ils ne sont pas
      censé être appelé de l'extérieur
      l' .ko), et

    • ceux qui l' .ko module NE doivent
      communiquer correctement avec le chargeur
      et le noyau.

    Les anciens ont probablement déjà été résolu par ld lors de la fusion, mais ld a aucun moyen de savoir si vous avez l'intention d'avoir eux aussi être appelé à partir en dehors de la .ko.

    Donc le superflu et de symboles que vous voyez sont ceux qui sont extern pour chacun de vos .o fichiers, mais ne sont pas nécessaires comme extern pour la suite .ko.
    Et ce que vous êtes à la recherche d'un moyen de bande que les.

    Ne de ce dernier paragraphe décrire correctement les symboles que vous souhaitez vous débarrasser?

    Je pense que c'est exactement ce dont nous parlons ici. Désolé de ne pas mettre à jour plus tôt. En tout cas, ce que vous dites ici tout son sens et je vais avoir à investiguer davantage.

    OriginalL'auteur filofel

  2. 6

    Je pense que c'est exactement ce que nous sommes
    parler ici.

    OK, il semblerait que la seule solution est de "manuellement" supprimer le superflu et de symboles. Le "strip" de l'utilitaire semble autoriser individuellement décapage (ou de conservation), de symboles, de sorte que vous auriez à utiliser une --strip-tous et un petit tas de --keep-symbole= . Notez que --générique pourrait aider un peu, pas trop. Vous pouvez faire le contraire, bien sûr, de conserver tous et individuellement bande, selon ce qui est le plus pratique.

    Un bon point de départ consisterait à supprimer tous les symboles que vous explicitement définis dans votre module pour la croix-module de liaison et ne voulez pas paraître -, en laissant les évidentes utiles, des choses comme init et de sortie. Et à ne pas les toucher ceux qui ont été généré par /appartiennent au noyau dev de l'infrastructure logicielle. Puis, d'essai et d'erreur jusqu'à ce que vous trouver la bonne recette... En fait, je pense que vos propres symboles peut être amovible, à l'exception de ceux expressément définis toi-même comme EXPORT_SYMBOL (et init /sortie, bien sûr).

    Bonne chance! 🙂

    PS:

    En fait, il semble que la source d'information existe dans tous les .ko projets d'effectuer un décapage automatiquement: à Moins que je me manque quelque chose, il semble que tout ce qui n'est pas EXPORT_SYMBOL ou explicitement par le logiciel de construction pourraient théoriquement être dépouillé par défaut à la fin de "r dl-" le temps qui se termine .ko construire. C'est juste que je ne pense pas que la suite d'outils (compilateur /linker) provision /directives /options à titre individuel, de désigner "la bande ou de la garder" syms pour le mobile de liaison /de fusion. Sinon, quelques modifications dans les EXPORT_SYMBOL macro et dans quelques autres endroits pourrait probablement obtenir le résultat que vous êtes après, et le rasage de quelques octets de plus .ko fichiers dans n'importe quel système Linux.

    Ok, ce genre d'transforme la question à quoi d'autre est nécessaire que *_init(), *_exit() et ceux que j'explicitement EXPORT_SYMBOL()? - ou est-il vraiment?
    C'est pourquoi j'ai mentionné ce serait d'essai et d'erreur: je ne suis pas tout à fait sûr, je n'ai pas eu à jouer le jeu jamais. Je voudrais commencer par laisser seul dans tout le symbole que je n'ai pas mis moi-même, et en supprimant tout ce qui appelle à travers mes propres modules source et qui a sans doute été résolu par l' .ko ld. Si cela fonctionne, je voudrais commencer à partir de celui-ci et essayer de faire un peu plus de nettoyage, fragmentaire, de l'essai, et l'itération de ce genre. Très empirique, mais bon... si cela résout votre problème, il pourrait être assez bon.

    OriginalL'auteur filofel

  3. 6

    Je viens de construire un noyau sans se rendre compte de la configuration du noyau avait symboles de débogage activé, de sorte que la taille du modules sont assez importantes. Cela a fonctionné pour moi:

    # du -sh /lib/modules/3.1.0/
1.9G    /lib/modules/3.1.0/
# find /lib/modules/3.1.0/-iname "*.ko" -exec strip --strip-debug {} \;
# du -sh /lib/modules/3.1.0/
134M    /lib/modules/3.1.0/

    Rechercher tous les fichiers dans /lib/modules/3.1.0 nommé *.ko et exécuter strip --strip-debug sur chacun d'eux.

    OriginalL'auteur aorth

  4. 3

    Je ne suis pas sûr de comprendre ce que le problème est vraiment:
    Lors de l'élaboration d'une .ko, si je ne suis pas d'ajouter explicitement quelque chose comme 

    ccflags-y += -ggdb -O0 -Wall

    dans mon Makefile, je ne suis pas un symbole, mais pour ceux que je publie ou externe réf moi-même. Je suis sûr que je ne reçois pas tous les autres symboles pour plusieurs bonnes raisons:

    • la résultante .ko fichier est beaucoup plus petit,
    • dumping le fichier et l'analyse de l'ELFE affiche les tables ne sont pas là,
    • Je ne peux pas le voir, ni l'accès aux symboles de kgdb.

    Donc je suis un peu perplexe à votre question, en fait?... Ce sont ces symboles que vous voyez dans votre .ko (et ne veux pas)?
    Comment sont-ils déclaré dans votre fichier source?
    Dans lequel l'ELFE sections ne sont-ils finir?
    Et (désolé, question stupide à l'avance): Avez-vous définir statique de toutes les choses qui n'ont pas besoin d'être vu en dehors de leur propre module?

    Nan, ils finissent par y avec -Os et pas de -g -drapeaux.

    OriginalL'auteur filofel

  5. 1

    En plus de filofel du post:

    La raison de décapage de l'espace utilisateur bibliothèques partagées maintient le fonctionnement est parce que leurs symboles exportés sont dans le .dynsym section qui n'est jamais dépouillé. .ko fichiers, toutefois, ne pas utiliser de dynsym.

    OriginalL'auteur user502515

  6. 1

    personnes ont rapporté des succès avec

    strip --strip-unneeded
    quel est en fait le strip avec ce drapeau?

    OriginalL'auteur Angus Beef

  7. 0

    strip -g XXX.

    Mon Précédent problème, comme ce qui vous est arrivé est sloved par cette commande dans l'appareil embarqué avec Linux Kernel 3.0.8.

    J'ai appris par le biais de quelques essais et erreurs que l'utilisation de strip -g sur un module du noyau ne modifie pas *.ko de ce qui est normalement produite. Cependant, grâce à la collaboration avec un collègue, il semble que l'utilisation de gcc avec l'option -g0 n'affecte les symboles de débogage. Je suppose que c'est parce que les modules du noyau est construit légèrement différente de celle d'autres modules: voir cette réponse dans ce fil.

    OriginalL'auteur Beil Zheng