[devel] verify_elfsym

[devel] verify_elfsym

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 71 bytes --]

Вот упрощенная реализация проверки ELF'ов, как я её себе представляю.

[-- Attachment #1.2: verify_elfsym --]
[-- Type: text/plain, Size: 1313 bytes --]

#!/bin/sh -ef

elf1_undefined_symbols()
{
	local elf="$1" err=
	err="$(ldd -r "$elf" 2>&1 1>/dev/null)" || return
	[ -n "$err" ] || return 0
	echo "$err" |awk '/^undefined symbol:/ {
		gsub("^[(]|[)]$", "", $NF)
		print $3 "\t" $NF
	}'
}

elf1_verify_strict()
{
	local elf="$1" err=
	err=$(elf1_undefined_symbols "$elf") || return 2
	[ -n "$err" ] || return 0
	echo "Error: $elf: undefined symbols" >&2
	echo "$err" >&2
	return 1
}

elf1_verify_relaxed()
{
	local elf="$1" symtab="$2" err=
	err=$(elf1_undefined_symbols "$elf") || return 2
	[ -n "$err" ] || return 0
	local rc=0 sym= obj=
	while IFS=$'\t' read -r sym obj; do
		if [ "$obj" != "$elf" ]; then
			echo "Error: $elf: undefined symbol: $sym ($obj)" >&2
			rc=1
		elif ! bloom -e "$sym" "$symtab"; then
			echo "Error: $elf: undefined symbol: $sym" >&2
			rc=1
		fi
	done <<<"$err"
	return $rc
}	

rc=0 symtab="$1"; shift
for elf; do
	type="$(file -b "$elf")"
	if [ -z "${type##*ELF*executable*dynamic*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ -z "${type##*ELF*shared*}" -a -z "${elf##*/lib/lib*.so*}" ]; then
		elf1_verify_strict "$elf" || rc=1
	elif [ -z "${type##*ELF*dynamic*}" -o -z "${type##*ELF*shared*}" ]; then
		elf1_verify_relaxed "$elf" "$symtab" || rc=1
	fi	
done
exit $rc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify_elfsym

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Wed, Sep 21, 2005 at 03:17:27PM +0400, Alexey Tourbin wrote:
> elf1_verify_strict()
> elf1_verify_relaxed()

> 	done <<<"$err"

Это башизм эквивалентен
	done <<__EOF__
$err
__EOF__

> rc=0 symtab="$1"; shift
> for elf; do
> 	type="$(file -b "$elf")"
> 	if [ -z "${type##*ELF*executable*dynamic*}" ]; then
> 		elf1_verify_strict "$elf" || rc=1
> 	elif [ -z "${type##*ELF*shared*}" -a -z "${elf##*/lib/lib*.so*}" ]; then
> 		elf1_verify_strict "$elf" || rc=1
> 	elif [ -z "${type##*ELF*dynamic*}" -o -z "${type##*ELF*shared*}" ]; then
> 		elf1_verify_relaxed "$elf" "$symtab" || rc=1
> 	fi	

Соответственно, у давилки может может быть 4 режима:

strict -- все ELF'ы проверяеются с помощью elf1_verify_strict
normal (default) -- выполняются проверки elf1_verify_strict или
	elf1_verify_relaxed, в зависимости от типа и пути ELF'ов
relaxed -- все ELF'ы проверяеются с помощью elf1_verify_relaxed
none -- ELF'ы не проверяются

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify_elfsym

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Wed, Sep 21, 2005 at 03:17:27PM +0400, Alexey Tourbin wrote:
> Вот упрощенная реализация проверки ELF'ов, как я её себе представляю.
> 	err="$(ldd -r "$elf" 2>&1 1>/dev/null)" || return

Я пришел к выводу, что `ldd -r' не очень хорошо подходит для этой
проверки.  Есть несколько проблем, связанных со спецификой проверки
в %buildroot.  В частности, ldd не позволяет "перебить" rpath.

Вот альтернативная реализация `ldd -r'.

RTLD=/lib/ld-linux.so.2
RTLD_libpath=/lib:/usr/lib:/usr/X11R6/lib

elf1_libpath()
{
	local elf="$1"
	local libpath="$RTLD_libpath"
	[ -z "$LD_LIBRARY_PATH" ] ||
		libpath="$LD_LIBRARY_PATH:$libpath"
	[ -z "$RPM_FINDPROV_LIB_PATH" ] ||
		libpath="$RPM_FINDPROV_LIB_PATH:$libpath"
	local info= rpath=
	info="$(objdump -p "$elf")" || return
	rpath="$(echo "$info" |awk '($1=="RPATH"){printf "%s:", $2}')"
	[ -z "$rpath" ] ||
		libpath="$rpath$libpath"
	if [ -n "$RPM_BUILD_ROOT" ]; then
		local BR_libpath= path= IFS=:
		for path in $libpath; do
			BR_libpath="$BR_libpath:$RPM_BUILD_ROOT$path"
		done
		libpath="${BR_libpath#:}:$libpath"
	fi
	[ "$libpath" = "$RTLD_libpath" ] ||
		echo "${libpath%%:$RTLD_libpath}"
}

elf1_ldd()
{
	local elf="$1" libpath=
	libpath="$(elf1_libpath "$elf")" || return
	LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_VERBOSE= \
		"$RTLD" --library-path "$libpath" --inhibit-rpath "$elf" "$elf"
}


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify_elfsym

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

On Wed, Sep 21, 2005 at 07:05:43PM +0400, Alexey Tourbin wrote:
> Я пришел к выводу, что `ldd -r' не очень хорошо подходит для этой
> проверки.  Есть несколько проблем, связанных со спецификой проверки
> в %buildroot.  В частности, ldd не позволяет "перебить" rpath.

> 	LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_VERBOSE= \
> 		"$RTLD" --library-path "$libpath" --inhibit-rpath "$elf" "$elf"

Такой механизм отключения rpath является не очень строгим, то есть не
рекурсивным.  Но если существовал бы способ отключить RPATH рекурсивно,
могли бы возникнуть новые проблемы.

Может, поставить вопрос ребром?  А именно, я утверждаю, что
в %buildroot'е нельзя абсолютно корректно проверить ELF'ы при помощи
динамического линкера, даже модифицируя его механизмы при помощи
переменных и опций.  Это связано с тем, что в %buildroot'е ELF'ы
находятся не на своём месте, и, находись они на своём месте, проверка
могла бы завершиться иначе.  Эту модальность всегда нужно иметь в виду,
когда речь идёт о проверках в buildroot'е.

Тем не менее, даже не будучи абсолютно корректной, проверка может быть
более или менее приемлемой для того, чтобы выполняться в %buildroot'е по
умолчанию.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: verify_elfsym

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

On Wed, Sep 21, 2005 at 08:57:37PM +0400, Alexey Tourbin wrote:
> Может, поставить вопрос ребром?  А именно, я утверждаю, что
> в %buildroot'е нельзя абсолютно корректно проверить ELF'ы при помощи
> динамического линкера, даже модифицируя его механизмы при помощи
> переменных и опций.

Логично.
А если модифицировать сам динамический линкер, добавив ему опций?
Действительно, что нам стоит?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify_elfsym

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Wed, Sep 21, 2005 at 09:16:01PM +0400, Dmitry V. Levin wrote:
> On Wed, Sep 21, 2005 at 08:57:37PM +0400, Alexey Tourbin wrote:
> > Может, поставить вопрос ребром?  А именно, я утверждаю, что
> > в %buildroot'е нельзя абсолютно корректно проверить ELF'ы при помощи
> > динамического линкера, даже модифицируя его механизмы при помощи
> > переменных и опций.
> 
> Логично.
> А если модифицировать сам динамический линкер, добавив ему опций?
> Действительно, что нам стоит?

Добавить опцию --buildroot?  Тогда для каждого ELF файла в зависимостях
(рекурсивно) стандартный механизм модифицируется следующим образом:
сначала предпринимается попытка загрузить файл $buildroot$file.  В
случае ENOENT загружается просто $file, как обычно.

Ну, это будет хак.  Плюс у rpm-build появится зависимость на хак.
Нужно подумать, как обосновать этот хак для включения в upstream.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: verify_elfsym

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

On Wed, Sep 21, 2005 at 09:57:50PM +0400, Alexey Tourbin wrote:
> Добавить опцию --buildroot?  Тогда для каждого ELF файла в зависимостях
> (рекурсивно) стандартный механизм модифицируется следующим образом:
> сначала предпринимается попытка загрузить файл $buildroot$file.  В
> случае ENOENT загружается просто $file, как обычно.

Хе-хе.  Здесь в игру вступают абсолютные симлинки...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: verify_elfsym

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Wed, Sep 21, 2005 at 09:57:50PM +0400, Alexey Tourbin wrote:
> On Wed, Sep 21, 2005 at 09:16:01PM +0400, Dmitry V. Levin wrote:
> > On Wed, Sep 21, 2005 at 08:57:37PM +0400, Alexey Tourbin wrote:
> > > Может, поставить вопрос ребром?  А именно, я утверждаю, что
> > > в %buildroot'е нельзя абсолютно корректно проверить ELF'ы при помощи
> > > динамического линкера, даже модифицируя его механизмы при помощи
> > > переменных и опций.
> > 
> > Логично.
> > А если модифицировать сам динамический линкер, добавив ему опций?
> > Действительно, что нам стоит?
> 
> Добавить опцию --buildroot?  Тогда для каждого ELF файла в зависимостях
> (рекурсивно) стандартный механизм модифицируется следующим образом:
> сначала предпринимается попытка загрузить файл $buildroot$file.  В
> случае ENOENT загружается просто $file, как обычно.

А ведь есть ещё ld.so.conf*

> Ну, это будет хак.  Плюс у rpm-build появится зависимость на хак.
> Нужно подумать, как обосновать этот хак для включения в upstream.

Без шансов.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]