#!/bin/bash --posix --verbose

выдаётся ошибка

/bin/bash: --posix --verbose: invalid option

в то время как в интерактивном режиме bash нормально запускается с такой комбинацией опций; более того, если в shebang’е оставить только одну из этих опций, то скрипт также запускается без ошибок.

Поначалу я предположил, что --posix запрещает опции, не определённые стандартом POSIX на sh. Но тогда попытка выполнить bash --posix --norc также приводила бы к ошибке, и конструкция #!/bin/bash --verbose --norc работала бы нормально, а это не так.

Пришлось разбираться более плотно. В bash (1) я вычитал следующее (выделение — моё):

If the program is a file beginning with #!, the remainder of the first line specifies an interpreter for the program. The shell executes the specified interpreter on operating systems that do not handle this executable format themselves. The arguments to the interpreter consist of a single optional argument following the interpreter name on the first line of the program, followed by the name of the program, followed by the command arguments, if any.

Т.е. в shebang можно задавать только один аргумент; кроме того, bash самостоятельно анализирует shebang и вызывает указанный интерпретатор только в случае, если система сама не может выполнить этот скрипт.

Сам файл передаётся на выполнение с помощью системного вызова execve (2) (это я вычитал в файле execute_cmd.c в исходном коде bash), в man-странице которого и разъясняется политика партии по поводу разбиения аргументов интерпретатора:

On Linux, the entire string following the interpreter name is passed as a single argument to the interpreter, and this string can include white space.

Таким образом, в самом первом примере у bash в argv оказывается не два аргумента --verbose и --norc, а один --verbose --norc, что и приводит к ошибке, и вина bash лишь в том, что он не разбивает свои аргументы на части, как это делает, например, Perl.

Причина такого странного поведения операционной системы (казалось бы, что сложного в том, чтобы просто разбить строку на части по пробелам или символам табуляции) описана, например, в этой дискуссии LKML или, более подробно, в письме Garance A Drosihn в рассылку freebsd-arch. Вкратце, если бы механизм механизм обработки shebang (в Linux — linux/fs/binfmt_script.c) передавал все аргументы интерпретатору, то для некоторых из них было бы затруднительно отделить аругменты интерпретатора от собственно аргументов вызываемого скрипта. По крайней мере, так было еще на заре развития Unix и с тех пор большая часть Unix-систем передаёт все аргументы как единую строку.

Linux version 2.6.24-19-generic (buildd@terranova) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Fri Jul 11 23:41:49 UTC 2008 (Ubuntu 2.6.24-19.36-generic)

Интересующихся смыслом vermagic отправляю к главе 2.8 The Linux Kernel Module Programming Guide и описанию опции --force-vermagic в man modprobe.

Vermagic незагруженного модуля, находящегося в текущем каталоге, можно узнать по команде modinfo ./module_name.ko (работает, даже если модуль собран для другой архитектуры, например, если мы работаем в i386, а модуль — для x86_64, и наоборот). С ядром такой фокус не пройдет: во-первых, ядро, как правило, находится в сжатом виде, а исходники ядра не всегда доступны; во-вторых, сжатое ядро представляет собой загрузчик и распаковщик, за которым следует собственно сжатый алгоритмом zlib vmlinux (вопреки распространенному мнению, bzImage — это не ядро, сжатое bzip’ом, а сжатое ядро, которое можно загружать в несвязанные между собой области памяти), и необходимо отделить сжатое ядро от загрузчика.

Решение нашлось на форуме CodeGuru.

Заголовок gzip начинается с байт 1f 8b 08 00, их и будем искать. По ссылке выше рекомендуют использовать команду od -A d -t x1 vmlinuz|grep "1f 8b 08 00", и в некоторых случаях это действительно помогает, однако, во-первых, остаётся много трудноалгоритмизируемой ручной работы (необходимо отсчитать количество байт от смещения первого байта в строке до начала собственно заголовка gzip); во-вторых, две части искомого фрагмента могут находиться в разных строках, как, например, в текущей версии generic-ядра Ubuntu:

0011376 00 fd f3 a4 fc 5e 81 c5 ff ff 0f 00 81 e5 00 00
0011392 f0 ff 8d 83 90 01 1d 00 ff e0 01 01 1d 00 1f 8b
0011408 08 00 26 a1 ac 48 02 03 ec 3a 6d 74 14 55 96 af
0011424 3b d5 49 77 e8 58 15 a7 5b 5b b6 19 1a 2d 30 19

В данном случае, чтобы вычислить актуальное смещение заголовка gzip, необходимо к смещению первого байта в строке (11392) прибавить еще 14 байт. Поэтому мы пойдём немного другим путём.

Как я уже писал ранее, в состав исходников ядра Linux входит программа binoffset, с помощью которой можно находить сколь угодно длинные последовательности байт в бинарном файле. Ей и воспользуемся, благо она присутсвует также и в пакете linux-headers в Ubuntu:

$ gcc -o binoffset /usr/src/linux/scripts/binoffset.c
$ /binoffset /vmlinuz 0x1f 0x8b 0x08 00 2>/dev/null
11406

Теперь «вытащим» из vmlinuz сжатое ядро и распакуем его:

$ dd if=/vmlinuz skip=11406 bs=1|gzip -d >vmlinux

В vmlinux уже можно искать нужные строки:

$ strings vmlinux |grep gcc
Linux version 2.6.24-19-generic (buildd@terranova) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed Aug 20 22:56:21 UTC 2008 (Ubuntu 2.6.24-19.41-generic)
%s version %s (buildd@terranova) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) %s

Как видно, получили почти то, что нам нужно. Теперь сократим все вышенаписанное в одну строчку:

(dd if=/vmlinuz skip=`./binoffset /vmlinuz 0x1f 0x8b 0x08 0x00` bs=1|gzip -d |strings|grep "^Linux version") 2>/dev/null

Оптимизацию и рефакторинг этой команды оставляю в качестве самостоятельной работы для читателей.

P.S. Примерно то же самое делает скрипт /usr/src/linux/scripts/extract-ikconfig, только нужно слегка его модифицировать, чтобы он выдавал не конфиг, а распакованное ядро, но мне было интересно изобрести очередной велосписед и разобраться самостоятельно :-)

В этом случае помогает выполнение команды «cd -» (после Ctrl+O, Ctrl+C, Enter, Ctrl+O), которая меняет каталог на предыдущий (т.е. в котором мы находились до первого Ctrl+O).

cd /usr/src/linux/scripts
gcc -o binoffset binoffset.c

После чего можно натравливать extract-iconfig на ядро:

scripts/extract-ikconfig /path/to/bzImage

#!/bin/bash
passwords_count=3
test $1 && echo $1 | grep -q ^[0-9]*$ && passwords_count=$1

words=/usr/share/dict/words
words_count=3
symbols=("," "*" "-" "(" ")" "_" '"' ',' ',')

# prepare words array
declare -a allwords
exec 10< $words
while read LINE <&10; do
    allwords[${#allwords[*]}]=$LINE
done

nwords=${#allwords[@]}

for ((k=0;$k<$passwords_count;k++));
do
    declare -a words_array
    for w in `seq 0 $words_count`; do
        words_array[${#words_array[*]}]=${allwords[$(($nwords*$RANDOM/32767))]}
    done

    passwd=${words_array[0]}
    for ((c=1;$c<${#words_array[@]}-1;c++));
    do
        symbol=${symbols[(($RANDOM*${#symbols[*]}/32767))]}
        passwd="${passwd}${symbol}${words_array[$c]}"
    done
    echo $passwd
    unset passwd
    unset words_array
done

На наше счастье, кое-кто (итальянец Giacomo Catenazzi) уже озаботился этой проблемой и в какой-то степени её решил. Встречайте: Linux Kernel Driver Database (LKDDb). Основная цель этого проекта, цитирую: «попытка построения понятной пользователю базы данных устройств и протоколов, известных ядру linux. База данных включает в себя цифровые идентификаторы железа, опции конфигурации ядра, необходимые для включения модуля в ядро, и названия модулей, получающихся на выходе. База составляется на основе исходников ядра и поэтому всегда актуальна»

На сайте представлен пример того, что получается в результате работы этого скрипта. Для каждой опции ядра указывается, поддержка каких PCI IDs добавляется в систему с включением этой опции, как называется результирующий модуль и от какой опции зависит. Например, вот страница, посвящённая упоминавшемуся в прошлой заметке драйверу sata_nv.

Но нас в первую очередь интересует собственно база данных, lkddb.list – текстовый файл относительно простого для парсинга формата, на основе которого и строится работа программы. Разобраться в формате не составляет никакого труда. Приведу лишь пример записей для неоднократно здесь упоминавшегося драйвера sata_nv:

lkddb module libata "NVIDIA SATA support" :: CONFIG_SCSI_SATA_NV :: drivers/scsi/Kconfig
lkddb module sata_nv "NVIDIA SATA support" :: CONFIG_SCSI_SATA_NV :: drivers/scsi/Kconfig
lkddb pci 10de .... .... .... 0101.. :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de .... .... .... 0104.. :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 0036 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 003e .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 0054 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 0055 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 008e .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 00e3 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 00ee .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 0266 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 0267 .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 037e .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c
lkddb pci 10de 037f .... .... ...... :: CONFIG_SCSI_SATA_NV CONFIG_SCSI :: drivers/scsi/sata_nv.c

Все строки в этом файле начинаются с lkddb; далее следует тип записи: pci, usb, ieee1394, eisa, pcmcia и т.д. для устройств, i2c, platform, fs или module для различной информации, связанной с самим ядром. Далее для pci-устройств идут device id, vendor id, device class; затем, через разделитель «::», опция ядра, которую нужно включить для того, чтобы данный модуль скомпилировался, а также опции, от которой зависит данная опция; и, наконец, файл, в котором был найден данный pci id.

lkddb.list может быть сгенерирован с помощью генератора, который, собственно, и является ядром программы. Нужно скачать последнюю версию, распаковать, указать в Makefile путь к исходникам своего ядра; для экономии 500 килобайт трафика можно в этот же каталог скопировать из /usr/share/hwdata файлы pci.ids и usb.ids, после чего выполнить команду make откинуться на спинку кресла и подождать две-три минуты, пока парсятся немаленькие исходники и генерируется БД. Возможно, потребуется еще кое-что подпилить напильником, в зависимости от ситуации.

После дюжины экранов отладочных сообщений будет создан нужный нам файл lkddb.list и, в качестве бонуса, около 35 мегабайт описаний модулей в формате HTML в папке web-lkddb. До создания HCL остаётся полтора шага, не составляющих проблемы для знакомых с основами shell-программирования — из конфигурационного файла ядра нужно извлечь список всех включённых опций и для каждой скопировать информацию из lkddb.list, попутно преобразовав PCI ID устройства (в процессе работы скриптов преобразованного в более читаемую форму) к человекочитаемому виду.

Следите за обновлениями :)