https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html Компания Google ввела в строй (https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html) проект OSS-Fuzz (https://github.com/google/oss-fuzz), в рамках которого попыталась адаптировать свой опыт организации непрерывного fuzzing-тестирования (https://en.wikipedia.org/wiki/Fuzz_testing) Chromium для обеспечения тестирования любых открытых проектов. Суть fuzzing-тестирования в генерации потока всевозможных случайных комбинаций входных данных, приближенных к реальным данным (например, html-страницы с случайными параметрами тегов или изображения с аномальными заголовками), и фиксации возможных сбоев в процессе их обработки. Если какая-то последовательность приводит к краху или не соответствует ожидаемой реакции, то такое поведение с высокой вероятностью свидетельствует об ошибке или уязвимости. <br><br><br>Первый вариант сервиса основан на применении движка libFuzzer (http://llvm.org/docs/LibFuzzer.html), ранее переданного сообществу LLVM, и набора Google Sanitizers (https://github.com/google https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#36 Fri, 08 Feb 2019 19:14:34 GMT Ну pypy написан на питоне.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#35 Mon, 05 Dec 2016 22:30:40 GMT &gt; Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было.<br><br>А у интеловских процов все сложные древние инструкции узкого специального назначения -- это полнейший отстой в плане производительности. Есть куча инструкций общего назначения, которые можно привлечь к проверке. И, писечка в том, что здравомыслящий программист эти проверки вставляет в код всегда, когда их не вставляет туда компилятор. Раньше было важно вставлять их именно вручную, потому что компилятор не умел оптимизировать. Сегодня же... Гляньте для примера на C++: там проверки на выход за границы массива вставляет даже не компилятор, а библиотека -- STL, -- и это в C++, мастурбирующем на скорость выполнения кода. На каждый вызов оператора [] втыкается проверка выхода за границы массива. Как это возможно? А очень просто: современный оптимизирующий компилятор вполне в состоянии вычислить ненужные п https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#34 Mon, 05 Dec 2016 16:41:58 GMT Ну вот выдаст гуголь рекомендации, типа вот у вас тут неоптимально. Думаю не менее половины разработчиков не думая влепят предлагаемый солюшн.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#33 Sun, 04 Dec 2016 07:59:01 GMT Адольфус, я намекаю обычно плохо, так что скажу прямо: у Вас словесный понос.<br><br>"Контролировать границы изменения индексов" нужно потому, что когда Вы за них случайно выйдете, Вам бы хотелось, что выдалась большая жирная ошибка "неправильный индекс" весто того, чтобы запортить Вам адрес возврата или кучу.<br><br>Всё.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#32 Sat, 03 Dec 2016 08:11:26 GMT &gt; Как там проколоться можно, я и представить не могу.<br><br>Не только проколоться, но и в ногу выстрелить.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#31 Sat, 03 Dec 2016 07:07:30 GMT Что это за языки такие, в которых програмист не может контролировать границы изменения индексов и для этого нужны какие-то скрытые от него механизмы? А если есть возможность указать границы, то зачем делать какие-то еще проверки? Вы просто не лезете своими индексами за пределы буфера, размер которого Вам всегда известен, и все. Если Вы не знаете размера буфера, то никакие проверки не помогут. <br>Не знаю ни одного насильника, чтобы тот прокалывался с индексами или указателями. Ну разве что на этапе освоения C Library.<br>Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было. <br><br>А что не так с указателями? В си, например, они имеют типы и отлично проецируются в адресные части инструкций любых процессоров. Как там проколоться можно, я и представить не могу.<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#30 Fri, 02 Dec 2016 22:16:40 GMT Ты удивишься, но авторы кода. Данный сервис лишь показывает наличие потенциальных проблем, никаких рекомендаций кроме очевидной - посмотрите и по возможности исправьте - он не дает. Так что вычитанный тобой афоризм совершенно не подходит к этой ситуации, иди поищи еще умных мыслей для копипасты. <br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#29 Fri, 02 Dec 2016 19:00:36 GMT В байты<br> https://ssl.opennet.dev/openforum/vsluhforumID3/109796.html#28 Fri, 02 Dec 2016 14:59:16 GMT &gt; И как там, в луже?<br><br>Тепло, комфортно и мокро.<br>