Я работаю в 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 <stdlib.h> 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 <setjmp.h> #include <stdlib.h> 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 <stdio.h> #include <stdlib.h> 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 <stdlib.h> 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 <stdlib.h> 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 <stdio.h> #include <signal.h> 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 кода без гарантий безопасности.
