Покажите на ассемблере как выглядит защита от переполнения буфера?

Question

[Sasha_88]

Может кто-нибудь показать, используя x86-64 ассемблер, что делает компилятор языка с проверкой на выход за границу массива? И если этой проверки нет. Я правильно понимаю там одна, две инструкции лишние будут в коде, чтобы проверить и вызвать исключение, панику?
Спасибо

Comments

[Василий Дёмин]

Какой конкретно компилятор? В C/C++ компилятор никакие проверки за вас делать не будет. Компиляторы языков, у которых проверки прописаны в стандарте, реализуют их по-разному. Сначала идёт проверка, что индекс >= 0 и индекс < размера массива, если проверка не проходит, то дальше вызывается процедура, которая генерирует исключение или останавливает программу и выводит стектрейс или что-то ещё. Также в некоторых случах компиляторы не вставляют такие проверки, если при статическом анализе удалось подтвердить, что выхода за границы точно не будет.

Upd: На самом деле, можно сказать gcc/clang, чтобы он добавлял различные проверки при работе с памятью, добавив флаг -fsanitize=address. Алгоритм работы описан тут https://github.com/google/sanitizers/wiki/AddressS...,

[Sasha_88]

Василий Дёмин, В C++ будет делать проверки, если Вы используете at(). И мне нужно видеть какие именно инструкции машинного кода используются для этого. Я ожидаю что-то наподобие jmpcc инструкций. Лишние инструкции снижают производительность, а bound check elimination компилятор не всегда делает. И не понятно для каких паттернов выражений это будет работать. И надежды на fusion микрооперации в процессоре нет. Они не для всех инструкций реализованы и когда две инструкции в конвейере, то первая сработает, а вторая нет. (Это из описания этих микроопераций)

[Василий Дёмин]

Sasha_88, Ну так а при чём тут компилятор? at - это библиотечный метод, он не является частью компилятора. Его исходники можно посмотреть, достаточно скачать код стандартной библиотеки c++

[Sasha_88]

Василий Дёмин, Ну я вопрос в общем виде задавал. Потому, что в большинстве случаев это имеет отношение именно к компиляторам. В данном случае у меня MS Visual C++. Там только заголовочные файлы в библиотеке из исходного кода. От Майкрософт исходники открыты, чтобы скачать? Или смотреть сразу GNU Compiler Collection?

И мне не исходный код нужен, а код, который процессор выполнять будет. Мне надо посмотреть неужели какая-то одна инструкция обеспечивает прям полную защиту от хакинга с буфером.

[Василий Дёмин]

Sasha_88, Магии там никакой нет - проверка, что индекс больше нуля и меньше размера массива, если она не проходит, то вызывается процедура, которая кидает исключение. Получается, что такая простая проверка защитит от переполнения буфера, потому что, чтобы его переполнить надо записать больше, чем он может вместить. В инструкциях ассемблера - это cmp, jcc и call.

[res2001]

Sasha_88,

неужели какая-то одна инструкция обеспечивает прям полную защиту от хакинга с буфером.

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

В общем случае проверка выглядит так - когда выделяется память, то выделяется чуть больше памяти, в конец выделенного буфера записывается некое магическое число.
При освобождении памяти - число проверяется - не совпадает с эталоном - была запись за пределы массива. Так же можно проверять и при каждом обращении к этой памяти, но тут могут быть сложности. Кроме того - это дополнительный расход памяти и ЦП.
Аналогичным образом можно добавить к буферу места и в начале и проверять выход за начало буфера - такое то же может быть.
У GCC это делается с помощью ASAN (и прочих санитайзеров) - это дополнительная библиотека и некоторый код поддержки, который добавляет компилятор. Довольно полезная штука. Кроме того умеет не только утечки памяти ловить.
Кроме того есть валгринд и т.п. внешние анализаторы, intel vtune в отличие от валгринда очень быстро работает, правда стоит денег (и сейчас как-то по другому вроде бы называется, давно не пользовался).
Но все это используется обычно только на этапе отладки, в релизе - это все убирают, чтоб не тормозило процесс.

Answer 1

[Ternick]

Есть такая штука Stack Canary. Она отвечает за защиту от переполнения буфера, вполне возможно, что это не единственный механизм, но один из основных, которые отвечают за это.

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

В принципе вопрос особо ничего не стоит и гуглиться по первым ссылкам буквально, но допустим.

От себя порекомендую видео S0ER на эту тему

*ТЫК*

Comments

[Sasha_88]

Видео очень хорошее. Спасибо.

Answer 2

[Rsa97]

Защита от переполнения буфера - это не пара магических инструкций, а проверка при работе с массивами или выделенными участками памяти (впрочем, для C/C++/ASM это примерно одно и то же), что указатель не выходит за границу выделенной памяти. Реализовано может быть самыми разными способами. Например, в C есть функция strncpy, которая делает всё то же самое, что strcpy, только проверяя, что копируется не более заданного количества байтов. Если вы правильно передали в неё размер буфера, то переполнения при операции не произойдёт.
Так что на языках низкого уровня только проверки, проверки и ещё раз проверки.

Comments

[Sasha_88]

Мне просто надо видеть выход с компилятора походу. Лишние инструкции снижают производительность.

[Wataru]

Sasha_88, надо видеть, так посмотрите на https://godbolt.org/

Пишите ваш код, выставляйте флаги компилятора и смотрите ассемблерный выход.

[Sasha_88]

Wataru, Вот это сервис! Спасибо большое!

[Rsa97]

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

[Sasha_88]

Rsa97, Да я уже понял.

call    std::vector<int, std::allocator<int>>::at(unsigned long)

[Rsa97]

Sasha_88, Ну, всегда можно поковыряться в исходниках того же gcc:

_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
reference
at(size_type __n)
{
    _M_range_check(__n);
    return (*this)[__n];
}

Видим, что вся суть функции сводится к проверке выхода индекса за границы и выдаче значения по этому индексу. Посмотрим код проверки:

_GLIBCXX20_CONSTEXPR
void
_M_range_check(size_type __n) const
{
    if (__n >= this->size())
    __throw_out_of_range_fmt(__N("vector::_M_range_check: __n "
          "(which is %zu) >= this->size() "
          "(which is %zu)"),
          __n, this->size());

}

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

[Wataru]

Rsa97, Sasha_88, Во-первых, библиотечный код, особенно at, компилятор инлайнит почти всегда и его видно. Там cmp, jmp и call __throw_out_of_range_fmt.

Во-вторых, если хочется посмотреть, что там в стандартной библиотеке, можно локально на своем компьютере скомпилировать со статической линковкой, дизассемблировать и посмотреть на весь файл.

Да в том же дебаггере можно запустить программу и зайти внутрь vector::at - можно будет и исходники проверок посмотреть, да и ассемблерный код.

[Sasha_88]

Rsa97, Ладно, фиг с ними с инструкциями ассемблера. Я могу представить, что там на выходе будет. Просто сейчас в мире такая шумиха по поводу безопасности, я и думаю что там такого в коде должно быть, чтобы не приводить как минимум к ошибкам при работе с памятью ну или там к эксплойтам.
И вот про такие функции как strcpy, которые не проверяют ничего. Если к примеру размер буфера будет только во время выполнения известен, то проверка нужна обязательно в таких случаях? Это же распространенный случай, когда на момент компиляции что-то не известно.

[CityCat4]

Sasha_88,

Если к примеру размер буфера будет только во время выполнения известен, то проверка нужна обязательно в таких случаях?

Разумеется. Если буфер забирается malloc-ом, то его размер ты знаешь только при выполнении и именно его ты и отдаешь параметром strncpy(). А есть еще memcpy() и memmove() - ваще магические штуки, если уметь ими пользоваться...