(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

Может, чем хакать файлы загрузчика, лучше добавить исключения для данных файлов?

предлагаю спросить это у ментейнера сборочницы.

(В ответ на комментарий №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 все еще актуален...

(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 все еще актуален...

Мы же именно для этого хотим добавить новую секцию, верно?

(In reply to comment #4)
> Мы же именно для этого хотим добавить новую секцию, верно?

Да, было бы круто их отличать и люто карать!

(В ответ на комментарий №5)
> Да, было бы круто их отличать и люто карать!

Люто - это научить ldd этих эльфов не есть?

(In reply to comment #6)
> Люто - это научить ldd этих эльфов не есть?

Скорее ld.so. Добавил ".boot.code" и хрен в системе выполнишь без дополнительных телодвижений.

(In reply to comment #7)
> (In reply to comment #6)
> > Люто - это научить ldd этих эльфов не есть?
> 
> Скорее ld.so. Добавил ".boot.code"

Почему именно ".boot.code"?

(В ответ на комментарий №8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Люто - это научить ldd этих эльфов не есть?
> > 
> > Скорее ld.so. Добавил ".boot.code"
> 
> Почему именно ".boot.code"?

Может быть из-за упоминания в комментарии 3 .boot.code.module?
Изначально логика была такая: побольше слов, чтобы избежать случайных пересечений в дальнейшем и то, что такую секцию с наибольшей вероятностью придется пришивать к ELF-файлам исполняющимся до запуска системы, а это будет скорее всего модуль загрузчика.

Я что-то упускаю?

(In reply to comment #8)
> Почему именно ".boot.code"?

Я взят то, что nickel@ предложил. Можно выбрать другое имя.

> Я что-то упускаю?

Вроде всё верно.

(In reply to comment #10)
> (In reply to comment #8)
> > Почему именно ".boot.code"?
> 
> Я взят то, что nickel@ предложил. Можно выбрать другое имя.

Давайте подумаем, какое имя лучше выбрать.

(In reply to comment #11)
> Давайте подумаем, какое имя лучше выбрать.

.presystem ?
.prekernel ?
.bootloader ?
.boottime ?

Когда нечего придумать - можно взять random. Его точно никто использовать не будет.
.yoongei6Hahshahgh6pais9cumeetohs1sie

По смыслу всё равно это понимать должны только скрипты.

Это точно про boot?

Если мы хотим некий относительно универсальный механизм,
чтобы dynamic linker и rpmelfsym "не видели" такие ELFы,
то это не только про boot.

(In reply to comment #14)
> Это точно про boot?
> 
> Если мы хотим некий относительно универсальный механизм,
> чтобы dynamic linker и rpmelfsym "не видели" такие ELFы,
> то это не только про boot.

Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться?

(В ответ на комментарий №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, но при этом не являющийся ни библиотекой или плагином, ни частью загрузчика...

(In reply to comment #16)
> (В ответ на комментарий №15)
> > (In reply to comment #14)
> > > Это точно про boot?
> > > 
> > > Если мы хотим некий относительно универсальный механизм,
> > > чтобы dynamic linker и rpmelfsym "не видели" такие ELFы,
> > > то это не только про boot.
> > 
> > Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться?
> 
> Мне видится, что да - не должны, но тогда надо понять, какие еще бинарные
> модули
> могут подпадать под "юрисдикцию" этого механизма, чтобы придумать более общее
> название.

Переформулирую вопрос: syslinux со своим необычным загрузчиком ELFов может использовать обычный dlopen или нет?  Я предполагаю, что нет.

> Скорее всего многие программы, реализующие систему расширений на базе т.н.
> plugin'ов, пользуются dlopen и им перекрывать доступ к нему нельзя.

Они используют обычный механизм, об этом речи не идёт.

Предлагаю подумать в строну имён вида .alt.ld.so.skip
где .alt - это наш альтовый префикс.

(In reply to comment #15)
> Кстати, вопрос, dlopen'ом эти файлы тоже не должны открываться?

Пока мы говорим о файлах в формате ELF, которые выполняются не в системе, а где-то ещё. В частности, в процессе загрузки до загрузки ядра. Исходя из этого ELF-файлы с этим признаком в идеале не должны обрабатываться никак в системе.

Собственно, название секции я предлагал исходя из этого.

Если хочется более общее название, то по сути этот признак будет отключать обработку этих файлов и только у нас в дистрибутиве.

.altlinux.ignored ?
.altlinux.unverified ?

(In reply to comment #13)
> Когда нечего придумать - можно взять random. Его точно никто использовать не
> будет.
> .yoongei6Hahshahgh6pais9cumeetohs1sie
> 
> По смыслу всё равно это понимать должны только скрипты.

Антон, это неудобно использовать в патчах. Хочется всё-таки осмысленное что-то.

(В ответ на комментарий №18)
> Предлагаю подумать в строну имён вида .alt.ld.so.skip
> где .alt - это наш альтовый префикс.

Ничего против не имею. Это будет отражать скорее механизм обработки, а не принадлежность какому-то классу программ.
Если других замечаний по
 http://git.altlinux.org/people/nickel/packages/?p=perl-qa-rpmelfsym.git;a=commit;h=e3038cc3481ef19080616f3fb0dbe5ac4e2dc442
не будет, то я переделаю с предложенным именем секции и пересоберу.

Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта, которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip

(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

(In reply to comment #21)
> Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта,
> которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip

Ну во-первых хочется не только игнорировать их в rpm проверках.
Ну и слово elf в ELF-хэдере кажется лишним )))

(В ответ на комментарий №23)
> (In reply to comment #21)
> > Если хочется осмысленное, тогда лучше назвать по имени приложения/скрипта,
> > которое будет эту настройку обрабатывать Например .alt.rpm.verify-elf.skip
> 
> Ну во-первых хочется не только игнорировать их в rpm проверках.

А где ещё ?

> Ну и слово elf в ELF-хэдере кажется лишним )))

Ок, убираем rpm и elf и получаем .alt.verify.skip

(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.

(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).

(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

(В ответ на комментарий №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 выставить.

(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 как удобным форматом. Не нужно портить каким-то образом эти файлы.

Антон, чтобы сократить количество вопросов вот выдержка из ченджлога проекта:

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

Лёш, спасибо. Так всё понятно.

(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 и проверять код возврата.

(В ответ на комментарий №32)

> 
> Думаю, что в коде лучше использовать objdump -h -j .alt.ld.so.skip и проверять
> код возврата.

Если больше не планируется проверять ELF-файл на наличие каких-то других секций, то да, такая адресная проверка не допускает разночтений. В текущей же реализации можно "сэкономить" на повторном вызове objdump если нужно более 1 сравнения.

(In reply to comment #33)
> (В ответ на комментарий №32)
> 
> > 
> > Думаю, что в коде лучше использовать objdump -h -j .alt.ld.so.skip и проверять
> > код возврата.
> 
> Если больше не планируется проверять ELF-файл на наличие каких-то других
> секций, то да, такая адресная проверка не допускает разночтений. В текущей же
> реализации можно "сэкономить" на повторном вызове objdump если нужно более 1
> сравнения.

Это понятно, но сейчас других сравнений не планируется.
Можно оставить комментарий о том, как лучше поступить в будущем,
если такие сравнения понадобится добавить.

Мужчины, у меня написан ELF-парсер на Си для новой реализации rpmelfsym, который парсит только program header и PT_DYNAMIC.  Секции чота парсить неохота.  А есть какие-нибудь другие косвенные признаки, по которым можно понять, что эльф левый?

Кстати когда ld.so откупоривает эльфа, то он смотрит у него какой-то ABI tag, в котором по идее зашита минимальная версия ядра, но вроде еще какие-то поля есть.  Может туда прописать что-нибудь неприличное?  Лучше конечно кросс-дистрибутивное решение выработать.

(In reply to comment #35)
> Секции чота парсить неохота.

Так себе аргумент.

> А есть какие-нибудь другие косвенные признаки, по которым можно
> понять, что эльф левый?

Когда мы с Димой пытались найти какие-нибудь признаки, то у нас это не получилось.
В сизифе есть пакет extlinux. Можешь попробовать понять, что в /boot/extlinux лежат левые бинарники ?

(В ответ на комментарий №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

Загрузчику тоже неохота парсить секции.  Когда он ищет секцию .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'.

(In reply to comment #39)
> В общем местечковые конструкции на уровне формата ELF мне не нравятся.  Проще
> добавить куда надо исключение типа 'syslinux.*\.c32\t'.

Если Диме нравится такой подход, то я только за. Вот только у нас уже не только syslinux, но и extlinux и grub2. Но в целом, тоже решение.

Коллеги, извините, я беру паузу до конференции в Калуге в конце этой недели.

(В ответ на комментарий №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 их игнорирует.

(In reply to comment #42)
> Ну, вообще, syslinux и extlinux - теперь суть один проект.

Код один, а расположение файлов разное, как и назначение. Поэтому exclude нужно делать по разным путям.

Меня устраивает и текущее положение вещей с исключением для /boot. Если вы помните в 37213#c3 мы говорили про общее решение. Exclude я таким не считаю, но всё же это решение, если секции чота парсить неохота.

> ELF у grub2 типа REL, а не DYN и rpmelfsyms их игнорирует.

Ok. Одним меньше.

(В ответ на комментарий №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...

(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 мне не нравятся.

(In reply to comment #39)
> Загрузчику тоже неохота парсить секции.  Когда он ищет секцию .note.ABI-tag, то
> он на самом деле не видит имени секции, а только видит PT_NOTE и дальше смотрит
> что там внутри.

OK, давайте запишем, например, __ABI_TAG_OS == -1 в .note.ABI-tag, так даже проще - ld.so не надо будет трогать.

Написал в рассылку upstream'а. Может быть когда-нибудь узнаем их мнение на счет того, что ELF'ы неразличимы.

(In reply to comment #46)
> OK, давайте запишем, например, __ABI_TAG_OS == -1 в .note.ABI-tag, так даже
> проще - ld.so не надо будет трогать.

Ок. Значит abuse.

Как всегда, смотрите в SuSE https://build.opensuse.org/package/show/openSUSE:Factory/syslinux6 .
У них, кстати, syslinux-6.03.99+20171123 .

Проблема потеряла для меня актуальность с переходом на grub.
Если станет актуальной для модулей в виде ELF-файлов другого проекта - переоткройте.