andy_shev Jun 4 2015 at 15:21

Сказ об одной ошибке, так и не попавшей в релиз ядра Linux

3 min

28K

System Programming*

+41

Comments 46

foxin Jun 4 2015 at 15:57

А как вообще тестируются коммиты в ядро линукса?

no111u3 Jun 4 2015 at 16:22

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

andy_shev Jun 4 2015 at 16:25

Отличный вопрос! На самом деле помимо разрозненных девелоперских тестов и тестов различных команд / подсистем (например, mmtests) существует проект 0-day kernel test. Подробнее можно почитать здесь: lwn.net/Articles/514278.

no111u3 Jun 4 2015 at 16:28

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

andy_shev Jun 4 2015 at 18:58

Кстати, Intel продвигает Intel® Processor Trace, которая при помощи Trace Hub позволит обойтись без этих баснословно стоящих устройств, если я правильно понимаю.

no111u3 Jun 4 2015 at 19:05

Ну да, т.к. помимо отладчика (который я видел только на картинках), нужна ещё и соответствующая мат-плата. Одна такая, правда под амд мне всё же попадалась, но скорее всего из-за задержки в релизе (выпустили дебаг версию, т.к. некогда было править рабочую версию).

jcmvbkbc Jun 4 2015 at 19:09

Обычным людям вполне хватает qemu.

no111u3 Jun 4 2015 at 19:12

Обычные люди не пишут настолько низкоуровневый код, что вызовы в нём ещё и надо согласовывать между собой.

no111u3 Jun 4 2015 at 19:23

Ну и да, qemu ну вот нисколько не предназначен для отладки ядра, равно как и другая виртуальная машина с «быстрой» симуляцией. Тут нужен полноценный эмулятор процессора и его окружения.

jcmvbkbc Jun 4 2015 at 19:38

qemu ну вот нисколько не предназначен для отладки ядра

Возможно вам тогда интересно будет узнать, что в течение трёх последних лет я разрабатываю и отлаживаю linux для xtensa преимущественно с помощью qemu. И могу сказать, что для подобных чисто софтверных багов он подходит отлично. А кроме того, «быстрая» симуляция не значит «плохая».

no111u3 Jun 4 2015 at 19:45

«быстрая» обозначает то что не все инструкции будут исполнятся также как и на реальном железе, с тем же отношением. Также большинство моделей процессоров и то что есть в qemu не сходятся по разным показателям. Никто не говорит что нельзя по qemu разрабатывать, но при этом не стоит забывать что это симулятор и то насколько он соответствует реальной модели не знает никто.
Поэтому без реального железа всё равно нельзя говорить что код исправен — типичный пример atmel: чередуя релизы разработчики ядра по очереди ломают одно из устройств, а точнее его драйвер.

jcmvbkbc Jun 4 2015 at 19:56

Ну вообще-то «быстрая» в контексте qemu обозначает, что используется бинарная трансляция совместно с разнообразными трюками для поддержки MMU, что быстрее наивной интерпретации.
На качество эмуляции эта быстрота не влияет, насколько точно поддерживать архитектуру решает разработчик.

насколько он соответствует реальной модели не знает никто

Знает как минимум человек, знакомый с железом и заглянувший в реализацию qemu. А ещё есть тесты.

no111u3 Jun 4 2015 at 19:58

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

jcmvbkbc Jun 4 2015 at 20:03

немного изменённое адресное пространство, которое работает не так, как реальный режим процессора

Расскажите поподробнее об изменённом адресном пространстве? И о том, что может помешать разработчику учесть эти изменения?

no111u3 Jun 4 2015 at 20:07

То что это не соответствует тому что он ожидает, и это мешает ему увидеть ошибки подобные описанной в статье.

jcmvbkbc Jun 4 2015 at 16:58

Какая-то недосказанность в этой истории: вроде уже С-код исполняется, функции вызываются. Что особенного в функции sprintf?
Исследований по поиску причин тоже не видно.

no111u3 Jun 4 2015 at 17:05

Особенного ничего нету, просто для части функций нету проекции virt-to-real. Поэтому адреса получившиеся после линковки оказались недействительными, в этом и вся ошибка.

jcmvbkbc Jun 4 2015 at 17:21

для части функций нету проекции virt-to-real

Да ладно.
Функции из arch/x86/boot можно звать, потому что они слинкованы по адресам реального режима, а остальные — нет, так?

no111u3 Jun 4 2015 at 17:28

Для экскурсии можете посмотреть System.map, в частности тому же spirntf отводится верхняя граница адресов в памяти (виртуальный адрес).

jcmvbkbc Jun 4 2015 at 18:04

System.map описывает vmlinux, там вообще ни одного адреса ниже 3G нет.
Тем не менее, код выполняется в реальном режиме и startup_32 вызывает load_ucode_bsp в реальном режиме.

c1ae13da T load_ucode_bsp

и это работает, как я понимаю, только потому что код position-independent.

no111u3 Jun 4 2015 at 18:15

Какая то часть да, в том числе и инициализация, загрузчик и распаковщик. Однако остальная часть кода имеет фиксированные адреса и точки входа. И после загрузки для них с помощью MMU меняется виртуальный адрес (для тех устройств где есть MMU).

jcmvbkbc Jun 4 2015 at 18:20

no111u3 «загрузчик» и «распаковщик» уже закончились к началу startup_32, MMU ещё не инициализирован на момент вызова load_ucode_bsp.
У меня был простой вопрос: «что особенного в sprintf», если вам не терпится ответить — ответьте пожалуйста на него.

no111u3 Jun 4 2015 at 18:29

/*
* Calculate the delta between where we were compiled to run
* at and where we were actually loaded at.
То что он вычислил куда прыгнуть, а вот несчастный sprintf он таким образом не может использовать, т.к. он был встроен при компиляции и вызов для него рассчитывался исходя из виртуальной адресации. Как говорится всё бы было хорошо, но адрес вызова sprintf который был подставлен виртуальный, и чтобы его преобразовать в реальный нужно знать об этом.

jcmvbkbc Jun 4 2015 at 18:59

Да ни при чём тут адрес вызова sprintf. Вызывается она нормально, это легко проверить.

no111u3 Jun 4 2015 at 19:01

Вызовется то да, да вот работать не будет нормально (т.к. внутри него адреса то другие).

jcmvbkbc Jun 4 2015 at 18:37

Сдаётся мне, ничего особенного в нём нет, и следующая замена скорее всего починила бы это место:

        sprintf(name, __pa_nodebug("intel-ucode/%02x-%02x-%02x"), family, model, stepping);

Но в целом, конечно, поддерживать этот код — это реальная жуть.

no111u3 Jun 4 2015 at 19:01

Ну лучше пока не сделали, да и не будут.

andy_shev Jun 4 2015 at 19:06

Вы невнимательно прочитали мой пост. параметры не имеют значения, я даже проверил ваше предположение — не работает. Проблема в самом символе sprintf.

jcmvbkbc Jun 4 2015 at 19:08

Я тоже проверил своё предложение. Действительно не работает.
Однако я точно попадаю в sprintf и дальше в vsprintf (по реальным адресам, разумеется). Дальше пока не смотрел.

jcmvbkbc Jun 4 2015 at 19:13

Ну и если вызывать strcpy то она вполне работает с такой заменой.

andy_shev Jun 4 2015 at 19:14

Будет интересно увидеть ваш анализ.

jcmvbkbc Jun 4 2015 at 19:31

Проблема из-за того, что компилятор реализовал switch в vsnprintf через таблицу переходов. Я вижу два вот таких стрёмных места:

c12b905b:       ff 24 85 54 c6 7f c1    jmp    *-0x3e8039ac(,%eax,4)
                        c12b905e: R_386_32      .rodata

Разумеется в .rodata абсолютные виртуальные адреса.
Может это место скомпилировать с -fPIC?

andy_shev Jun 4 2015 at 19:39

Процитирую Borislav'а: …even if we build the string properly, we choke later in get_builtin_firmware().
А так похоже, что это хорошее объяснение поведения sprintf().

jcmvbkbc Jun 4 2015 at 19:44

Это понятно, что весь этот код работает на честном слове, и даже если пофиксить здесь то повалится там.
Я реально удивлён что этот код никак не отделён от остального и не собирается как-то особенно. А например, начнёт завтра gcc все свитчи делать таблицами переходов…

no111u3 Jun 4 2015 at 19:47

Так никто и не рассчитывал что подобный код будет исполнятся из разных адресных пространств. Разбить на независимые модули — да, и ещё раз да. Но опять же необходимо проработать архитектуру, чтобы это работало.

KoCMoHaBT61 Jun 5 2015 at 15:45

Ну нифига себе! Это прямо жабство какое-то.
А как ещё надо свичи делать? Серией ifов?

jcmvbkbc Jun 4 2015 at 20:38

Немного подробностей:
вставляем sprintf в удобное место, я сделал так:

 void __init load_ucode_bsp(void)
 {       
         int vendor, family;
+        char str[100];
+        
+        sprintf(str, __pa_nodebug(":%d"), 1234);
         if (check_loader_disabled_bsp())
                 return;

конфигурируем ядро, включаем CONFIG_DEBUG_INFO и собираем ядро. Загружаем его в qemu:

$ qemu-system-i386 -kernel arch/x86/boot/bzImage -s -S

Запускаем gdb, загружаем символы, соединяемся с qemu:

$ gdb
(gdb) target remote :1235
Remote debugging using :1235
0x0000fff0 in ?? ()
(gdb) add-symbol-file vmlinux 0x1000000
add symbol table from file "vmlinux" at
        .text_addr = 0x1000000
(y or n) y
Reading symbols from /home/jcmvbkbc/ws/tensilica/linux/z/vmlinux...done.
(gdb) b sprintf
Breakpoint 1 at 0x12b9150: file /home/jcmvbkbc/ws/tensilica/linux/linux-xtensa/lib/vsprintf.c, line 2120.
(gdb) c
Continuing.

Breakpoint 1, sprintf (buf=<error reading variable: can't compute CFA for this frame>, fmt=<error reading variable: can't compute CFA for this frame>) at /home/jcmvbkbc/ws/tensilica/linux/linux-xtensa/lib/vsprintf.c:2120
....
1885                    switch (spec.type) {
1: x/10i $pc
=> 0x12b8e88 <vsnprintf+232>:   jmp    *-0x3e8039cc(,%eax,4)
(gdb) si
0x00000000 in ?? ()
1: x/10i $pc
=> 0x0: push   %ebx

В сессии gdb работает source-level отладка.

jcmvbkbc Jun 4 2015 at 20:46

target remote :1235 читать как target remote :1234.
qemu запущенный с -s ожидает gdb на порте 1234, чтобы перевесить gdbserver на другой порт вместо -s можно указать -gdb tcp::port

jcmvbkbc Jun 8 2015 at 17:11

Может это место скомпилировать с -fPIC?

Попробовал, не компилируется. Похоже из-за inline assembly или явного использования регистров.
Однако нашёл опцию -fno-jump-tables отключающую именно это поведение.

jcmvbkbc Jun 4 2015 at 20:20

Множество разработчиков тестирует свой код не на реальных машинах, а в виртуальных, с помощью того же QEMU. Так вот там всё прекрасно работает.

Двусмысленно. sprintf вызванный из реального режима там точно так же падает. Т.е. «не работает». Т.е. qemu достаточно точно эмулирует для воспроизведения и отладки этого бага (до свитча реализованного таблицей я дошёл как раз в qemu). Т.е. «работает».

andy_shev Jun 4 2015 at 20:31

А как запускали QEMU? Я ему указал на ядро, initrd и командную строку. Запускается без проблем.

jcmvbkbc Jun 4 2015 at 20:44

Ответил выше. Конечно дерево tip я не собирал, просто вставил sprintf в загрузчик микрокода и походил по нему.

ilammy Jun 4 2015 at 22:58

Стиль гиперссылок выдаёт разработчика ядра, привыкшего к простому тексту.

KoCMoHaBT61 Jun 5 2015 at 08:13

#define GETASCII(a) a>9? a+'a': a+'\0'

char name[]=«intel-ucode/00-00-00»;
char b;

b=family>>8;
name[12]=GETASCII(b);
b=family & 0x0F;
name[13]=GETASCII(b);

b=model>>8;
name[15]=GETASCII(b);
b=model & 0x0F;
name[16]=GETASCII(b);

name[19]=GETASCII(stepping);

KoCMoHaBT61 Jun 5 2015 at 08:20

Надо-же, облажался… :(

andy_shev Jun 5 2015 at 11:24

Причём функция преобразования доступна, вот я рассказывал здесь: habrahabr.ru/post/252453 (см. главу Бонусы). И предложенное мной исправление в этом же состояло. :-)