[devel] Ограничения сборочницы для virtualbox-6.1.14 и выше
Ivan A. Melnikov
iv на altlinux.org
Вт Дек 29 14:07:47 MSK 2020
On Mon, Dec 28, 2020 at 11:39:03PM +0300, Alexey V. Vissarionov wrote:
> On 2020-12-28 18:01:26 +0300, Dmitry V. Levin wrote:
>
> > Из этого описания мне не стало понятно, из какого именно
> > рассмотрения и что именно нужно исключать. Есть ли вероятность,
> > что эти файлы могут запровайдить какие-то символы и тем самым
> > исказить проверку для других пакетов?
>
> Сделай проверку только для Linux ELF - не ошибешься. Остальную
> блобятину можно считать данными.
Было бы здорово, если бы Linux ELF можно было бы как-то формально
отличить от не-Linux ELF. Опираться для этого на поле EI_OSABI
(на которое и смотрит команда file, когда выдаёт своё SYSV или
Linux), к сожалению, ошибочно.
Загрузчик ELF'ов в Linux'е традиционно принимает ELF'ы
с двумя типами этих самых OSABI: ELFOSABI_NONE (SYSV это
alias на него) и ELFOSABI_GNU (ELFOSABI_LINUX это алиас
на него); похоже, загрузчик не делает различий между ними.
Компоновщик же (который GNU ld, из состава binutils) ELF'ам,
которые он собирает, по умолчанию выставляет OS ABI
в ELFOSABI_NONE, и использует ELFOSABI_GNU только если в полученом
ELF'е используются какие-то особенные GNU-тые расширения,
а точнее "STT_GNU_IFUNC symbol type or STB_GNU_UNIQUE binding".
Таких меньшинство, и это технически правильно. Вот прямо
сейчас у меня:
$ file /usr/lib64/*.so.* | grep ELF | grep SYSV | wc -l
1258
$ file /usr/lib64/*.so.* | grep ELF | grep GNU/Linux | wc -l
210
То есть, эти буквы в скобках -- не предназначение, а особенности
формата. Причём, что интересно, GNU binutils и glibc в коде
используют ELFOSABI_NONE и ELFOSABI_GNU и похоже так к ним
и относятся, а все readelf, file и сотоварищи в human-readable
выводе пишут SysV или Linux. Не дайте себя запутать)
--
wbr,
iv m.
Подробная информация о списке рассылки Devel