- PVSM.RU - https://www.pvsm.ru -
В прошлой статье [1] мы обсуждали, как процессоры Intel Sandy Bridge отображают физические адреса в кэше L3.
Теперь я расскажу, как контроллеры памяти этих процессоров сопоставляют физические адреса с местоположением в DRAM — в частности, с номерами строк, банков и столбцов в модулях DRAM. Назовём это отображением адресов DRAM. Я использую одну тестовую машину в качестве примера.
Меня интересует отображение адресов DRAM, поскольку оно относится к багу Rowhammer [2].
Rowhammer — проблема с некоторыми модулями DRAM, когда определённые самые плохие модели доступа к памяти могут привести к повреждению памяти. В этих DRAM многократная активация строки памяти («забивание строки») вызывает электрические помехи, меняющие биты в уязвимых ячейках соседних строк.
Эти повторяющиеся активации строк могут быть вызваны многократным доступом к паре адресов DRAM, которые находятся в разных строках одного банка DRAM. Знание отображения адресов DRAM полезно, поскольку оно указывает, какие пары адресов удовлетворяют этому свойству «один банк, разные строки» (same bank, different row; SBDR).
Для теста у меня есть машина с модулями DRAM, уязвимыми к багу Rowhammer. Запуск rowhammer_test [3] на этой машине демонстрирует смену битов.
Я хотел бы знать схему отображения адресов DRAM для этой машины, но она не задокументирована публично: здесь процессор Sandy Bridge, но Intel не документирует отображение адресов, используемое контроллерами памяти этих процессоров.
На самом деле тесту rowhammer_test не нужно знать пары адресов SBDR. Он просто несколько раз пытается забивать случайно выбранные пары адресов. Обычно 1/8 или 1/16 из них оказываются парами SBDR, потому что в нашей машине 8 банков в каждом DIMM (и 16 банков в итоге). Таким образом, нам не нужно знать отображение адресов DRAM, чтобы вызвать смену битов в памяти, но такое знание поможет проводить тест более целенаправленно.
Хотя отображение адресов не задокументировано, я обнаружил, что могу сделать обоснованное предположение о нём на основе геометрии DRAM, а затем проверить предположение на основе физических адресов, о которых сообщает rowhammer_test. Тест сообщает физические адреса, где происходят смены битов («жертвы») и пары физических адресов, которые производят эти смены («агрессоры»). Поскольку эти пары должны быть парами SBDR, мы можем проверить гипотетическое сопоставление адресов с этими эмпирическими данными.
Первый шаг: проверить, сколько DIMM установлено в машине и как они внутренне организованы.
Я могу запросить информацию о DIMM с помощью инструмента decode-dimms в Linux (в Ubuntu он находится в пакете I2C-tools). Этот инструмент декодирует метаданные SPD (Serial Presence Detect) [4] в DIMM.
На моей тестовой машине два четырёхгигабайтных SO-DIMM [5], что даёт 8 ГБ памяти.
Инструмент decode-dimms сообщает следующую информацию для каждого из модулей:
Size 4096 MB Banks x Rows x Columns x Bits 8 x 15 x 10 x 64 Ranks 2
Это означает, что у обоих DIMM:
У каждого DIMM есть 2 ранга и 8 банков. Перекрёстная проверка ёмкости модуля DIMM даёт тот размер, какой и ожидалось:
8 Кбайт в строке * 32768 строк * 2 ранга * 8 банков = 4096 МБ = 4 ГБ
На моём тестовом компьютере биты физических адресов используются следующим образом:
Данное отображение сходится с результатами rowhammer_test (см. ниже), но мы также можем объяснить, что адресные биты сопоставляются таким образом, чтобы обеспечить хорошую производительность для типичных шаблонов доступа к памяти, таких как последовательный доступ (sequential access) и ступенчатый или шаговый доступ (strided access):
Кстати, Ivy Bridge [6] (преемник Sandy Bridge), по-видимому, усложняет отображение номера канала. В презентации Intel [7] упоминается «хэширование каналов» и говорится, что это «позволяет выбирать канал на основе нескольких адресных битов. Исторически оно равнялось “A[6]”. Так обеспечивается более равномерное распределение доступа к памяти по каналам».
Небольшое введение: модули DRAM организованы в банки, которые, в свою очередь, организованы в строки. У каждого банка есть «текущая активированная строка»: её содержимое копируется в буфер строк, который действует как кэш, к которому можно быстро получить доступ. Доступ к другой строке занимает больше времени, потому что её сначала нужно активировать. Итак, при отображении адресов DRAM пары SBDR разносятся как можно дальше в физическом адресном пространстве.
Чеканка строк (row hammering) — частный случай буксования банка, когда попеременно активируются две конкретные строки (возможно, специально).
Схемы XOR'инга для банка/строки описаны в различной литературе, например:
Работа rowhammer_test_ext [10] (расширенная версия rowhammer_test) на тестовой машине в течение 6 часов выявила повторяемую смену битов в 22 местах. (см. исходные данные и код анализа [11]).
Тест чеканки строк генерирует наборы из трёх адресов (A1, A2, V):
Для всех этих результатов мы ожидаем выполнения трёх свойств:
Это свойство позволяет легко определить, где в физическом адресе находятся нижние биты номера строки.
Тест показал, что это свойство выполняется для всех результатов, кроме двух. В этих двух результатах номера строк отличаются на 3, а не на 1.
rowhammer_test выбирает только адреса, выровненные по 4k, и поэтому тестирует только один канал (возможно, это можно считать багом).В будущем можно запустить ещё два эксперимента для проверки, правильно ли отображение адресов DRAM оценивает свойство SBDR:
Кроме того, изъятие одного модуля DIMM из системного блока должно изъять бит канала из отображения адресов DRAM и соответственно изменить адреса агрессора и жертвы. Это тоже можно проверить.
Автор: m1rko
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/300267
Ссылки в тексте:
[1] прошлой статье: http://lackingrhoticity.blogspot.com/2015/04/l3-cache-mapping-on-sandy-bridge-cpus.html
[2] багу Rowhammer: http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[3] rowhammer_test: https://github.com/google/rowhammer-test
[4] SPD (Serial Presence Detect): https://en.wikipedia.org/wiki/Serial_presence_detect
[5] SO-DIMM: https://en.wikipedia.org/wiki/SO-DIMM
[6] Ivy Bridge: https://en.wikipedia.org/wiki/Ivy_Bridge_(microarchitecture)
[7] презентации Intel: http://www.hotchips.org/wp-content/uploads/hc_archives/hc24/HC24-1-Microprocessor/HC24.28.117-HotChips_IvyBridge_Power_04.pdf
[8] «Современные системы памяти DRAM: анализ производительности и алгоритмы планирования»: http://www.ece.umd.edu/~blj/papers/thesis-PhD-wang--DRAM.pdf
[9] «Сокращение задержек DRAM с помощью иерархии интегрированной памяти»: https://impact.asu.edu/cse520fa08/pravin.pdf
[10] rowhammer_test_ext: https://github.com/google/rowhammer-test/tree/master/extended_test
[11] исходные данные и код анализа: https://github.com/google/rowhammer-test/tree/2e35c726fdcf96d5f249094487fd2ba0464d0021/dram_physaddr_mapping
[12] Источник: https://habr.com/post/431102/?utm_campaign=431102
Нажмите здесь для печати.