«Убийца-противник» для распределителей памяти? - PullRequest
17 голосов
/ 24 марта 2011

Прочитав этот вопрос о кажущемся вырожденном поведении для распределителя памяти Windows и вспомнив эту статью о построении входных данных для наихудшего случая для реализации быстрой сортировки, я начал задаваться вопросом: Можно ли построить программу, которая, учитывая распределитель памяти черного ящика, заставляет этот распределитель отклонять запрос на выделение, даже если в системе еще достаточно памяти? То есть возможно ли взять черный распределитель памяти и заставить его выйти из строя?

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

Есть идеи / мысли о том, как это сделать?

1 Ответ

2 голосов
/ 24 марта 2011

Зависит от того, что вы подразумеваете под «достаточным объемом доступной памяти».Для простой фрагментарной «атаки»:

  • Выделите 15 000 small распределений, пока не произойдет сбой [*].

  • Теперь сортируйте ихв порядке адреса [**].

  • Свободных 100 альтернативных распределений.

  • Попытка выделить 100*small байтов.

Скорее всего, распределителю не удастся найти непрерывную память для ее удовлетворения.Если он имеет размер страницы small и много виртуального адресного пространства по сравнению с физической памятью, он может изменить положение вещей, чтобы сделать это, но для этого требуются возможности MMU поверх любой стратегии антифрагментации со стороныallocator.

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

[*] возможная проблема - чрезмерная фиксация распределителей памяти может не дать сбоя, вы просто получаете segfault или ваш процесс убит.В таких системах вам может потребоваться отслеживать объем доступной памяти.

[**] возможная проблема - в C и C ++ operator< не гарантированно будет работать.Но почти на всех системах это так, а в C ++ тоже есть std::less.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...