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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

# 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 для каждого из них.

Answer 3

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

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

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

Удачи! :)

PS:

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

Answer 4

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

ccflags-y += -ggdb -O0 -Wall

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

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

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

Answer 5

человек сообщили об успехе с

strip --strip-unneeded 

Answer 6

В дополнение к сообщению Филофеля:

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

Answer 7

strip -g XXX.

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