Ядро macOS, есть ли червячки в этом яблоке?
В самом начале этого года Apple выложили в открытый доступ исходный код системных компонентов macOS 11.0 – Big Sur, включая XNU – ядро операционной системы macOS. Пару лет назад исходный код ядра уже проверялся PVS-Studio в связи с выходом анализатора для macOS. Прошло достаточно много времени, и вышел новый релиз исходного кода ядра. Почему бы и не провести повторную проверку.
Что это за проект, Apple и open-source?
XNU – X is Not Unix – используется и разрабатывается Apple в качестве ядра операционных систем OS X. Исходные коды этого ядра 20 лет назад были опубликованы под лицензией APSL (Apple Public Source License) вместе с OC Darwin. Раньше Darwin можно было даже установить в качестве полноценной операционной системы, однако теперь это стало невозможно. Причиной публикации исходного кода является тот факт, что он во многом основан на других open-source проектах.
Исходные коды компонентов можно найти тут. Для проверки я использовала зеркало проекта на GitHub.
Предыдущая проверка
Как я уже упомянула, этот проект ранее проверялся нами с помощью PVS-Studio. С предыдущими результатами можно познакомиться в статье: «Релиз PVS-Studio для macOS: 64 weaknesses в Apple XNU Kernel». После публикации мой коллега Святослав также отправил статью разработчикам на почту, но ответа не получил. Так что я предполагаю, что наша проверка никак не связана с исправлениями, которые мы дальше рассмотрим. Разработчикам пришлось искать их другим путём. А могли бы просто взять и запустить PVS-Studio :). Сейчас, после публикации статей, мы в основном пишем об этом в GitHub репозиторий проекта.
Мне стало интересно, были ли исправлены ошибки, описанные в предыдущей статье, или всё так и осталось. Большинство из найденных ошибок действительно были исправлены. Это показывает, что отобранные предупреждения анализатора оказались верными. Хотя для написания статьи с отчётом работал человек, не участвующий в разработке XNU, то есть близко не знакомый с этим исходным кодом.
Я приведу здесь несколько примеров исправлений. Но, чтобы не раздувать объём статьи, не буду полностью приводить объяснение ошибок. Если из исправления будет неясно, в чём была проблема, то вы всегда можете обратиться к первой статье по проверке этого проекта. Я не буду разбирать все исправленные фрагменты, большинство из фрагментов всё-таки было поправлено. А фрагментов в предыдущей статье было ни много ни мало 64!
Перейдём к рассмотрению исправлений примеров из прошлой статьи.
Фрагмент N1, в котором член класса сравнивался сам с собой:
Был исправлен следующим образом:
Где макрос, из которого получена переменная orglen, выглядит следующим образом:
Выходит, что анализатор оказался прав: сравнение было некорректным и должно было проводиться с переменной orglen, которая даже присутствовала в коде до исправления.
Еще один пример исправления, который я хочу привести здесь, – фрагмент N5, где знак равно всё-таки был исправлен на проверку на равенство.
Накосячить в условии assertf – одно, но ещё и перезаписать переменную для отладочной версии – такое точно стоит поправить.
Фрагменты 6 и 7 были исправлены одинаково. Оказалось, что во вложенной проверке перепутали значение перечислителя для сравнения. Вместо PBUF_TYPE_MBUF во внутренней проверке должен быть элемент PBUF_TYPE_MEMORY в обоих случаях.
В случае фрагментов N8, 9, 10 исправление было таким:
На это исправление я обратила внимание, так как серьёзная часть коммита в целом (обновление репозитория до xnu-4903.270.47 от 11 января) содержит помимо прочего много правок код-стайла. Это может указывать на то, что для данной версии кодовая база была подчищена с помощью разных инструментов качества кода. Что сделает эту проверку PVS-Studio более интересной. Ведь видно, что качество кодовой базы уже было улучшено другими инструментами.
Что касается фрагментов 11, 12, 13, 14 – был исправлен только фрагмент 11:
Остальные остались прежними. Похоже, кто-то невнимательно прочитал наш отчёт 😉 (или отчёт анализатора, использованный для улучшения качества кода в этом коммите). Приведу здесь код, на который было выдано одно из предупреждений, чтобы не было сомнений в аналогичности ошибки:
Предупреждение PVS-Studio: V612 An unconditional ‘return’ within a loop. kern_credential.c 951
Я привела код почти целиком, чтобы можно было сформировать общее представление о том, что происходит в этой функции. В случае отмеченного цикла при выполнении условия входа в него будет совершён один проход по телу цикла, завершающийся возвращением error. Видимо, подразумевалось, что если выполняется условие (workp = TAILQ_FIRST(. )) == NULL, то нужно найти причину ошибки и завершить функцию возвращением информации об ошибке. Однако по какой-то причине вместо if был написан while, как и во фрагменте из предыдущей статьи. Строчка error = msleep0(. ) выглядит в коде таким образом:
Здесь последним аргументом передаётся указатель на функцию kauth_resolver_getwork_continue. В теле этой функции есть условие, аналогичное условию цикла, на который нам указал анализатор. Но в нём уже корректно используется if, а не while.
В принципе этот код работает немного сложнее, чем я описала. В нём присутствует рекурсия (в методе kauth_resolver_getwork_continue), и, как я поняла, он нацелен на нахождение потоков, которые можно перезагрузить. Но я не стала вдаваться в подробности, так как while всё равно лишний. Возможно, он остался здесь с того времени, когда исходный код выполнял ту же задачу, но без использования рекурсии.
Это примеры из начала статьи. Проскочим в середину и возьмём фрагмент N40. В нём одному и тому же элементу дважды присваивается одно значение:
Предупреждение PVS-Studio: V519 CWE-563 The ‘wrap.Seal_Alg[0]’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 2070, 2071. gss_krb5_mech.c 2071
Эта ошибка, конечно же, тоже была поправлена:
Ну и ближе к концу статьи, фрагмент 62 был исправлен так, как и было предложено в предыдущей статье. Причём это было единственной правкой в том файле.
Фрагменты 63 и 64 также были исправлены, но там код был изменён капитально. Поэтому понять, какое исправление было именно для рассмотренного предупреждения, сложно.
Новые находки
После этого долгого вступления перейду к ошибкам, которые привлекли моё внимание при последней проверке исходного кода XNU статическим анализатором PVS-Studio. Скажу честно, мне тяжело далась работа с отчётом, так как проект имеет сложный код и у меня нет опыта работы с подобной кодовой базой. Но предупреждения PVS-Studio достаточно подробны и имеют ссылку на документацию с примерами правильного и неправильного кода и описанием возможной проблемы, что очень меня выручило.
К этой проверке cloc насчитал в проекте 1346 *.c файлов, 1822 С/C++ хэдера и 225 *.cpp файлов.
Ну и перейдём к разбору интересных находок.
Фрагмент N1
Предупреждение PVS-Studio: V1064 The ‘gPEClockFrequencyInfo.bus_clock_rate_hz’ operand of integer division is less than the ‘gPEClockFrequencyInfo.dec_clock_rate_hz’ one. The result will always be zero. pe_identify_machine.c 72
Все используемые здесь поля имеют целочисленный тип:
Через промежуточные присвоения полю gPEClockFrequencyInfo.bus_clock_rate_hz, являющемуся делимым, присваивается значение 100000000, а полю-делителю gPEClockFrequencyInfo.dec_clock_rate_hz присваивается значение 1000000000. Делитель в этом случае в десять раз больше делимого. Так как все поля здесь являются целочисленными, поле gPEClockFrequencyInfo.bus_to_dec_rate_den окажется равным 0.
Судя по наименованию результирующего поля bus_to_dec_rate_den, делитель и делимое были перепутаны местами. Я допускаю возможность, что код был написан с расчётом на то, что исходные значения изменятся и результат уже не будет равен 0. Но этот код всё равно кажется мне очень подозрительным.
Фрагмент N2
Предупреждение PVS-Studio: V614 Uninitialized variable ‘best’ used. sdt.c 572
Насколько я поняла, этот метод ищет название некоей функции. В алгоритме используется переменная best, возможно, это положение наилучшего кандидата на результат. Однако изначально эта переменная только объявляется без инициализации. Следующее же использование сверяет значение некоего элемента с переменной best, которая будет неинициализированной на тот момент. Еще страннее, что она инициализируется только внутри условия, в котором используется её же значение.
Неинициализированные переменные могут приводить к непредсказуемым результатам. И, хотя эта ошибка может показаться достаточно банальной, она всё ещё часто встречается при проверках разных проектов с помощью PVS-Studio. Например, совсем недавно мой коллега Андрей описывал интересный случай такой ошибки.
Фрагмент N3
Предупреждение PVS-Studio: V560 A part of conditional expression is always false: index nb_dirtyoff >= bp->nb_dirtyend’ is always false. nfs_bio.c 3858
V560 A part of conditional expression is always true: (bp->nb_dirtyoff nb_dirtyend > 0) && (bp->nb_dirtyoff nb_dirtyend > end. А также осуществляется присвоение bp->nb_dirtyend = end.
Почему же третья проверка bp->nb_dirtyoff >= bp->nb_dirtyend будет всегда false?
Всё просто. Из условий выходит, что nb_dirtyoff меньше, чем end, а nb_dirtyend равно end. В итоге nb_dirtyend точно больше, чем nb_dirtyoff. Присвоение bp->nb_dirtyoff = bp->nb_dirtyend = 0 никогда не будет выполнено.
В итоге вот такой участок кода:
Можно упростить хотя бы до такого:
Но только если в настоящий момент этот алгоритм работает корректно.
Второе предупреждение указывает на четвёртый if, вложенный в первый.
Здесь анализатор выдаёт предупреждение на основании того, что присвоение нуля никогда не будет выполнено. В итоге во внешнем условии уже была проверка bp->nb_dirtyoff t_rawq.c_cc + tp->t_canq.c_cc’ statement is a part of the condition. Perhaps, this statement should have been compared with something else. tty.c 568
Аналогичный случай. Тут повыше в коде снова есть проверка, которая не просто использует сумму, а сравнивает результат с другой переменной:
В упрощённом коде условие, на которое указал анализатор, выглядит заметно. Но в оригинале оно было вложено в несколько if. Так что при код-ревью такое можно и пропустить, а анализатор не пропустит 😉
Фрагмент N7
Предупреждение PVS-Studio: V1028 Possible overflow. Consider casting operands of the ‘amount + used’ operator to the ‘size_t’ type, not the result. kpi_mbuf.c
Снова ошибка в условии, но уже совсем другого рода. Вместо приведения к size_t операндов сложения, чтобы результат точно поместился в числовой тип, к size_t приводится результат сложения. Если в итоге сложения возникнет переполнение, то с результатом mbuf_maxlen(m) будет сравниваться бессмысленное значение, приведённое к size_t. Раз программист всё-таки хотел защититься от переполнения, то стоит его сделать правильно:
Таких срабатываний было несколько, стоит обратить на этот момент внимание.
- V1028 Possible overflow. Consider casting operands, not the result. vm_compressor_pager.c 1165
- V1028 Possible overflow. Consider casting operands, not the result. vm_compressor_pager.c 1131
- V1028 Possible overflow. Consider casting operands, not the result. audit_worker.c 241
- V1028 Possible overflow. Consider casting operands of the ‘((u_int32_t) slp * hz) + 999999’ operator to the ‘long’ type, not the result. tty.c 2199
Фрагмент N8
Предупреждение PVS-Studio: V1019 Compound assignment expression ‘n -= i’ is used inside condition. kern_descrip.c_99 3916
Этот код, на мой взгляд, является крайне сложночитаемым. Возможно, условие, на которое указал анализатор, стоит переписать в более простом виде:
Этот код выглядит менее эффективным, но точно является более понятным. Для быстрой проверки равнозначности эффективности этого кода можно зайти на Godbolt (Compiler Explorer), где, кстати, можно тестировать работу диагностик PVS-Studio. Анализатор легко найти среди инструментов этого сервиса.
Если не включать оптимизации, то ассемблерный код получится на пару строк больше. А вот с оптимизациями разницы уже нет никакой. Так что писать тут хитрый код нет смысла, компилятор всё сам сделает, как надо.
Но, если обратить внимание на тело этого if, новое значение n в нём не используется. То есть вполне возможно, что никакое присвоение здесь и не нужно. Тогда можно обойтись таким кодом:
И, более того, исходный код может приводить к ошибке при дальнейшем использовании переменной n. Если выражение (n -= i) tbr_last’ should be checked here. classq_subr.c 685
В проекте эта диагностика работала не лучшим образом, так как в коде постоянно над телом условия или цикла инициализировались сторонние переменные с именами, похожими на используемые в условии. Поэтому на этот раз диагностика выдала несколько явно ложных предупреждений. Но рассматриваемое нами срабатывание всё же показалось мне подозрительным, так как проверяемое поле tbr_rate не использовалось в теле условия и было инициализировано на 35 строк выше этой проверки. А вот поле tbr_last, инициализированное прямо перед этой проверкой, больше нигде не используется. Можно предположить, что проверить нужно было его вместо tbr_rate.
Фрагмент N11
Предупреждение PVS-Studio: V571 Recurring check. The ‘if (ar->k_ar.ar_arg_mac_string == NULL)’ condition was already verified in line 245. audit_mac.c 246
Предупреждение PVS-Studio: V547 Expression ‘ar->k_ar.ar_arg_mac_string == NULL’ is always true. audit_mac.c 246
На этот код анализатор выдал сразу два предупреждения.
Сначала взгляд может зацепиться за то, что проверка в самом первом if и во втором совпадает. Но тут всё правильно: внутри тела первой проверки аллоцируется память, а для второй проверки есть пояснение:
Судя по этому комментарию, во второй проверке не должно быть никакой внутренней проверки. Нужно просто выйти из метода. Так что, скорее всего, внутренняя проверка была продублирована случайно и не имеет никакого смысла.
Хотя возможен и тот вариант, что во внутренней проверке нужно было проверить какое-то другое поле. Но сюда закралась ошибка копипасты, и разработчик забыл поправить имя поля.
Фрагмент N12
Предупреждение PVS-Studio: V567 Undefined behavior. The ‘ucsp’ variable is modified while being used twice between sequence points. vfs_utfconv.c 298
Макросы – очень коварная штука. Возможно, вы даже уже встречались с нашей статьей «Вред макросов для C++ кода». Я обычно при написании статей избегаю срабатываний на макросы. С ними всегда всё оказывается сложно без знакомства с кодовой базой проекта.
Но в случае этой ошибки всё оказалось чуть проще. Хотя, чтобы дойти до причины и развернуть цепочку макросов, пришлось прыгнуть в ту ещё кроличью нору. Собственно, цепочка эта начинается с выражения OSSwapInt16(*ucsp++).
Потом я поняла, что есть способ попроще, и просто обратилась к .i файлу, который остался после проверки проекта. По нему строка с этим макросом развернулась следующим образом:
Больше всего здесь нас интересует вот этот участок выражения:
Никакой из операторов в выражении не является точкой следования. Так как точно неизвестно, какой из аргументов оператора | будет вычисляться первым, значение *uscp оказывается неопределённым.
Для диагностики V567 PVS-Studio предоставляет крайне подробную документацию. Если вам интересно, почему такой код может приводить к неопределённому поведению, документация может стать хорошим началом изучения этой проблемы.
Однако это ещё не всё! Есть очень интересный и важный момент. Готова поспорить, что человек, писавший этот код, планировал увеличить значение *ucsp только один раз. Но, на самом деле, значение увеличится дважды. Это не видно и непонятно. Макросы очень и очень опасны из-за вот таких случаев. Во многих ситуациях лучше написать обыкновенную функцию. Скорее всего, компилятор автоматически выполнит подстановку и никакого ухудшения производительности не произойдёт.
Фрагмент N13
Предупреждение PVS-Studio: V567 Undefined behavior. The ‘pf_status.stateid’ variable is modified while being used twice between sequence points. pf.c 1440
И снова коварные макросы смешали все карты для инкремента. Рассмотрим строку с вызовом htobe64, которая оказалась подозрительной для анализатора после препроцессинга:
Проблема собственно та же, что и в предыдущем примере. Во внутренней цепочке с операндами | и & нет точек следования. Поэтому неизвестно, какое значение примет pf_status.stateid на моменте выполнения каждой операции. Результат также неопределён.
И, опять-таки, переменная увеличивается несколько раз подряд, что является неприятным сюрпризом от макроса :).
Вот остальные срабатывания этой диагностики на этом проекте:
- V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. ip_id.c 186
- V567 Undefined behavior. The ‘lp’ variable is modified while being used twice between sequence points. nfs_boot.c 505
- V567 Undefined behavior. The ‘lp’ variable is modified while being used twice between sequence points. nfs_boot.c 497
- V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 588
- V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 665
- V567 Undefined behavior. The ‘ip_id’ variable is modified while being used twice between sequence points. kdp_udp.c 1543
Фрагмент N14
Предупреждение PVS-Studio: V519 The ‘uh->uh_sport’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 4866, 4870. ipsec.c 4870
В этом фрагменте возникла подозрительная ситуация: полю uh_sport в зависимости от определённого условия присваиваются разные значения. Однако сразу после if-else этому же полю снова присваивается значение, такое же как в ветке else. В итоге этот if-else блок теряет смысл, так как значение поля всё равно будет перезаписано.
Фрагмент N15
Предупреждение PVS-Studio: V547 Expression ‘(value & (1ULL
Источник
