FATAL: kernel too old

> Subj -- кто такой умный? libc?

больше некому.

_возможная_ причина в том, что эта libc скомпилирована
так, чтобы вызывать syscall только с помощью sysenter
(без отката на старый добрый "int 80").

хотя аллах знает, что они там делают. например, я заметил
случайно, что невинный fork() вызывает clone(... | CLONE_PARENT_SETTID)
(на хрена???), так что, конечно, нужно проверить, что
ядро достаточно новое, чтобы это работало.

вот из-за такой вот фигни я все чаще в тестах/эксплойтах
пишу что-нибудь вроде syscall(__NR_exit, 0).

>я заметил случайно, что невинный fork() вызывает clone

тык все правильно, man fork:
Under Linux, fork is implemented using copy-on-write pages, so the only penalty incurred by fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.

>--- SIGSEGV (Segmentation fault) --- >+++ killed by SIGSEGV +++

>И что можно посоветовать автору программы (он только бинарники >дает, шароварная прога) чтобы такого не было -- какие-нибудь >ключики компиляции может быть?

по моемому это обычное топтание по памяти и как следствие сегфолт.

насколько я знаю strace в случае "FATAL: kernel too old" выглядит совершенно нетак.

на всякий случай:

[BusyBox] FATAL: kernel too old
Mike Frysinger vapier at gentoo.org
Sun Jan 23 21:02:50 MST 2005

On Sunday 23 January 2005 05:09 am, Matthew East wrote:
> Can anyone tell me why I am getting this error?

stop trying to boot 2.4 kernels on libc's you build against linux-2.6 headers
-mike

хотя ещё раз подчеркну - меня терзают большие сомнения что мы здесь имеем именно эту ситуацию

>>я заметил случайно, что невинный fork() вызывает clone

>тык все правильно, man fork:

>Under Linux, fork is implemented using copy-on-write pages, so the only penalty incurred by fork is the time and memory required to duplicate the parent's page tables, and to create a unique task structure for the child.

ты хоть сам понял что сказал??

hint:ответ не в тему

2idle:

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

На самом деле, речь идет об уникальной проге, которую ничем не заменить. Автор (профессор математики, BTW) ее накарябал на Паскале для Маков, потом его заставили ее перенести на прочие платформы, ему помогли, и до последнего времени он ее раздавал как shareware в бинарниках. Но последние две версии вот такой вот проблемой застрадали...

Может, дашь какой совет? Я с автором в тесном контакте, он меня, может, послушает...

> Слушай, мне очень важно донести до автора проги способ побороть сие явление.

Если уж прямо так важно, то почему бы не заглянуть в файл dl-osinfo.h исходников glibc?

Там описан макрос, ответственный за проверку версии ядра.

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

2anonymous (*) (30.01.2006 14:36:13):

Thanks,

Собственно, про это и был вопрос.

> ...вероятно, можно найти ответ на заданный вопрос.

А нельзя поделиться готовыми решениями?

хм.

по моемому пост

(28.01.2006 11:16:34)

содержал решение вашей проблемы.

тоесть вам надо приложение статически слинковать с libc скомпиленой для ядра 2.4.

сейчас вы запускаете приложение слинкованое с libc собраной для ядра 2.6

PS. Там ещё есть траблы.!!!! не та сборка libc не должна валить приложение в сегфолт!!!

2cvv :

> вам надо приложение статически слинковать с libc скомпиленой для ядра 2.4.

Увы, не я автор программы.

Я могу только _посоветовать_ автору проги, что делать. Например, ключик для компиляции проги, или (вряд ли он меня послушает, конечно) как собрать подходящую libc.

У меня нет готового решения, однако проблема кажется тривиальной.

При запуске configure для сборки glibc нужно указать параметр --enable-kernel=X.Y.Z, где X.Y.Z - самое младшее ядро, которое будет поддерживать данная сборка glibc.

glibc от системы с ядром 2.4.х уже обладает этим свойством и совет cvv использовать такую glibc представляется вполне разумным. Другое соображение, высказанное cvv, про неожиданность падения по SIGSEGV, также кажется обоснованным.

Никакого магического ключа компиляции, насколько я понимаю, быть не пожет, потому как код проверки включен в библиотеку и "размазан" по ней.

Вероятно, наиболее простым советом автору программы будет использование другого компилятора, который, скорее всего, имеется на его системе (напр. в Fedora Core 4 включен gcc 3.2 для сборки тех приложений, которые не удается собрать новым gcc).

хм.

1)найти _бинарный_ пакет для его дистра с собраной подходящей libc (скомпиленой для 2.4) или позаимствовать из другого дистра (например с той же слаки).

2)развернуть в каталоге проэкта в каталог libc_new

3)статически подлиноковать при помощи ключей gcc типа

-static -L $(top_project_dir)/libc_new -lc

ну _возможно_ ещё придётся принудительно выключить линковку с /lib/libc.so OR /usr/lib/libc.a

2anonymous (*) (30.01.2006 16:49:25):

Thanks,

> ...однако проблема кажется тривиальной.

Всякая проблема кажется тривиальной, если знаешь решение :)

Собственно, я все перечисленные советы и пошлю автору.

2cvv (30.01.2006 17:52:19):

Thanks,

Проблема линковки c "левой" libc мне хорошо знакома и не сводится просто к описанным 3 пуктам. К сожалению, вряд ли автор программы станет это делать...

пол-года назад делал такое на SCO. особой сложности не заметил хотя какието нюансы были

> Может, дашь какой совет?

Сори, не знаю что посоветовать, все разумное уже вроде
сказали.

линковать со старой libc это (теоретически) тоже небезопасно,
нужно перекомпилировать с include'ами от этой версии библиотеки.

я думаю у тебя будет больше шансов запустить эту программу если
он выложит бинарник с динамической линковкой: есть LD_PRELOAD,
можно попытаться убрать VERNEED record.

Распространять объектные файлы программы и линковать с системной libc при инсталяции. Такой вариант рассматривался?

2idle:

> линковать со старой libc это (теоретически) тоже небезопасно,
нужно перекомпилировать с include'ами от этой версии библиотеки.

Конечно, но этого мало -- надо еще и саму эту старую версию
пересобрать тем же компилятором, иначе большой риск напороться
на какую-нибудь багофичу gcc.

> ...если он выложит бинарник с динамической линковкой...

А он его выкладывает! Только там сразу  version GLIBC... not found.
Как это отловить через LD_PRELOAD, я не представляю:
$ltrace -S ./proga
. . .
SYS_open("/lib/libc.so.6", 0, 027777763350)      = 4
SYS_read(4, "\177ELF\001\001\001", 1024)         = 1024
SYS_fstat64(4, 0xbfffe73c, 0x40012a90, 15, 0xbfffe73c) = 0
SYS_mmap2(0, 0x11d9c0, 5, 2, 4)                  = 0x4004e000
SYS_mprotect(0x40162000, 39360, 0, 0xbfffe620, 0xbfffe650) = 0
SYS_mmap2(0x40162000, 24576, 3, 18, 4)           = 0x40162000
SYS_mmap2(0x40168000, 14784, 3, 50, -1)          = 0x40168000
SYS_close(4)                                     = 0
SYS_writev(2, 0xbfffe97c, 6, 6, 2proga: /lib/libc.so.6: version \
`GLIBC_2.3' not found (required by proga)
. . .
то есть, подменять нечего.

Да и если суметь ее обмануть, скорее всего, сразу засегфолтится на
чужой libc...

2amm:

> Распространять объектные файлы программы и линковать с системной libc при инсталяции.

Ну, во-первых, скорее всего, сглючит.

А во-вторых, это для автора слишком сложно. Он вообще на Маке работает!

> А он его выкладывает! Только там сразу  version GLIBC... not found.
> Как это отловить через LD_PRELOAD, я не представляю:

нет, нужно удалить VERNEED из exe, я так делал. сейчас
мало что могу про это вспомнить, может, завтра что-нибудь
и смогу к вечеру.

> Да и если суметь ее обмануть, скорее всего, сразу засегфолтится на
> чужой libc...

конечно, это хак, и небезопасный. но, как говорил товарищ
Берия ...

а автора точно нельзя убедить дать исходники?

>Только там сразу version GLIBC... not found.

ну так и возьми glibc 2.3 c его дистра и подсунь этой проге через LD_PRELOAD

ну мож быть придётся пересобрать для своего ядра. по моемому вероятность что поедет ~95%

2cvv:

> ну так и возьми glibc 2.3 c его дистра и подсунь этой проге через LD_PRELOAD

Не все так просто :(

1. Я ж не для себя, у меня-то подходящих машин под рукой вдоволь. Просто коллеги задолбали. Далеко не все знают даже что такое libc.

2. Я просто пример привел, со старой версией. Автор же статический бинарь дает, ему LD_PRELOAD не нужен. Проблема в новых версиях программы, которые FATAL на ядро ругаются.

> а автора точно нельзя убедить дать исходники?

Пробовали, не получается :(

>Автор же статический бинарь дает,

так вы же говорили что доступны и динамические сборки

или какая-то версия не имеет динамической сборки?

ну тогда вашим колегам в руки UML или WMware

Ok, сеанс черного хакинга, после прочтения сжечь!

$ ls -l /lib/libc.so.6
lrwxrwxrwx   1 root     root           13 Dec 10  2002 /lib/libc.so.6 -> libc-2.1.2.so

$ ./ls
./ls: /lib/librt.so.1: version `GLIBC_2.2' not found (required by ./ls)
./ls: /lib/libc.so.6: version `GLIBC_2.2.3' not found (required by ./ls)
./ls: /lib/libc.so.6: version `GLIBC_2.1.3' not found (required by ./ls)
./ls: /lib/libc.so.6: version `GLIBC_2.2' not found (required by ./ls)

$ readelf -d ./ls

Dynamic segment at offset 0xa9c0 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8048f60
 0x0000000d (FINI)                       0x804f950
 0x00000004 (HASH)                       0x8048128
 0x00000005 (STRTAB)                     0x8048890
 0x00000006 (SYMTAB)                     0x8048380
 0x0000000a (STRSZ)                      836 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x8053aa0
 0x00000002 (PLTRELSZ)                   560 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048d30
 0x00000011 (REL)                        0x8048cf8
 0x00000012 (RELSZ)                      56 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x8048c78   <------- 17 от начала
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x8048bd4
 0x00000000 (NULL)                       0x0

$ objdump -h ./ls | fgrep .dynamic
 16 .dynamic      000000d0  080539c0  080539c0  0000a9c0  2**2
                                                   ^
                                                   |
                                             смещение в файле

$ dd if=/dev/zero conv=notrunc bs=1 of=./ls count=4 seek=$((0x0000a9c0+17*8))
4+0 records in
4+0 records out

$ ./ls
./ls: error in loading shared libraries: ./ls: undefined symbol: __cxa_atexit

$ echo "void __cxa_atexit(void) {}" > T.c
$ cc -fpic -shared -o T.so T.c

$ LD_PRELOAD=./T.so ./ls
               txt  txt~

Почти работает :)

2idle :

:)

Интересно, за такое в Штатах могут посадить?

2idle :

Кстати, а нельзя ли подобным образом убрать проверку версии ядра? Например, вместо uname подсунуть что-то другое, дописанное куда-нибудь прямо в бинарь, как это вирусы делают?

> вместо uname подсунуть что-то другое,
> дописанное куда-нибудь прямо в бинарь,
> как это вирусы делают?

да можно конечно, только уметь надо. я не умею.

ну так как, получилось запустить или нет?

2idle:

> ну так как, получилось запустить или нет?

Пробую обязательно, но сейчас возиться некогда. Я-то искал некий простой универсальный вариант, чтобы посоветовать автору программы. Лично я могу в любой момент зайти на другую машину на кластере, с ядром поновее, моя домашняя директория отовсюду видна.