[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