37213 2019-09-12 17:37:55 +0300 Сборка syslinux6 в Sisyphus 2024-08-30 10:36:14 +0300 1 1 4 Development Sisyphus syslinux unstable all Linux CLOSED WONTFIX P3 enhancement --- 1 nickel nickel alexey.tourbin darktemplaralt glebfm iv klark ldv legion rider sin qa-sisyphus oldest_to_newest 184269 0 nickel 2019-09-12 17:37:55 +0300 Необходимо сделать модули syslinux6 *.с32 представляющиеся как dynamically linked ELF отличимыми от обычных dynamically linked ELF, чтобы проверка сборочницы на bad_elf_symbols их пропускала. https://bugzilla.altlinux.org/show_bug.cgi?id=34481#c19 184270 1 darktemplaralt 2019-09-12 17:41:44 +0300 (In reply to comment #0) > Необходимо сделать модули syslinux6 *.с32 представляющиеся как dynamically > linked ELF отличимыми от обычных dynamically linked ELF, чтобы проверка > сборочницы на bad_elf_symbols их пропускала. > https://bugzilla.altlinux.org/show_bug.cgi?id=34481#c19 Может, чем хакать файлы загрузчика, лучше добавить исключения для данных файлов? 184271 2 rider 2019-09-12 17:47:39 +0300 предлагаю спросить это у ментейнера сборочницы. 184274 3 nickel 2019-09-12 18:04:54 +0300 (В ответ на комментарий №2) > предлагаю спросить это у ментейнера сборочницы. Уже. Я даже уже пожалел, что сразу в devel не отправил свой изначальный вопрос... > > Алексей, Дмитрий, здравствуйте! > > 09.09.2019 9:57, Alexey Gladkov пишет: > >> On Sat, Sep 07, 2019 at 11:47:55AM +0300, Dmitry V. Levin wrote: >>>> Дим, эта бомба всё-таки взорвалась. Нужно какое-то более общее решение. >>>> Дим, что ты думаешь ? >>> Я бы хотел, чтобы эти ELFы можно было отличить от обычных. >>> >>> Если же это совсем обычные ELFы, которые при желании можно слинковать >>> с другими обычными, тогда я думаю, что их можно как-нибудь помечать >>> с тем, чтобы отличать от обычных. >> как насчёт добавить специальную секцию в elf ? > По-моему - отличная идея. > > Я добавлю, скажем, ".boot.code.module" и проверю - не сломается ли чего... > Кстати, добавлением секций со списком зависимостей и именем модуля > решается вопрос модульности в grub. > Мы же, как я понимаю, можем обойтись просто пустой секцией с именем? > > Чтобы не отвлекать Дмитрия от основных дел я, попробую разобраться в > премудростях perl и предложу свои изменения к эльфопроверялке по готовности. > > Дмитрий, можно ли расчитывать на освобождение модифицированных elf'ов из > "тюрьмы" в /boot в случае успеха? Тем не менее, вопрос к ldv@ по поводу возможности в дальнейшем размещать такие модифицированные ELF'ы за пределами /boot все еще актуален... 184279 4 ldv 2019-09-12 23:17:44 +0300 (In reply to comment #3) > (В ответ на комментарий №2) > > предлагаю спросить это у ментейнера сборочницы. > > > Уже. Я даже уже пожалел, что сразу в devel не отправил свой изначальный > вопрос... > > > > > Алексей, Дмитрий, здравствуйте! > > > > 09.09.2019 9:57, Alexey Gladkov пишет: > > > >> On Sat, Sep 07, 2019 at 11:47:55AM +0300, Dmitry V. Levin wrote: > >>>> Дим, эта бомба всё-таки взорвалась. Нужно какое-то более общее решение. > >>>> Дим, что ты думаешь ? > >>> Я бы хотел, чтобы эти ELFы можно было отличить от обычных. > >>> > >>> Если же это совсем обычные ELFы, которые при желании можно слинковать > >>> с другими обычными, тогда я думаю, что их можно как-нибудь помечать > >>> с тем, чтобы отличать от обычных. > >> как насчёт добавить специальную секцию в elf ? > > По-моему - отличная идея. > > > > Я добавлю, скажем, ".boot.code.module" и проверю - не сломается ли чего... > > Кстати, добавлением секций со списком зависимостей и именем модуля > > решается вопрос модульности в grub. > > Мы же, как я понимаю, можем обойтись просто пустой секцией с именем? > > > > Чтобы не отвлекать Дмитрия от основных дел я, попробую разобраться в > > премудростях perl и предложу свои изменения к эльфопроверялке по готовности. > > > > Дмитрий, можно ли расчитывать на освобождение модифицированных elf'ов из > > "тюрьмы" в /boot в случае успеха? > > Тем не менее, вопрос к ldv@ по поводу возможности в дальнейшем размещать такие > модифицированные ELF'ы за пределами /boot все еще актуален... Мы же именно для этого хотим добавить новую секцию, верно? 184280 5 legion 2019-09-12 23:29:59 +0300 (In reply to comment #4) > Мы же именно для этого хотим добавить новую секцию, верно? Да, было бы круто их отличать и люто карать! 184428 6 nickel 2019-09-20 14:25:07 +0300 (В ответ на комментарий №5) > Да, было бы круто их отличать и люто карать! Люто - это научить ldd этих эльфов не есть? 184430 7 legion 2019-09-20 14:52:25 +0300 (In reply to comment #6) > Люто - это научить ldd этих эльфов не есть? Скорее ld.so. Добавил ".boot.code" и хрен в системе выполнишь без дополнительных телодвижений. 184448 8 ldv 2019-09-21 13:16:13 +0300 (In reply to comment #7) > (In reply to comment #6) > > Люто - это научить ldd этих эльфов не есть? > > Скорее ld.so. Добавил ".boot.code" Почему именно ".boot.code"? 184488 9 nickel 2019-09-23 10:56:03 +0300 (В ответ на комментарий №8) > (In reply to comment #7) > > (In reply to comment #6) > > > Люто - это научить ldd этих эльфов не есть? > > > > Скорее ld.so. Добавил ".boot.code" > > Почему именно ".boot.code"? Может быть из-за упоминания в комментарии 3 .boot.code.module? Изначально логика была такая: побольше слов, чтобы избежать случайных пересечений в дальнейшем и то, что такую секцию с наибольшей вероятностью придется пришивать к ELF-файлам исполняющимся до запуска системы, а это будет скорее всего модуль загрузчика. Я что-то упускаю? 184491 10 legion 2019-09-23 12:37:14 +0300 (In reply to comment #8) > Почему именно ".boot.code"? Я взят то, что nickel@ предложил. Можно выбрать другое имя. > Я что-то упускаю? Вроде всё верно. 184492 11 ldv 2019-09-23 12:39:44 +0300 (In reply to comment #10) > (In reply to comment #8) > > Почему именно ".boot.code"? > > Я взят то, что nickel@ предложил. Можно выбрать другое имя. Давайте подумаем, какое имя лучше выбрать. 184493 12 legion 2019-09-23 12:57:01 +0300 (In reply to comment #11) > Давайте подумаем, какое имя лучше выбрать. .presystem ? .prekernel ? .bootloader ? .boottime ? 184494 13 rider 2019-09-23 13:00:42 +0300 Когда нечего придумать - можно взять random. Его точно никто использовать не будет. .yoongei6Hahshahgh6pais9cumeetohs1sie По смыслу всё равно это понимать должны только скрипты. 184495 14 ldv 2019-09-23 13:03:27 +0300 Это точно про boot? Если мы хотим некий относительно универсальный механизм, чтобы dynamic linker и rpmelfsym "не видели" такие ELFы, то это не только про boot. 184497 15 ldv 2019-09-23 13:07:32 +0300 (In reply to comment #14) > Это точно про boot? > > Если мы хотим некий относительно универсальный механизм, > чтобы dynamic linker и rpmelfsym "не видели" такие ELFы, > то это не только про boot. Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться? 184499 16 nickel 2019-09-23 13:39:59 +0300 (В ответ на комментарий №15) > (In reply to comment #14) > > Это точно про boot? > > > > Если мы хотим некий относительно универсальный механизм, > > чтобы dynamic linker и rpmelfsym "не видели" такие ELFы, > > то это не только про boot. > > Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться? Мне видится, что да - не должны, но тогда надо понять, какие еще бинарные модули могут подпадать под "юрисдикцию" этого механизма, чтобы придумать более общее название. Скорее всего многие программы, реализующие систему расширений на базе т.н. plugin'ов, пользуются dlopen и им перекрывать доступ к нему нельзя. Проверил для MySQL: /* Compile dll path */ strxnmov(dlpath, sizeof(dlpath) - 1, plugindir, "/", name, SO_EXT, NullS); DBUG_PRINT("info", ("dlopeninig %s", dlpath)); /* Open new dll handle */ if (!(dlhandle = dlopen(dlpath, RTLD_NOW))) { Хотя при сборке verify-elf регулярно недоволен: verify-elf: WARNING: ./usr/lib64/mysql/plugin/version_token.so: undefined symbol: my_charset_latin1 verify-elf: WARNING: ./usr/lib64/mysql/plugin/version_token.so: undefined symbol: psi_rwlock_service проверку rpmelfsym такие plugin'ны проходят нормально. Т.е. нужно найти еще хоть что-то, что собирается в dynamically linked ELF, но при этом не являющийся ни библиотекой или плагином, ни частью загрузчика... 184501 17 ldv 2019-09-23 13:43:46 +0300 (In reply to comment #16) > (В ответ на комментарий №15) > > (In reply to comment #14) > > > Это точно про boot? > > > > > > Если мы хотим некий относительно универсальный механизм, > > > чтобы dynamic linker и rpmelfsym "не видели" такие ELFы, > > > то это не только про boot. > > > > Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться? > > Мне видится, что да - не должны, но тогда надо понять, какие еще бинарные > модули > могут подпадать под "юрисдикцию" этого механизма, чтобы придумать более общее > название. Переформулирую вопрос: syslinux со своим необычным загрузчиком ELFов может использовать обычный dlopen или нет? Я предполагаю, что нет. > Скорее всего многие программы, реализующие систему расширений на базе т.н. > plugin'ов, пользуются dlopen и им перекрывать доступ к нему нельзя. Они используют обычный механизм, об этом речи не идёт. 184502 18 ldv 2019-09-23 13:46:18 +0300 Предлагаю подумать в строну имён вида .alt.ld.so.skip где .alt - это наш альтовый префикс. 184504 19 legion 2019-09-23 13:54:08 +0300 (In reply to comment #15) > Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться? Пока мы говорим о файлах в формате ELF, которые выполняются не в системе, а где-то ещё. В частности, в процессе загрузки до загрузки ядра. Исходя из этого ELF-файлы с этим признаком в идеале не должны обрабатываться никак в системе. Собственно, название секции я предлагал исходя из этого. Если хочется более общее название, то по сути этот признак будет отключать обработку этих файлов и только у нас в дистрибутиве. .altlinux.ignored ? .altlinux.unverified ? (In reply to comment #13) > Когда нечего придумать - можно взять random. Его точно никто использовать не > будет. > .yoongei6Hahshahgh6pais9cumeetohs1sie > > По смыслу всё равно это понимать должны только скрипты. Антон, это неудобно использовать в патчах. Хочется всё-таки осмысленное что-то. 184505 20 nickel 2019-09-23 13:57:29 +0300 (В ответ на комментарий №18) > Предлагаю подумать в строну имён вида .alt.ld.so.skip > где .alt - это наш альтовый префикс. Ничего против не имею. Это будет отражать скорее механизм обработки, а не принадлежность какому-то классу программ. Если других замечаний по http://git.altlinux.org/people/nickel/packages/?p=perl-qa-rpmelfsym.git;a=commit;h=e3038cc3481ef19080616f3fb0dbe5ac4e2dc442 не будет, то я переделаю с предложенным именем секции и пересоберу. 184506 21 rider 2019-09-23 13:57:46 +0300 Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip 184507 22 legion 2019-09-23 13:58:21 +0300 (In reply to comment #17) > Переформулирую вопрос: syslinux со своим необычным загрузчиком ELFов может > использовать обычный dlopen или нет? Я предполагаю, что нет. Может использовать, если будет LUA_USE_DLOPEN: http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=blob;f=com32/lua/src/loadlib.c#l139 184508 23 legion 2019-09-23 14:00:38 +0300 (In reply to comment #21) > Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, > которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip Ну во-первых хочется не только игнорировать их в rpm проверках. Ну и слово elf в ELF-хэдере кажется лишним ))) 184509 24 rider 2019-09-23 14:02:49 +0300 (В ответ на комментарий №23) > (In reply to comment #21) > > Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, > > которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip > > Ну во-первых хочется не только игнорировать их в rpm проверках. А где ещё ? > Ну и слово elf в ELF-хэдере кажется лишним ))) Ок, убираем rpm и elf и получаем .alt.verify.skip 184510 25 ldv 2019-09-23 14:05:13 +0300 (In reply to comment #22) > (In reply to comment #17) > > Переформулирую вопрос: syslinux со своим необычным загрузчиком ELFов может > > использовать обычный dlopen или нет? Я предполагаю, что нет. > > Может использовать, если будет LUA_USE_DLOPEN: > > http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=blob;f=com32/lua/src/loadlib.c#l139 Обычный dlopen завязан на обычный ld.so. Если загрузчик ELFов необычный, то и dlopen необычный. Это я спрашивал с точки зрения будущей реализации обработки этой секции в обычном ld.so/dlopen. 184511 26 ldv 2019-09-23 14:07:47 +0300 (In reply to comment #24) > (В ответ на комментарий №23) > > (In reply to comment #21) > > > Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, > > > которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip > > > > Ну во-первых хочется не только игнорировать их в rpm проверках. > > А где ещё ? Насколько я понял, идея Алексея в том, чтобы (1) игнорировать этих эльфов в ld.so и dlopen; (2) игнорировать их в rpmelfsym. причём (2) становится оправданным именно вследствие (1). 184512 27 legion 2019-09-23 14:15:26 +0300 (In reply to comment #25) > Это я спрашивал с точки зрения будущей реализации обработки этой секции в > обычном ld.so/dlopen. Если мы говорим про syslinux, то мы можем делать в системе что угодно. По понятным причинам они не пользуются системным libc. У них своя: http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=tree;f=com32/lib;h=97a22245bcaf4d2ce3b8d55542ffe584081e8c96;hb=5e426532210bb830d2d7426eb8d8c154d9dfcba6 184513 28 rider 2019-09-23 14:17:48 +0300 (В ответ на комментарий №26) > (In reply to comment #24) > > (В ответ на комментарий №23) > > > (In reply to comment #21) > > > > Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, > > > > которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip > > > > > > Ну во-первых хочется не только игнорировать их в rpm проверках. > > > > А где ещё ? > > Насколько я понял, идея Алексея в том, чтобы > (1) игнорировать этих эльфов в ld.so и dlopen; > (2) игнорировать их в rpmelfsym. > > причём (2) становится оправданным именно вследствие (1). А может ли кто-то однозначно утверждать, что такие эльфы никто и нигде не использует в libc'шном dlopen? Ну и если так, то может быть есть какие-то другие параметры, позволяющие добавить такое исключение ? Например Class в NONE выставить. 184514 29 legion 2019-09-23 14:32:37 +0300 (In reply to comment #28) > А может ли кто-то однозначно утверждать, что такие эльфы никто и нигде не > использует в libc'шном dlopen? Я могу. Эти файлы исполняются до загрузки вообще всего. Как правило эти файлы загружаются по сети или же из специального раздела, который понимает загрузчик. > Ну и если так, то может быть есть какие-то другие параметры, позволяющие > добавить такое исключение ? Например Class в NONE выставить. Так сделать нельзя. Например, syslinux проверяет класс и другие флаги: http://git.altlinux.org/people/legion/packages/extlinux.git?p=extlinux.git;a=blob;f=com32/lib/sys/module/common.c;h=05a27e854f5c0a4a8b960a9f3e5041c040ed94d7;hb=5e426532210bb830d2d7426eb8d8c154d9dfcba6#l222 Этот проект пользуется ELF как удобным форматом. Не нужно портить каким-то образом эти файлы. 184515 30 legion 2019-09-23 14:41:35 +0300 Антон, чтобы сократить количество вопросов вот выдержка из ченджлога проекта: com32: Switched from the COM32 object format to ELF as it is a much more powerful format that allows undefined symbols to be resolved at runtime and dynamic loading of module dependencies, which means modules now become shared object files instead of statically linked binaries - reducing both disk space and runtime memory consumption. https://wiki.syslinux.org/wiki/index.php?title=Syslinux_5_Changelog 184518 31 rider 2019-09-23 15:22:58 +0300 Лёш, спасибо. Так всё понятно. 184523 32 ldv 2019-09-23 16:37:51 +0300 (In reply to comment #20) > (В ответ на комментарий №18) > > Предлагаю подумать в строну имён вида .alt.ld.so.skip > > где .alt - это наш альтовый префикс. > > Ничего против не имею. Это будет отражать скорее механизм обработки, а не > принадлежность какому-то классу программ. > Если других замечаний по > > http://git.altlinux.org/people/nickel/packages/?p=perl-qa-rpmelfsym.git;a=commit;h=e3038cc3481ef19080616f3fb0dbe5ac4e2dc442 > не будет, то я переделаю с предложенным именем секции и пересоберу. Думаю, что в коде лучше использовать objdump -h -j .alt.ld.so.skip и проверять код возврата. 184529 33 nickel 2019-09-23 17:58:24 +0300 (В ответ на комментарий №32) > > Думаю, что в коде лучше использовать objdump -h -j .alt.ld.so.skip и проверять > код возврата. Если больше не планируется проверять ELF-файл на наличие каких-то других секций, то да, такая адресная проверка не допускает разночтений. В текущей же реализации можно "сэкономить" на повторном вызове objdump если нужно более 1 сравнения. 184531 34 ldv 2019-09-23 18:08:22 +0300 (In reply to comment #33) > (В ответ на комментарий №32) > > > > > Думаю, что в коде лучше использовать objdump -h -j .alt.ld.so.skip и проверять > > код возврата. > > Если больше не планируется проверять ELF-файл на наличие каких-то других > секций, то да, такая адресная проверка не допускает разночтений. В текущей же > реализации можно "сэкономить" на повторном вызове objdump если нужно более 1 > сравнения. Это понятно, но сейчас других сравнений не планируется. Можно оставить комментарий о том, как лучше поступить в будущем, если такие сравнения понадобится добавить. 184563 35 alexey.tourbin 2019-09-24 21:43:36 +0300 Мужчины, у меня написан ELF-парсер на Си для новой реализации rpmelfsym, который парсит только program header и PT_DYNAMIC. Секции чота парсить неохота. А есть какие-нибудь другие косвенные признаки, по которым можно понять, что эльф левый? 184564 36 alexey.tourbin 2019-09-24 21:59:02 +0300 Кстати когда ld.so откупоривает эльфа, то он смотрит у него какой-то ABI tag, в котором по идее зашита минимальная версия ядра, но вроде еще какие-то поля есть. Может туда прописать что-нибудь неприличное? Лучше конечно кросс-дистрибутивное решение выработать. 184565 37 legion 2019-09-24 23:01:23 +0300 (In reply to comment #35) > Секции чота парсить неохота. Так себе аргумент. > А есть какие-нибудь другие косвенные признаки, по которым можно > понять, что эльф левый? Когда мы с Димой пытались найти какие-нибудь признаки, то у нас это не получилось. В сизифе есть пакет extlinux. Можешь попробовать понять, что в /boot/extlinux лежат левые бинарники ? 184566 38 nickel 2019-09-25 00:26:19 +0300 (В ответ на комментарий №35) > А есть какие-нибудь другие косвенные признаки, по которым можно > понять, что эльф левый? Вот тут лог сборки, можно увидеть, что никаких особенных действий при линковке и strip'e модулей *.c32 не производится: http://git.altlinux.org/tasks/236472/build/400/x86_64/log ld -shared -m elf_x86_64 --hash-style=gnu -T /usr/src/RPM/BUILD/syslinux6-6.04/com32/lib/x86_64/elf.ld -soname libcom32.c32 -o libcom32.elf zlib/adler32.o zlib/compress.o zlib/crc32.o zlib/uncompr.o zlib/deflate.o zlib/trees.o zlib/zutil.o zlib/inflate.o [...] syslinux/initramfs_archive.o sys/libansi.o sys/gpxe.o atexit.o onexit.o abort.o objcopy --strip-debug --strip-unneeded libcom32.elf libcom32.c32 ld-скрипт: http://git.altlinux.org/tasks/236472/gears/400/git?p=git;a=blob;f=syslinux/com32/lib/x86_64/elf.ld;h=10ee7c44e160eb2da6b7db4f4e3db9f84754d5f6;hb=b1b5eaf39dc8d99e6a45479eb65642949e5f02f5 184567 39 alexey.tourbin 2019-09-25 02:48:58 +0300 Загрузчику тоже неохота парсить секции. Когда он ищет секцию .note.ABI-tag, то он на самом деле не видит имени секции, а только видит PT_NOTE и дальше смотрит что там внутри. https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=21a91b9484cd5d98bbbab45ef4e8e38cb45cce33;hb=5d245b5f8d9663953c20107e3bb16fe249e48126#l1678 Если загрузчик такие файлы сразу не отвергает, почему тогда rpmelfsym их должен сразу отвергать? Неохота на самом деле потому что когда я читаю из cpio stream, то могу сразу прочитать DYNAMIC секцию без создания временного файла. С точки зрения rpmelfsym мне нужна только DYNAMIC секция, в ней внутри всё есть! А если надо будет читать ELF в нескольких местах, не обязательно упорядоченных по смещению, то это будет более сложная конструкция. А у вас как раз предлагается сделать пустую секцию, в которой значащей будет только ее имя, не видное через program header. В общем местечковые конструкции на уровне формата ELF мне не нравятся. Проще добавить куда надо исключение типа 'syslinux.*\.c32\t'. 184573 40 legion 2019-09-25 11:13:49 +0300 (In reply to comment #39) > В общем местечковые конструкции на уровне формата ELF мне не нравятся. Проще > добавить куда надо исключение типа 'syslinux.*\.c32\t'. Если Диме нравится такой подход, то я только за. Вот только у нас уже не только syslinux, но и extlinux и grub2. Но в целом, тоже решение. 184575 41 ldv 2019-09-25 11:34:17 +0300 Коллеги, извините, я беру паузу до конференции в Калуге в конце этой недели. 184577 42 nickel 2019-09-25 12:09:18 +0300 (В ответ на комментарий №40) > (In reply to comment #39) > > В общем местечковые конструкции на уровне формата ELF мне не нравятся. Проще > > добавить куда надо исключение типа 'syslinux.*\.c32\t'. > > Если Диме нравится такой подход, то я только за. Вот только у нас уже не только > syslinux, но и extlinux и grub2. Но в целом, тоже решение. Ну, вообще, syslinux и extlinux - теперь суть один проект. grub2 от этого вообще в стороне, по крайней мере пока, - у них модульность держится на своих скриптах формирующих списки зависимостей и рассовывающих их по своим придуманным секциям и своем же динамическом загрузчике: 6 .moddeps 00000025 00000000 00000000 000038a0 2**0 CONTENTS, READONLY 7 .modname 00000006 00000000 00000000 000038c5 2**0 CONTENTS, READONLY ELF у grub2 типа REL, а не DYN и rpmelfsyms их игнорирует. 184578 43 legion 2019-09-25 12:25:15 +0300 (In reply to comment #42) > Ну, вообще, syslinux и extlinux - теперь суть один проект. Код один, а расположение файлов разное, как и назначение. Поэтому exclude нужно делать по разным путям. Меня устраивает и текущее положение вещей с исключением для /boot. Если вы помните в 37213#c3 мы говорили про общее решение. Exclude я таким не считаю, но всё же это решение, если секции чота парсить неохота. > ELF у grub2 типа REL, а не DYN и rpmelfsyms их игнорирует. Ok. Одним меньше. 184579 44 nickel 2019-09-25 12:42:14 +0300 (В ответ на комментарий №36) > Кстати когда ld.so откупоривает эльфа, то он смотрит у него какой-то ABI tag, в > котором по идее зашита минимальная версия ядра, но вроде еще какие-то поля > есть. Может туда прописать что-нибудь неприличное? Лучше конечно > кросс-дистрибутивное решение выработать. >[...] > Загрузчику тоже неохота парсить секции. Когда он ищет секцию .note.ABI-tag, то > он на самом деле не видит имени секции, а только видит PT_NOTE и дальше смотрит > что там внутри. Секцию .note.ABI-tag нашел только у запускаемых бинарников. У DSO такой секции нет. Но наткнулся на вот такие #definе'ы #define ELFOSABI_NONE 0 #define ELFOSABI_LINUX 3 коих уже достаточно много: https://ru.wikipedia.org/wiki/Executable_and_Linkable_Format и подумалось, почему бы не предложить еще одно значение добавить в enum, раз ELF становится популярным в стане загрузчико-писателей. А по этому значению в заголовке отсекать код имеющий право исполнятся в работающей системе от неимеющего. Опять же странно: неужели проверку на bad_elf_symbols осуществляет только сборочница в Sisyphus? У остальных дистрибутивов "и так сойдет"? 6й syslinux есть как минимум в Arch, Fedora, Debian... 184581 45 legion 2019-09-25 13:22:49 +0300 (In reply to comment #44) > Секцию .note.ABI-tag нашел только у запускаемых бинарников. У DSO такой секции > нет. > Но наткнулся на вот такие #definе'ы > > #define ELFOSABI_NONE 0 > #define ELFOSABI_LINUX 3 Да, у них они есть и действительно они нигде не проверяют EI_OSABI. > и подумалось, почему бы не предложить еще одно значение добавить в enum, раз > ELF становится популярным в стане загрузчико-писателей. А по этому значению в > заголовке отсекать код имеющий право исполнятся в работающей системе от > неимеющего. Вот только это чистейший abuse EI_OSABI. Это поле не имеет отношения к стадии выполнения. Теперь моя очередь сказать: В общем местечковые конструкции на уровне хэдера ELF мне не нравятся. 184582 46 ldv 2019-09-25 13:43:37 +0300 (In reply to comment #39) > Загрузчику тоже неохота парсить секции. Когда он ищет секцию .note.ABI-tag, то > он на самом деле не видит имени секции, а только видит PT_NOTE и дальше смотрит > что там внутри. OK, давайте запишем, например, __ABI_TAG_OS == -1 в .note.ABI-tag, так даже проще - ld.so не надо будет трогать. 184583 47 nickel 2019-09-25 14:24:39 +0300 Написал в рассылку upstream'а. Может быть когда-нибудь узнаем их мнение на счет того, что ELF'ы неразличимы. 184584 48 legion 2019-09-25 14:54:40 +0300 (In reply to comment #46) > OK, давайте запишем, например, __ABI_TAG_OS == -1 в .note.ABI-tag, так даже > проще - ld.so не надо будет трогать. Ок. Значит abuse. 192789 49 zerg 2020-09-23 17:34:20 +0300 Как всегда, смотрите в SuSE https://build.opensuse.org/package/show/openSUSE:Factory/syslinux6 . У них, кстати, syslinux-6.03.99+20171123 . 250883 50 nickel 2024-08-30 10:36:14 +0300 Проблема потеряла для меня актуальность с переходом на grub. Если станет актуальной для модулей в виде ELF-файлов другого проекта - переоткройте.