Компания Google ввела в строй (https://opensource.googleblog.com/2016/12/announcing-oss-fuz... проект OSS-Fuzz (https://github.com/google/oss-fuzz), в рамках которого попыталась адаптировать свой опыт организации непрерывного fuzzing-тестирования (https://en.wikipedia.org/wiki/Fuzz_testing) Chromium для обеспечения тестирования любых открытых проектов. Суть fuzzing-тестирования в генерации потока всевозможных случайных комбинаций входных данных, приближенных к реальным данным (например, html-страницы с случайными параметрами тегов или изображения с аномальными заголовками), и фиксации возможных сбоев в процессе их обработки. Если какая-то последовательность приводит к краху или не соответствует ожидаемой реакции, то такое поведение с высокой вероятностью свидетельствует об ошибке или уязвимости.
Первый вариант сервиса основан на применении движка libFuzzer (http://llvm.org/docs/LibFuzzer.html), ранее переданного сообществу LLVM, и набора Google Sanitizers (https://github.com/google/sanitizers), в который входят инструменты AddressSanitizer (https://github.com/google/sanitizers/wiki/AddressSanitizer), MemorySanitizer (https://github.com/google/sanitizers/wiki/MemorySanitizer), LeakSanitizer и ThreadSanitizer, позволяющие на основе выявленных в процессе fuzzing-тестирования проблем, определять наличие типовых уязвимостей, вызванных переполнениями буфера, целочисленными переполнениями, обращением к неинициализированным и освобождённым областям, утечками памяти, разыменованием указателей и проблемами с установкой блокировок.В будущем в OSS-Fuzz планируется обеспечить поддержку и других движков fuzzing-тестирования, таких как AFL (http://lcamtuf.coredump.cx/afl/). Для формирования отчётов и распределённого тестирования кода задействован кластер ClusterFuzz (https://github.com/google/oss-fuzz/blob/master/docs/clusterf... уже применяемый для проверки Chrome. В настоящее время в OSS-Fuzz обеспечивает около 4 триллионов проверок в неделю. Тестирование охватывает 31 открытый проект (https://github.com/google/oss-fuzz/tree/master/projects), среди которых SQLite, PCRE2, openssl, boringssl, coreutils, curl, ffmpeg, freetype2, libjpeg-turbo, libpng, node.js, nss, pidgin и zlib. В процессе проверки данных проектов выявлено 150 ошибок, из которых 92 ошибки (https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=typ... уже исправлены.
Разработчики других открытых проектов могут добавить свои репозитории для тестирования, подготовив шаблон fuzzing-тестирования (http://llvm.org/docs/LibFuzzer.html#fuzz-target) и отправив (https://github.com/google/oss-fuzz#accepting-new-projects) специальную заявку через pull-запрос. При обнаружении ошибок, разработчикам автоматически отправляется уведомление и создаётся приватная заявка на исправление (https://bugs.chromium.org/p/oss-fuzz/issues/list) (чтобы исключить преждевременной утечки сведений об уязвимостях, issue создаётся в системе отслеживания ошибок с ограниченным доступом). ClusterFuzz отслеживает состояние исправления ошибки и сам закрывает issue. Информация о проблеме становится публично доступной спустя 7 дней после исправления или спустя 90 дней с момента выявления ошибки, если проблема остаётся не исправлена.
URL: https://opensource.googleblog.com/2016/12/announcing-oss-fuz...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45602
Шикарная новость! С её помощью мы сможем проверить боты ли пишут всякую муть про OSS/Alsa/Pulsaudio или же это делают живые люди.
Шикарная новость! С её помощью мы сможем проверить Астахлы ли пишут всякую муть про OSS/Alsa/Pulsaudio или же это делают живые люди.
да
> мутьПример мути, пожалуйста?
П-ш-ш-ш, например.
Что только люди не придумают, чтобы не использовать языки с управляемой памятью!
"вызванных переполнениями буфера, целочисленными переполнениями, обращением к неинициализированным и освобождённым областям, утечками памяти, разыменованием указателей и проблемами с установкой блокировок"Внимание вопрос: что из этого списка решается языками с управляемой памятью?
Подсказка: меньше половины.Попкорн захватил, жду ответа.
angra, я конечно понимаю, что это не совсем то место, где стоит задавать такие вопросы (ой налетят сейчас на меня!), но какие собственно языки относят к языкам с управляемой памятью, да и есть ли определение этой самой "управляемой памяти"?Я так понимаю, что "язык с управляемой памятью", должен:
1) осуществлять проверку индексов при работе с буфером
2) оперировать связываниями, а не переменными
3) не позволять оперирование указателями вообщеНо может, я ошибаюсь?
Не, ну с тобой не интересно, я лучше того анонима подожду, который уверен, что управляемая память позволяет решить даже проблему целочисленного переполнения.Но вообще часть операций с указателями языки с управляемой памятью разрешают. Обычно запрещается запись в указатель произвольного значения и адресная арифметика, что по сути одно и то же. Но остается возможность хранения в отдельных переменных и структурах, копирование, сравнение, передача в функцию, обнуление.
Управляемая память позволяет решить даже проблему целочисленного переполнения!!!!11111
> angra, я конечно понимаю, что это не совсем то место, где стоит
> задавать такие вопросы (ой налетят сейчас на меня!), но какие собственноhttps://duckduckgo.com/?q=language+managed+mamory
Одна из первых ссылок на MSDN -- что "какбэ намекает"ТМ. //пусть теперь они отмазываются!
> языки относят к языкам с управляемой памятью, да и есть ли
> определение этой самой "управляемой памяти"?
Во. Это определение, пожалуй, и возьму. Ничего более чёткого я не нашёл."The Microsoft definition is that managed memory is cleaned up by a Garbage Collector (GC), i.e. some process that periodically determines what part of the physical memory is in use and what is not."
Спасибо, Андрей!
> Во. Это определение, пожалуй, и возьму. Ничего более чёткого я не нашёл.
> "The Microsoft definition is
> Спасибо, Андрей!Вы меня неправильно https://www.opennet.ru/openforum/vsluhforumID3/109204.html#72 поняли, коллега!? P-))
Что это за языки такие, в которых програмист не может контролировать границы изменения индексов и для этого нужны какие-то скрытые от него механизмы? А если есть возможность указать границы, то зачем делать какие-то еще проверки? Вы просто не лезете своими индексами за пределы буфера, размер которого Вам всегда известен, и все. Если Вы не знаете размера буфера, то никакие проверки не помогут.
Не знаю ни одного насильника, чтобы тот прокалывался с индексами или указателями. Ну разве что на этапе освоения C Library.
Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было.А что не так с указателями? В си, например, они имеют типы и отлично проецируются в адресные части инструкций любых процессоров. Как там проколоться можно, я и представить не могу.
> Как там проколоться можно, я и представить не могу.Не только проколоться, но и в ногу выстрелить.
Адольфус, я намекаю обычно плохо, так что скажу прямо: у Вас словесный понос."Контролировать границы изменения индексов" нужно потому, что когда Вы за них случайно выйдете, Вам бы хотелось, что выдалась большая жирная ошибка "неправильный индекс" весто того, чтобы запортить Вам адрес возврата или кучу.
Всё.
> Была такая инструкция у интеловского ЦПУ -- bound -- как почитаешь мануал, сколько тактов она жрет и что после этого случается с кешем, так возникает желание страничку вырвать нахрен, чтобы и соблазна не было.А у интеловских процов все сложные древние инструкции узкого специального назначения -- это полнейший отстой в плане производительности. Есть куча инструкций общего назначения, которые можно привлечь к проверке. И, писечка в том, что здравомыслящий программист эти проверки вставляет в код всегда, когда их не вставляет туда компилятор. Раньше было важно вставлять их именно вручную, потому что компилятор не умел оптимизировать. Сегодня же... Гляньте для примера на C++: там проверки на выход за границы массива вставляет даже не компилятор, а библиотека -- STL, -- и это в C++, мастурбирующем на скорость выполнения кода. На каждый вызов оператора [] втыкается проверка выхода за границы массива. Как это возможно? А очень просто: современный оптимизирующий компилятор вполне в состоянии вычислить ненужные проверки и убрать их.
И на фоне этого, вой современных программистишек, что мол автоматические проверки на выход за границы массива не совместимы с производительностью, выглядит смешно. Ещё смешнее, когда для подтверждения своих тезисов они вытаскивают на свет божий инструкцию bound, которой сто^W сорок лет в обед, и которая существует сегодня (если существует) исключительно ради обратной совместимости и за сорок лет своего существования небось ни разу не оптимизировалась, потому что Intel'у глубоко плевать на то, как быстро она работает, лишь бы работала.
Вопрос на засыпку: А на чём написаны компиляторы и интерпретаторы языков с управляемой памятью?
За всех не скажу, но вот Roslyn, к примеру, на C#.
А сишарп на чём?
На английском
Жирно, но доставило :)
https://github.com/ghc/ghc
> Haskell 82.1% C 10.6% Makefile 2.2% Terra 1.7% Logos 0.5% Python 0.5% Other 2.4%Вопрос на засыпку: А на чем написаны компиляторы языков с ручным управлением памятью?
https://github.com/gcc-mirror/gcc/blob/gcc_5_3_0_release/lib...
https://github.com/gcc-mirror/gcc/blob/gcc_5_3_0_release/lib...movl %esp,%eax # Current stack,
subl 8(%esp),%eax # less required stack frame size,
subl $NON_SPLIT_STACK,%eax # less space for non-split code.
cmpl %gs:0x30,%eax # See if we have enough space.
https://github.com/gcc-mirror/gcc
> C 46.1% Ada 18.4% C++ 15.1% Go 6.4% GCC Machine Description 3.5% HTML 3.4% Other 7.1%И что же теперь из этого следует?
Вопрос на засыпку: а во что компилируется любой язык с управляемой памятью?
> Вопрос на засыпку: а во что компилируется любой язык с управляемой памятью?И как там, в луже?
> И как там, в луже?Тепло, комфортно и мокро.
В байты
Ну pypy написан на питоне.
а что, если рекомендации гугла окажутся вредными для OpenSource ? :) Кто проверит проверяющего?
> а что, если рекомендации гугла окажутся вредными для OpenSource ? :) Кто
> проверит проверяющего?Учёные, безопасники, философы. В MS-Research и на опеннет таковых с избытком!
Ты удивишься, но авторы кода. Данный сервис лишь показывает наличие потенциальных проблем, никаких рекомендаций кроме очевидной - посмотрите и по возможности исправьте - он не дает. Так что вычитанный тобой афоризм совершенно не подходит к этой ситуации, иди поищи еще умных мыслей для копипасты.
Ну вот выдаст гуголь рекомендации, типа вот у вас тут неоптимально. Думаю не менее половины разработчиков не думая влепят предлагаемый солюшн.