Ядро Linux проверено статическим анализатором PVS Studio

В Clang же тоже есть статический анализатор, почему с ним нет сравнений?

Всё просто. Это большая и сложная задача. До неё не хватает времени и сил.

Почему не проанализировать MySQL, например.

Проанализировали. Код качественный и на статью не набралось. Авторов уведомил.

Если тебе что-то непонятно во фразе:

tailgunner> прогнали ядро через готовый анализатор

спрашивай.

Что толку от нахождения уязвимостей которых нет. Так понятно?

Я не утверждал, что найдены серьезные уязвимости. В статье я хотел показать, что диагностики, выдаваемые PVS-Studio можно использовать не только для нахождения ошибок, но и для нахождения некоторых видов уязвимостей. Странно было бы найти с помощью PVS-Studio дыру размером с галактику в Linux, который вдоль и поперёк проверен множеством различным инструментов. Тот-же Coverity например. Linux фактически является полигоном испытаний различных инструментов анализа. То, что удалось найти хоть что-то поле всех этих инструментов, уже большое достижение.

А тебе бы лишь погромче погазировать в комментах на ЛОРе, не принимая во внимание LKML и принятые патчи на найденные подозрительные места. Хоть бы поскромнее выражал своё «правильное» мнение.

С одной стороны вы приводите ссылку на архитектуру майнфреймов из 90-х, хоть это конечно не главное. С другой, код завершается:

if (ret)
       ret = *(char *) r2 - *(char *) r4;

сообщество поюзали

Просто прогнав код через этот статический анализатор? Код открыт, каждый может прогнать его через что хочет, в чём проблема то?

Я комментировал их анализ и выводы, вы комментируете свое фи. Ну очень познавательно.

С одной стороны вы приводите ссылку на архитектуру майнфреймов из 90-х

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

Код надо писать по стандартам, чтобы не было сюрпризов с портированием на новые архитектуры.

В ядро уже приняты патчи на основе их анализа. Этого мало? Даже если бы приняли только один патч - значит проверка уже прошла не в пустую.

Ну так ядро пишут разработчики, а срут в комментариях на лоре, в основном, балаболы, которые с пеной у рта друг другу на полном серьезе доказывают, что должно получиться в результате i = ++i + i++

Я написал про конкретные их замечания, если возражений нет то мне непонятно что у вас так бомбануло.

Вполне может быть что дело в одной скобочке не на своём месте.

Те, кто её закрыл считают иначе.

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

Разве ядро уже не собирается Шлангом (не без патчей, но всё же)? И патчи на совместимость с ним принимают. И как минимум один дистрибутив в этом году на него переходит.

12309 не фиксят, systemd везде пихают... нафиг нужен такой линукс

Вы меня конечно извините, но вы процитировали не мое сообщение. Я написал: «шланге».
Это лор всетаки

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

Может сперва заглянешь в багзиллу, перед тем как бухтеть?

Я считаю, что нужно сказать «спасибо» и команде PVS и Андрею, что они «нахаляву» показывают недостатки ядра. Заметьте - говнокод, прошедший одобрение Линуса! Осталось надеяться, что кому-то будет не лень хотя бы промтом прогнать отчёт Андрея и послать «его пингвиночеству».
Да, это коммерческий продукт - ВДВОЙНЕ надо быть благодарными, что люди не делают на вас деньги, а бесплатно помогают. Это было пояснение для некоторых ЛОРовцев, которых воспитали как свинотов неблагодарных.

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

Ну давай разберем по пунктам:

Вы ядро анализируете, у вас реализация этого strcmp перед глазами. Какие 0x100000, не несите чушь. Там разница между двумя байтами лежит, не верите так проверьте. Вы своей вижуалстудией размахиваете которая к ядру никакого отношения не имеет.

Ты предлагаешь писать неочевидный код, полагаясь на нюансы конкретной реализации? А если завтра её поменяют в новой архитектуре - что делать? Рыскать по всему ядру? Не будет ли более архитектурно правильно не полагаться в коде на «авось» и смотреть на пару шагов вперед?

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

Наглая, ВОПИЮЩЕ НАГЛАЯ ложь. Ядро адаптируют регулярно для сборки разными компиляторами, в том числе и icc и clang. А уж gcc почти любой современной версии может собирать ядро. Уж точно 4.6-4.8, потому что я тестирую. Да ещё и с разными патчами.

memset()

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

Все так, но вы говорите о баг-фиксах а я имею в виду баг-репорты.

Это «нюансы» из которых состоит код. Если моя программа сама внутри себя реализует memcmp (я ошибся в том посте), то зачем мне вникать в реализацию других и фиксить то что к коду отношения не имеет.
Адаптировать ядро вы можете под что угодно, но если вы собираете его чем-то отличным от gcc то слать Торвальдсу баг-репорты что оно не собирается borland c бессмысленно, это ваши проблемы.
По поводу самого memset() у меня не было претензий, я удивился тому что люди не удосужились проверить собственные выводы основанные на работе компилятора не имеющего отношения к тестируемому продукту.

надо быть благодарными, что люди не делают на вас деньги

Как не делают? Такой PR. Если бы Haiku проверили, тогда.

Что толку от нахождения уязвимостей которых нет.

Уязвимости или есть или их нет. Ошибка в документации — уже уязвимость.

А вообще, я фигею, дорогая редакция. Линуксят тычут носом в явные ошибки, а они «ничего не занаю, ничего нет»!

Andrey_Karpov_2009, а можете прогнать ядро OpenBSD ради интересса?

Какие ошибки в документации - это статический анализ кода, новость хоть прочтите перед комментированием. Про явные ошибки речи не идет.
Другое дело, что алгоритмы выявления ошибок лежат на поверхности, и тут действительно есть стимул для развития свободных продуктов. Те же расширения варнингов в gcc, например.

новость хоть прочтите перед комментирование

Не волнуйтесь, читал.

Про явные ошибки речи не идет

Дак, чёрт в деталях кроется. Сегодня пропустил integer overlow (ну мало ли!? don't gonna happen!), а завтра heatblead.

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

Царь, перелогинься.

Людей, которые оправдывают баги в коде молениями на компилятор, я бы расстреливал при попытке приблизиться к этому самому компилятору ближе чем на 100 метров. Вон из профессии, «инженер».

Кстати, вопрос. Вы рассматривали возможность предоставления бесплатной лицензии крупным опенсорсным проектам?

Возможно, из тех же {Free,Open,DragonFly}BSD кто-нибудь заинтересуется, а вам неплохой пиар.

уже вижу речь Тео :)

ты уже третий, кто в этой теме просит :) хотя я просил весь src (ну и, гулять так гулять, xenocara)

И что же разрабы сабжа не отдадут лицензию группе энтузиастов для проверки ядра Линукс?

Здесь всем очевидный профит. Ядро регулярно проверяется. Ошибки уменьшаются. Бесплатная реклама на весь мир сабжа.

А патчи в ядро приняты? Или правлен сферический конь в вакууме?

Почему у такого сурьёзного продукта такой упоротый логотип? Вы его писали, чтобы продавать или чтобы статейки для Швабры клепать?

Почему у такого сурьёзного продукта такой упоротый логотип?

Мы маленькие и приходится идти на хулиганство, чтобы остаться в памяти людей.

1. я за раздачу лицензии open source проектам

2. не понимаю за что удалили первый топик. Ну прогнали и прогнали, ну пиар и пиар, что плохого в этом мне совершенно не ясно.

3. ну и да, ждем lite версию в open source

не понимаю за что удалили первый топик. Ну прогнали и прогнали, ну пиар и пиар, что плохого в этом мне совершенно не ясно.

Там было 4.2 в тексте новости.

Хоть один баг приведите, инженер. Попытку собрать линукс визуальщиной нормальной не назовешь, но может у вас - инженера получится.

Вот я и посмотрел в детали. В деталях как раз все OK, это с высоты прикладного программиста там опасность есть но эти соображения сюда не подходят.

Тем не менее гцц умеет собирать хороший код так, что он не работает. Кто знает, может он плохой код собирает так, что тот работает хорошо?

``gcc - the best argument for non-determinism ever"

Хоть один баг приведите, инженер. Попытку собрать линукс визуальщиной нормальной не назовешь, но может у вас - инженера получится.

Тебе уже неоднократно указали, что оптимизирующий компилятор может выкинуть memset() как не имеющий побочных эффектов. Но чукча не читатель.

Или вот классическую ошибку «проверка на NULL после разыменования» ты тоже назовешь «попыткой собрать линукс визуальщиной», неуч?

Или некорректный if ... else if, когда управление никогда не попадает в одну из веток?

Таких как ты я бы гнал ссаными тряпками из профессии. «Я нихера не знаю, самообразовываться не хочу, и вообще я самый умный, потому что мой код у меня на локалхосте работает, а на других мне плевать.» С такой позицией в нормальную фирму даже полы мыть не возьмут.

Тем не менее гцц умеет собирать хороший код так, что он не работает.

На самом деле «хороший код, который gcc собирает плохо» — он не совсем хороший. Факап gcc в том, что раньше такой глубокой оптимизации компиляторы не умели, и программисты привыкли, что как написано, так и работает; а gcc оптимизирует и молчит.

Компиляторы научились выводить такие зубодробительные инфарианты при анализе алгоритмов, что любое случайное UB может МОЛЧА превратить всю функцию в винегрет. Если бы gcc умел сообщать «у вас тут после оптимизации херня какая-то получилось, посмотрите внимательнее», было бы норм.

Бесплатный CppCat для студентов

Это завлечение студентов на Visual Studio 2010-2013 те на венду. За одно это нужно карать!

Если моя программа сама внутри себя реализует memcmp (я ошибся в том посте), то зачем мне вникать в реализацию других и фиксить то что к коду отношения не имеет.

Потому что эта реализация платформозависимая, и с появлением новых платформ будут новые реализации, которые могут следовать по поведению согласно стандарту (и будут правы).

Адаптировать ядро вы можете под что угодно, но если вы собираете его чем-то отличным от gcc то слать Торвальдсу баг-репорты что оно не собирается borland c бессмысленно, это ваши проблемы.

Ты не прав. Действительно, ядро слишком завязано на gcc-змах, но их стараются выпиливать, чтобы можно было собирать ядро с помощью других компиляторов, таких как icc и clang, например.

Есть даже проект llvmlinux - форк ядра для сборки с помощью clang. Вот презенташка http://events.linuxfoundation.org/sites/events/files/slides/2014-LCNA-LLVMLin...

Из этой ветки ряд патчей попали в апстрим ядра.

И вообще, если ядро не собирается борландом, потому что борланд не придерживается стандарта языка - это проблема борланда. Если ядро не придерживается стандарта языка - это проблема ядра, которую фиксят.

По моему, первый абзац «Заключения» статьи авторов PVS Studio во-первых доставляет, а во-вторых, — исчерпывает тему.

Цитирую:

В любом большом проекте можно найти какие-то ошибки. Ядро Linux не стало исключением. Однако, разовые проверки кода статическим анализатором является неправильным способом его применения. Да, они позволяют написать вот такую рекламную статью, но приносят мало пользы проекту.

Ядро ОС платформозависимое по определению, потому что ОС это пограмма создающая операционную среду для исполнения других программ на конкретном железе. Про borlandc это конечно экстрим, но вы ведь не собираетесь linux визуальщиной собирать. libc - стнадарт для прикладных программ, даже винда собирается патченой визуальщиной и к стандартной библиотеке отношения не имеет а есть коммерческие ядра которым несколько компиляторов для сборки нужно. В общем, весь выхлоп линуксовых memcmp укладывается в char, спорить не о чем.

Опять демагогия одна. Вы по конкретным вопросам так ничего не ответили, в голове только «ссаные тряпки». Я не всякие if комментировал а конкретные баги. Для каких архитектур собирается код, какие флаги при этом используются? Вам по барабану, у вас рассуждения уровня секретарш. Для абстрактного компилятора с абстрактыми настройками. Это не системное программиование, в котором вы ничего не смыслите. Главное что прокукарекали, поздравляю.

ты несносный

Опять демагогия одна. Вы по конкретным вопросам так ничего не ответили, в голове только «ссаные тряпки». Я не всякие if комментировал а конкретные баги. Для каких архитектур собирается код, какие флаги при этом используются? Вам по барабану, у вас рассуждения уровня секретарш. Для абстрактного компилятора с абстрактыми настройками. Это не системное программиование, в котором вы ничего не смыслите. Главное что прокукарекали, поздравляю.

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

В общем, весь выхлоп линуксовых memcmp укладывается в char, спорить не о чем.

~/tmp/linux-3.18.3$ find . -name '*.h' | xargs grep 'extern.*memcmp'
./include/linux/string.h:extern int memcmp(const void *,const void *,__kernel_size_t);
./arch/powerpc/include/asm/string.h:extern int memcmp(const void *,const void *,__kernel_size_t);
./arch/powerpc/boot/string.h:extern int memcmp(const void *s1, const void *s2, size_t n);
./arch/arc/include/asm/string.h:extern int memcmp(const void *, const void *, __kernel_size_t);
./arch/arm64/include/asm/string.h:extern int memcmp(const void *, const void *, size_t);
./arch/blackfin/include/asm/string.h:extern int memcmp(const void *, const void *, __kernel_size_t);
./arch/s390/include/asm/string.h:extern int memcmp(const void *, const void *, size_t);

Ядерный memcmp() возвращает int, ты не осилил find и grep, а спорить тут действительно не о чем.