[syslinux] syslinux-5.xx+ modules' ELF files may be mistreated as system DSO

[Nikolai Kostrigin]

Hi!

Nowadays Syslinux uses regular dynamically linked ELF files as it's
modules:

[...]

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

The pros are obviously explained. But this causes some side effects.
Those modules may be erroneously treated as system DSOs.
 
libcom32.c32 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x9860
  Start of program headers:          64 (bytes into file)
  Start of section headers:          186720 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         3
  Size of section headers:           64 (bytes)
  Number of section headers:         19
  Section header string table index: 18

Linux binary packages' repositories build system may check provides and
dependencies of such ELF files forming list of "bad ELF symbols" which
cannot be resolved system wide for future package management according
to undefined symbols specified in such module files. As the code of
bootloader module is not intended to be executed in the running system
symbols provided by lib*.c32 should not be considered as provides and
linking to such ELFs should not be done for GNU/Linux system components.
But there is no way to distinguish DYN ELF built as regular DSO and DYN
ELF built for bootloader, except, may be, by the packaging path which is
not a secure method at all. So I'm wondering whether this behavior is
considered to be a problem by someone else except me? Are there any
plans or thoughts how the situation could be solved in future by
Syslinux developers? May be I'm missing some peculiarity of *.c32 ELF
files which could be used to distinguish them from regular DSO? Any info
or opinion would be appreciated. Thanks.

-- 
Best regards,
Nikolai Kostrigin