WedX - журнал о программировании и компьютерных науках

Как удалить локальные символы из модуля ядра Linux, не нарушая его?

Если я делаю --strip-debug или --strip-unneeded, у меня есть .ko, в котором перечислены имена всех функций с nm, если я делаю только strip foo.ko, у меня есть модуль ядра, который отказывается загружаться.

Кто-нибудь знает быстрый ярлык, как удалить все символы, которые не нужны для загрузки модуля, чтобы люди не могли так же легко реконструировать API?

PS: Для всех миссионеров фанатов с открытым исходным кодом; это то, что широкая публика никогда не будет использовать в любом случае, поэтому не нужно превращать вопрос в войну флейма GPL.


  • Если вы действительно хотите избежать флеймовой войны, я предлагаю не обобщать людей как фанатиков :) 24.05.2010
  • Хороший вопрос, Тим :) Теперь лучше? :D 24.05.2010
  • Если широкая публика никогда не увидит ваш код, почему вы беспокоитесь о реверс-инжиниринге? 25.05.2010
  • Не могу вдаваться в подробности, но давайте рассмотрим, например, что у вас был клиент или деловой партнер, который хотел провести, скажем, тест на совместимость с кем-то, кого вы считаете конкурентом, — в их помещении, на их оборудовании? 26.05.2010
  • Или, другими словами, с какой стати мне беспокоиться о том, что широкая публика реконструирует мой код? 26.05.2010
  • Вы пометили символы, которые не хотите экспортировать static? 02.06.2010

Ответы:


1

Без ответа на мои предыдущие вопросы, вот несколько догадок, которые также могут быть подсказками и шагом к ответу:

Насколько я помню, .ko — это не что иное, как файл .o, полученный в результате слияния всех файлов .o, сгенерированных вашим исходным модулем, и добавления раздела .modinfo. В конце любого .ko-сборочного Makefile есть вызов LD: насколько я помню, ld вызывается с опцией -r, и это то, что создает тот .o-файл, который Makefile называет .ko. Этот результирующий файл не следует путать с архивом или библиотекой объектов (файл .a), который представляет собой просто формат, архивирующий/упаковывающий несколько файлов .o в один: объединенный объект является результатом ссылки, которая создает еще один файл .o. модуль: Но в результирующем модуле все разделы, которые можно было объединить, и все пары общедоступных/внешних, которые можно было разрешить, были внутри этих разделов. Итак, я предполагаю, что вы получите файл .ko, содержащий все ваши «локальные» внешние определения:

  • Те, которые являются внешними, потому что они используются для вызова модулей .o в вашем .ko (но больше не нужны, поскольку их не предполагается вызывать из-за пределов .ko), и

  • те, которые нужны модулю .ko для правильной связи с загрузчиком и ядром.

Первые, скорее всего, уже были разрешены ld во время слияния, но ld не может узнать, собираетесь ли вы сделать так, чтобы они также вызывались из-за пределов .ko.

Таким образом, посторонние символы, которые вы видите, являются внешними для каждого из ваших файлов .o, но не нужны в качестве внешних для результирующего .ko. И то, что вы ищете, это способ раздеть только их.

Правильно ли этот последний абзац описывает символы, от которых вы хотите избавиться?

04.06.2010
  • Я думаю, что это именно то, о чем мы говорим здесь. Извините, что не обновил раньше. В любом случае то, что вы здесь говорите, имеет смысл, и мне придется провести дальнейшее расследование. 04.06.2010

  • 2

    Я думаю, что это именно то, о чем мы говорим здесь.

    Хорошо, тогда похоже, что одним из решений является «ручное» удаление посторонних символов. Утилита «strip», по-видимому, позволяет удалять (или сохранять) символы по отдельности, поэтому вам придется использовать один --strip-all и небольшой набор --keep-symbol= . Обратите внимание, что --wildcard тоже может немного помочь. Можно, конечно, и наоборот, оставить все и раздеть по отдельности, смотря как удобнее.

    Хорошим началом может быть удаление всех символов, которые вы явно определили в своем модуле для межмодульного связывания и которые не должны появляться, — просто оставьте очевидные полезные символы, такие как инициализация и выход. И не трогать те, которые были сгенерированы / принадлежат программной инфраструктуре разработки ядра. Затем методом проб и ошибок, пока вы не найдете правильный рецепт... На самом деле, я думаю, что все ваши собственные символы могут быть удалены, кроме тех, которые вы явно определили сами как EXPORT_SYMBOL (и init/exit, конечно).

    Удачи! :)

    PS:

    На самом деле кажется, что необходимая исходная информация существует во всех проектах .ko для автоматического выполнения требуемой очистки: если я что-то не упустил, кажется, что все, что не EXPORT_SYMBOL или явно вставлено программным обеспечением сборки, теоретически может быть удалено по умолчанию. в конце времени "ld -r", которое завершает сборку .ko. Просто я не думаю, что цепочка инструментов (компилятор/компоновщик) имеет положение/директивы/параметры для индивидуального назначения символов «удалить или сохранить» для перемещаемой ссылки/слияния. В противном случае некоторые изменения в макросе EXPORT_SYMBOL и в некоторых других местах, вероятно, могли бы привести к желаемому результату и сократить некоторые байты из большинства файлов .ko в любой системе Linux.

    05.06.2010
  • Хорошо, это как бы трансформирует вопрос в - что еще нужно, кроме *_init(), *_exit() и тех, которые я явно EXPORT_SYMBOL()? - или это действительно все? 07.06.2010
  • Вот почему я упомянул, что это будет метод проб и ошибок: я не совсем уверен, мне никогда раньше не приходилось играть в эту игру. Я бы начал с того, что оставил в покое любой символ, который не поставил сам, и удалил все, что вызывается в моих собственных исходных модулях и что предположительно было разрешено с помощью .kold. Если это сработает, я бы начал с этого и попытался сделать еще несколько очисток, по частям, тестированию и повторению, как это. Очень эмпирически, но, черт возьми... если это решит вашу проблему, этого может быть достаточно. 08.06.2010

  • 3

    Я только что собрал ядро, не осознавая, что в конфигурации ядра включены символы отладки, поэтому размер полученных модулей был довольно большим. Это сработало для меня:

    # 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/
    

    Найдите все файлы в /lib/modules/3.1.0 с именем *.ko и выполните strip --strip-debug на каждом из них.

    26.10.2011

    4

    Я не уверен, что понимаю, в чем проблема на самом деле: при разработке .ko, если я явно не добавлю что-то вроде

    ccflags-y += -ggdb -O0 -Wall
    

    в мой Makefile я не получаю никаких символов, кроме тех, которые я публикую или внешние ссылки. Я уверен, что не получаю никаких других символов по нескольким веским причинам:

    • результирующий файл .ko значительно меньше,
    • сброс файла и анализ ELF показывает, что таблиц там нет,
    • Я не вижу и не могу получить доступ к символам в kgdb.

    Так что я немного озадачен вашим вопросом, на самом деле?... Что это за символы, которые вы видите в своем .ko (и не хотите)? Как они объявлены в вашем исходном файле? В какие разделы ELF они попадают? И (извините, впереди глупый вопрос): вы определили статические все вещи, которые не нужно было видеть за пределами их собственного модуля?

    27.05.2010
  • Нет, они заканчиваются там с -Os и без -g -флагов. 04.06.2010

  • 5

    В дополнение к посту filofel:

    Причина, по которой удаление разделяемых библиотек пользовательского пространства позволяет им работать, заключается в том, что их экспортированные символы находятся в разделе .dynsym, который никогда не удаляется. Однако файлы .ko не используют dynsym.

    21.11.2010

    6

    люди сообщают об успехах

    strip --strip-unneeded 
    
    14.07.2011
  • что он на самом деле раздевает с этим флагом? 18.02.2013

  • 7

    strip -g XXX.

    Моя предыдущая проблема, подобная вашей, решается этой командой во встроенном устройстве с Linux Kernel 3.0.8.

    10.04.2016
  • Путем проб и ошибок я понял, что использование strip -g в модуле ядра не меняет *.ko по сравнению с тем, что обычно создается. Однако благодаря сотрудничеству с коллегой оказалось, что использование параметра gcc -g0 действительно влияет на символы отладки. Я подозреваю, что это связано с тем, что модули ядра построены немного иначе, чем другие модули: см. этот ответ в этой ветке. 02.02.2018
  • Новые материалы

    Объяснение документов 02: BERT
    BERT представил двухступенчатую структуру обучения: предварительное обучение и тонкая настройка. Во время предварительного обучения модель обучается на неразмеченных данных с помощью..

    Как проанализировать работу вашего классификатора?
    Не всегда просто знать, какие показатели использовать С развитием глубокого обучения все больше и больше людей учатся обучать свой первый классификатор. Но как только вы закончите..

    Работа с цепями Маркова, часть 4 (Машинное обучение)
    Нелинейные цепи Маркова с агрегатором и их приложения (arXiv) Автор : Бар Лайт Аннотация: Изучаются свойства подкласса случайных процессов, называемых дискретными нелинейными цепями Маркова..

    Crazy Laravel Livewire упростил мне создание электронной коммерции (панель администратора и API) [Часть 3]
    Как вы сегодня, ребята? В этой части мы создадим CRUD для данных о продукте. Думаю, в этой части я не буду слишком много делиться теорией, но чаще буду делиться своим кодом. Потому что..

    Использование машинного обучения и Python для классификации 1000 сезонов новичков MLB Hitter
    Чему может научиться машина, глядя на сезоны новичков 1000 игроков MLB? Это то, что исследует это приложение. В этом процессе мы будем использовать неконтролируемое обучение, чтобы..

    Учебные заметки: создание моего первого пакета Node.js
    Это мои обучающие заметки, когда я научился создавать свой самый первый пакет Node.js, распространяемый через npm. Оглавление Глоссарий I. Новый пакет 1.1 советы по инициализации..

    Забудьте о Matplotlib: улучшите визуализацию данных с помощью умопомрачительных функций Seaborn!
    Примечание. Эта запись в блоге предполагает базовое знакомство с Python и концепциями анализа данных. Привет, энтузиасты данных! Добро пожаловать в мой блог, где я расскажу о невероятных..


    Для любых предложений по сайту: [email protected]