[Перевод] Статический анализ в GCC 10
Я работаю в Red Hat над GCC, GNU Compiler Collection. Для следующего основного релиза GCC, GCC 10, я реализовывал новую опцию -fanalyzer: проход статического анализа для выявления различных проблем во время компиляции, а не во время исполнения.
Я думаю, что лучше выявлять проблемы как можно раньше по мере написания кода, используя компилятор, как часть цикла компиляции-редактирования-отладки, а не использовать статический анализ в качестве дополнительного инструмента «на стороне» (возможно, проприетарного). Поэтому, представляется целесообразным иметь встроенный в компилятор статический анализатор, который видит код в точности такой же, какой видит компилятор — ведь это и есть компилятор.
Этот вопрос, конечно, является огромной проблемой, которую нужно решить. Для этого релиза я сконцентрировался на типах проблем, замеченных в коде на Си, и, в частности, на ошибках двойного освобождения (double-free), но с целью последующего создания фреймворка, который мы сможем расширить в последующих релизах (когда мы сможем добавить больше проверок и поддержку языков, отличных от Си).
Надеюсь, что анализатор обеспечивает приличное количество дополнительной проверки, при этом не являясь слишком накладным. Я стремился к тому, чтобы -fanalyzer «всего лишь» удвоил время компиляции в качестве разумного компромисса между дополнительными проверками. У меня пока не получилось, как вы увидите ниже, но я работаю над этим.
Сейчас код находится в основной ветке GCC для GCC 10 и может быть опробован в Compiler Explorer, он же godbolt.org. Он хорошо работает для малых и средних примеров, но есть ошибки, которые означают, что он не готов к промышленному использованию. Я усердно работаю над исправлениями в надежде, что к моменту выхода GCC 10 (скорее всего, в апреле) эта возможность будет эффективно применима для C-кода.
Пути диагностики
Вот самый простой пример ошибки double-free:
#include
void test(void *ptr)
{
free(ptr);
free(ptr);
}
GCC 10 с -fanalyzer сообщает об этом следующим образом:
$ gcc -c -fanalyzer double-free-1.c
double-free-1.c: In function ‘test’:
double-free-1.c:6:3: warning: double-‘free’ of ‘ptr’ [CWE-415] [-Wanalyzer-double-free]
6 | free(ptr);
| ^~~~~~~~~
‘test’: events 1-2
|
| 5 | free(ptr);
| | ^~~~~~~~~
| | |
| | (1) first ‘free’ here
| 6 | free(ptr);
| | ~~~~~~~~~
| | |
| | (2) second ‘free’ here; first ‘free’ was at (1)
|
Этот лог показывает, что GCC выучил несколько новых трюков; во-первых, возможность диагностики иметь идентификаторы Common Weakness Enumeration (CWE). В этом примере диагностика double-free помечена тегом CWE-415. Надеемся, что этот тег сделает вывод более понятным, повысит точность и даст вам что-то простое для ввода в поисковых системах. Пока что только диагностика от -fanalyzer маркируется идентификаторами уязвимости CWE.
Если Вы используете GCC 10 с подходящим терминалом (например, свежий gnome-terminal), то CWE-идентификатор — это гиперссылка, ведущая к описанию проблемы. Говоря о гиперссылках, для многих релизов, когда GCC выдает предупреждение, он печатает опцию, регулирующую это предупреждение. Начиная с GCC 10, этот текст опции теперь является гиперссылкой на щелчок (опять же, предполагая достаточно развитый терминал), что должно привести вас к документации по этой опции (для любого предупреждения, а не только для тех, которые относятся к анализатору).
Теперь диагностика GCC может иметь связанную с ними цепочку событий, описывающую путь через код, который инициирует проблему. Учитывая отсутствие потока управления в приведенном выше примере, у него есть только два события, но вы можете увидеть, как второе событие относится к первому в его описании.
Приведем более полный пример. Вы видите проблему в следующем коде? (Подсказка: на этот раз это не двойное освобождение):
#include
#include
static jmp_buf env;
static void inner(void)
{
longjmp(env, 1);
}
static void middle(void)
{
void *ptr = malloc(1024);
inner();
free(ptr);
}
void outer(void)
{
int i;
i = setjmp(env);
if (i == 0)
middle();
}
Вот что сообщает GCC -fanalyzer, который показывает межпроцедурный поток управления с помощью ASCII-вывода:
$ gcc -c -fanalyzer longjmp-demo.c
longjmp-demo.c: In function ‘inner’:
longjmp-demo.c:8:3: warning: leak of ‘ptr’ [CWE-401] [-Wanalyzer-malloc-leak]
8 | longjmp(env, 1);
| ^~~~~~~~~~~~~~~
‘outer’: event 1
|
| 18 | void outer(void)
| | ^~~~~
| | |
| | (1) entry to ‘outer’
|
‘outer’: event 2
|
| 22 | i = setjmp(env);
| | ^~~~~~
| | |
| | (2) ‘setjmp’ called here
|
‘outer’: events 3-5
|
| 23 | if (i == 0)
| | ^
| | |
| | (3) following ‘true’ branch (when ‘i == 0’)...
| 24 | middle();
| | ~~~~~~~~
| | |
| | (4) ...to here
| | (5) calling ‘middle’ from ‘outer’
|
+--> ‘middle’: events 6-8
|
| 11 | static void middle(void)
| | ^~~~~~
| | |
| | (6) entry to ‘middle’
| 12 | {
| 13 | void *ptr = malloc(1024);
| | ~~~~~~~~~~~~
| | |
| | (7) allocated here
| 14 | inner();
| | ~~~~~~~
| | |
| | (8) calling ‘inner’ from ‘middle’
|
+--> ‘inner’: events 9-11
|
| 6 | static void inner(void)
| | ^~~~~
| | |
| | (9) entry to ‘inner’
| 7 | {
| 8 | longjmp(env, 1);
| | ~~~~~~~~~~~~~~~
| | |
| | (10) ‘ptr’ leaks here; was allocated at (7)
| | (11) rewinding from ‘longjmp’ in ‘inner’...
|
<-------------+
|
‘outer’: event 12
|
| 22 | i = setjmp(env);
| | ^~~~~~
| | |
| | (12) ...to ‘setjmp’ in ‘outer’ (saved at (2))
|
Вышеизложенное довольно многословно, хотя, возможно, так это и должно быть для того, чтобы передать, что происходит, учитывая использование setjmp и longjmp. Я надеюсь, что описание достаточно понятно: происходит утечка памяти, когда вызов longjmp разворачивает стек обратно в outer мимо точки очистки в middle, не вызывая очистки.
Если вам не нравится ASCII-вывод, показанный выше, вы можете просматривать события как отдельную диагностику «ноты» при помощи -fdiagnostics-path-format=separate-events:
$ gcc -c -fanalyzer -fdiagnostics-path-format=separate-events longjmp-demo.c
longjmp-demo.c: In function ‘inner’:
longjmp-demo.c:8:3: warning: leak of ‘ptr’ [CWE-401] [-Wanalyzer-malloc-leak]
8 | longjmp(env, 1);
| ^~~~~~~~~~~~~~~
longjmp-demo.c:18:6: note: (1) entry to ‘outer’
18 | void outer(void)
| ^~~~~
In file included from longjmp-demo.c:1:
longjmp-demo.c:22:7: note: (2) ‘setjmp’ called here
22 | i = setjmp(env);
| ^~~~~~
longjmp-demo.c:23:6: note: (3) following ‘true’ branch (when ‘i == 0’)...
23 | if (i == 0)
| ^
longjmp-demo.c:24:5: note: (4) ...to here
24 | middle();
| ^~~~~~~~
longjmp-demo.c:24:5: note: (5) calling ‘middle’ from ‘outer’
longjmp-demo.c:11:13: note: (6) entry to ‘middle’
11 | static void middle(void)
| ^~~~~~
longjmp-demo.c:13:15: note: (7) allocated here
13 | void *ptr = malloc(1024);
| ^~~~~~~~~~~~
longjmp-demo.c:14:3: note: (8) calling ‘inner’ from ‘middle’
14 | inner();
| ^~~~~~~
longjmp-demo.c:6:13: note: (9) entry to ‘inner’
6 | static void inner(void)
| ^~~~~
longjmp-demo.c:8:3: note: (10) ‘ptr’ leaks here; was allocated at (7)
8 | longjmp(env, 1);
| ^~~~~~~~~~~~~~~
longjmp-demo.c:8:3: note: (11) rewinding from ‘longjmp’ in ‘inner’...
In file included from longjmp-demo.c:1:
longjmp-demo.c:22:7: note: (12) ...to ‘setjmp’ in ‘outer’ (saved at (2))
22 | i = setjmp(env);
| ^~~~~~
или вообще выключить их с помощью -fdiagnostics-path-format=none. Есть также формат вывода JSON.
Все новые диагностики имеют название вида -Wanalyzer-SOMETHING: Мы уже видели -Wanalyzer-double-free и -Wanalyzer-malloc-leak выше. Все эти диагностики включаются, когда включен -fanalyzer, но их можно выборочно отключить с помощью вариантов -Wno-analyzer-SOMETHING (например, с помощью прагм).
Какие новые предупреждения будут?
Наряду с детектированием double-free, проводятся проверки на утечки malloc и fopen:
#include
#include
void test(const char *filename)
{
FILE *f = fopen(filename, "r");
void *p = malloc(1024);
/* do stuff */
} $ gcc -c -fanalyzer leak.c
leak.c: In function ‘test’:
leak.c:9:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
9 | }
| ^
‘test’: events 1-2
|
| 7 | void *p = malloc(1024);
| | ^~~~~~~~~~~~
| | |
| | (1) allocated here
| 8 | /* do stuff */
| 9 | }
| | ~
| | |
| | (2) ‘p’ leaks here; was allocated at (1)
|
leak.c:9:1: warning: leak of FILE ‘f’ [CWE-775] [-Wanalyzer-file-leak]
9 | }
| ^
‘test’: events 1-2
|
| 6 | FILE *f = fopen(filename, "r");
| | ^~~~~~~~~~~~~~~~~~~~
| | |
| | (1) opened here
|......
| 9 | }
| | ~
| | |
| | (2) ‘f’ leaks here; was opened at (1)
|
Контроль использования памяти после ее освобождения:
#include
struct link { struct link *next; };
int free_a_list_badly(struct link *n)
{
while (n) {
free(n);
n = n->next;
}
} $ gcc -c -fanalyzer use-after-free.c
use-after-free.c: In function ‘free_a_list_badly’:
use-after-free.c:9:7: warning: use after ‘free’ of ‘n’ [CWE-416] [-Wanalyzer-use-after-free]
9 | n = n->next;
| ~~^~~~~~~~~
‘free_a_list_badly’: events 1-4
|
| 7 | while (n) {
| | ^
| | |
| | (1) following ‘true’ branch (when ‘n’ is non-NULL)...
| 8 | free(n);
| | ~~~~~~~
| | |
| | (2) ...to here
| | (3) freed here
| 9 | n = n->next;
| | ~~~~~~~~~~~
| | |
| | (4) use after ‘free’ of ‘n’; freed at (3)
|
Контроль освобождения указателя не на кучу (heap):
#include
void test(int n)
{
int buf[10];
int *ptr;
if (n < 10)
ptr = buf;
else
ptr = (int *)malloc(sizeof (int) * n);
/* do stuff. */
/* oops; this free should be conditionalized. */
free(ptr);
} $ gcc -c -fanalyzer heap-vs-stack.c
heap-vs-stack.c: In function ‘test’:
heap-vs-stack.c:16:3: warning: ‘free’ of ‘ptr’ which points to memory not on the heap [CWE-590] [-Wanalyzer-free-of-non-heap]
16 | free(ptr);
| ^~~~~~~~~
‘test’: events 1-4
|
| 8 | if (n < 10)
| | ^
| | |
| | (1) following ‘true’ branch (when ‘n <= 9’)...
| 9 | ptr = buf;
| | ~~~~~~~~~
| | |
| | (2) ...to here
| | (3) pointer is from here
|......
| 16 | free(ptr);
| | ~~~~~~~~~
| | |
| | (4) call to ‘free’ here
|
Контроль использования функции, которая, как известно, небезопасна для использования внутри обработчика signal:
#include
#include
extern void body_of_program(void);
void custom_logger(const char *msg)
{
fprintf(stderr, "LOG: %s", msg);
}
static void handler(int signum)
{
custom_logger("got signal");
}
int main(int argc, const char *argv)
{
custom_logger("started");
signal(SIGINT, handler);
body_of_program();
custom_logger("stopped");
return 0;
} $ gcc -c -fanalyzer signal.c
signal.c: In function ‘custom_logger’:
signal.c:8:3: warning: call to ‘fprintf’ from within signal handler [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler]
8 | fprintf(stderr, "LOG: %s", msg);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
‘main’: events 1-2
|
| 16 | int main(int argc, const char *argv)
| | ^~~~
| | |
| | (1) entry to ‘main’
|......
| 20 | signal(SIGINT, handler);
| | ~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) registering ‘handler’ as signal handler
|
event 3
|
|cc1:
| (3): later on, when the signal is delivered to the process
|
+--> ‘handler’: events 4-5
|
| 11 | static void handler(int signum)
| | ^~~~~~~
| | |
| | (4) entry to ‘handler’
| 12 | {
| 13 | custom_logger("got signal");
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (5) calling ‘custom_logger’ from ‘handler’
|
+--> ‘custom_logger’: events 6-7
|
| 6 | void custom_logger(const char *msg)
| | ^~~~~~~~~~~~~
| | |
| | (6) entry to ‘custom_logger’
| 7 | {
| 8 | fprintf(stderr, "LOG: %s", msg);
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (7) call to ‘fprintf’ from within signal handler
|
Наряду и с другими предупреждениями.
Что остаётся сделать?
В существующем виде проверка хорошо работает на малых и средних примерах, но есть две проблемные области, с которыми я сталкиваюсь при масштабировании до реального кода на Си.
Во-первых, в моем коде контроля состояний есть ошибки. Внутри чекера есть классы для абстрактного описания состояния программы. Чекер исследует программу, строя направленный граф пар (точка, состояние) с логикой упрощения состояния и слияния состояний в точках соединения потока управления.
Теоретически, если состояние становится слишком сложным, проверяющий должен перейти в наименее определенное состояние, но при таком подходе возникают ошибки, приводящие к взрыву числа состояний в заданной точке, что затем приводит к тому, что проверяющий работает медленно, в конце концов, достигая предела безопасности, и не исследует программу полностью. Чтобы исправить это, я переписал кишки кода управления состоянием. Надеюсь, что на следующей неделе перепишу master.
Далее, даже если мы полностью исследуем программу, пути через код, генерируемый анализатором -fanalyzer, иногда бывают абсурдно многословны. Самое худшее, что я видел, это путь из 110 событий для использования неинициализированных данных, сообщаемых при компиляции самого GCC. Я думаю, что это ложноположительное срабатывание, и очевидно, что неразумно ожидать от пользователей, что они пройдут через что-то подобное.
Анализатор пытается найти кратчайший возможный путь через граф (точка, состояние), генерирует из него цепочку событий, а затем пытается упростить эту цепочку. Фактически, он применяет серию peephole оптимизаций к цепочке событий, чтобы получить минимальную цепочку, которая демонстрирует проблему.
Недавно я реализовал способ фильтрации несущественных ребер потока управления из пути, который должен помочь, и работаю над аналогичным патчем для устранения избыточных межпроцедурных ребер.
В качестве конкретного примера я попробовал анализатор на реальной ошибке (пусть и пятнадцатилетней давности) -CVE-2005–1689, уязвимость double-free в krb5 1.4.1. Он корректно идентифицирует ошибку без ложных срабатываний, но на данный момент на выходе stderr 170 строк. Вместо того, чтобы показывать вывод в строке здесь, вы можете посмотреть его по этой ссылке.
Первоначально это было 1187 строк. Я исправлял различные ошибки и реализовывал больше упрощений, чтобы довести его до 170 строк. Частично проблема в том, что free выполняется с помощью макроса krb5_xfree, а код печати пути показывает, как каждый макрос расширяется каждый раз, когда происходит событие внутри макроса. Возможно, в выводе следует показывать расширение макроса только один раз за диагностику. Также первые несколько событий в каждой диагностике — это межпроцедурная логика, которая на самом деле неактуальна для пользователя (я работаю над исправлениями этого). С этими изменениями вывод должен быть значительно короче.
Может быть, лучший интерфейс мог бы выдавать отдельный HTML-файл, по одному на предупреждение, и выдавать «заметку» с указанием места расположения дополнительной информации?
Я хочу дать конечному пользователю достаточно информации о предупреждении, но не перегружая его. Есть ли лучшие способы представить это? Дайте мне знать в комментариях.
Как опробовать
GCC 10 появится в Fedora 32, которая должна выйти через пару месяцев.
Для простых примеров кода можно поиграться с новым GCC онлайн на godbolt.org (выберите gcc «trunk» и добавьте -fanalyzer в опции компилятора).
Удачи!
Далее добавлено переводчиком из форумов.
Dlang, комментарии Уолтера Брайта на Hacker News
Это соответствует продвижению [моей] идеи сделать для D по умолчанию @ safe, и реализовать систему Владения/Заимствования @ live.
Либо бы вскочим на этот автобус, либо он нас переедет.
Double-free’s можно отслеживать, выполняя анализ потока данных (DFA) в функции. Именно так D делает это в своей зарождающейся реализации системы владения/заимствования. Это можно сделать и без DFA, получив только 90% правильных результатов и имея множество ложных срабатываний.
В прошлом я использовал много статических чекеров, и процент ложных срабатываний был достаточно высок, чтобы отказаться от их использования. Вот почему D использует DFA, чтобы дать 100% положительных сигналов при 0% ложных срабатываний (Прим.пер. здесь имеется в виду, что все обнаруженные утечки — 100% утечки, а не то, что отлавливаются 100% всех возможных). Я знал, что это будет возможно, потому что компиляторы использовали DFA при проходе оптимизации.
Чтобы отслеживание заработало, нельзя просто отслеживать события для функции, называемой «free». В конце концов, обычное дело — писать свои собственные аллокаторы памяти, и компилятор не будет знать, что это такое. Следовательно, должен быть какой-то механизм, чтобы сообщить компилятору, когда параметр функции типа указатель «потребляется» вызываемой функцией, и когда он просто «одолжен» ей (отсюда и номенклатура системы «Владелец/заемщик»).
Одна из трудностей, которую можно преодолеть с помощью D, заключается в том, что существует несколько сложных семантических конструкций, которые необходимо разбить на их компонентные операции с указателями. Я заметил, что Rust упростил эту проблему, упростив язык:-).
Но как только это сделано, оно работает, и работает удовлетворительно хорошо.
Обратите внимание, что ничто из этого не является критикой того, что делает GCC 10, потому что в статье не хватает подробностей, чтобы сделать обоснованные выводы. Но я рассматриваю это как часть общей тенденции, что люди устали от ошибок безопасности памяти в языках программирования, и очень приятно видеть прогресс на всех фронтах.
Комментарий Тимона Гера для понимания D из форума обсуждения на Dlang.org
@ live не является системой владения/заимствования, хотя она действительно основывается на концепциях, связанных с владением и заимствованием.
Система собственности/заимствования навязывает семантику собственности в коде @ safe, @ live — нет. Это только линтер для @ system и @ trusted кода без гарантий безопасности.
