Какова ошибка DRAM Rowhammer и как я должен рассматривать ее?

Чипы DRAM очень плотно упаковываются. Исследование показало, что соседние биты могут быть зеркально отражены наугад.

  • Какова вероятность ошибки, инициировавшей наугад в чипе DRAM класса сервера с ECC (статья CMU-Intel цитирует, например, номер 9.4x10^-14 для неизвестной микросхемы для одного отказа за год)?
  • Как я знаю, исправлена ли ошибка прежде, чем купить память?
  • Что я должен сделать для противостояния злонамеренным попыткам сделать расширение полномочий, например, арендаторов или непривилегированных пользователей на, например, CentOS 7?

Ссылки:

20
задан 10 March 2015 в 14:43
2 ответа

Цитируемая вами бумага CMU-Intel показывает (на стр. 5), что коэффициент ошибок в значительной степени зависит от номера детали / даты изготовления модуля DRAM и изменяется в 10-1000 раз. Есть также некоторые признаки того, что проблема гораздо менее выражена в недавно (2014) изготовленных чипах.

Цифра '9.4x10^-14', которую вы цитировали, была использована в контексте предложенного теоретического механизма смягчения последствий под названием "PARA" (который может быть похож на существующий механизм смягчения последствий pTRR (pseudo Target Row Refresh)) и не имеет отношения к вашему вопросу, так как PARA не имеет никакого отношения к ECC.

Во второй работе CMU-Intel (стр. 10) упоминается влияние различных алгоритмов ECC на уменьшение ошибок (фактор от 10^2 до 10^5, возможно, гораздо больше при использовании сложных тестов памяти и "защитной маркировки").

ECC эффективно превращает эксплойт Row Hammer в DOS-атаку. 1-битные ошибки будут исправлены с помощью ECC, и как только будет обнаружена некорректируемая 2-битная ошибка, система остановится (предполагая SECDED ECC).

Решение заключается в покупке оборудования, поддерживающего pTRR или TRR. См. текущий пост в блоге Cisco о Row Hammer. По крайней мере, некоторые производители, кажется, имеют один из этих механизмов смягчения, встроенный в их модули DRAM, но держат его глубоко скрытым в своих спецификациях. Чтобы ответить на ваш вопрос: спросите производителя.

Более быстрая частота обновления (32 мс вместо 64 мс) и агрессивные интервалы Patrol Scrub тоже помогут, но окажут влияние на производительность. Но я не знаю никакого серверного оборудования, которое позволило бы на самом деле настроить эти параметры.

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

.
19
ответ дан 2 December 2019 в 20:11

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

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

Сообщается, что «неназванные компании-производители памяти» попытались дать взятку в обмен на то, что Passmark Software не выпустила тест rowhammer в своем инструменте Memtest86.

Аппаратное обеспечение Intel Skylake, как сообщается, более уязвимо, а не менее , для rowhammer, потому что о добавлении добавления новой инструкции clflushopt . Это уже использовалось в rowhammer.js

Даниэль Грусс отвечает на некоторые вопросы здесь о смягчении последствий по состоянию на декабрь 2015 г. (соавтор статьи rowhammer.js ) в этом talk :

  1. Хотя некоторая ОЗУ с ECC менее уязвима для Rowhammer, чем ОЗУ без ECC, другая ОЗУ с ECC более уязвима, чем ОЗУ без ECC ( ссылка на вопрос в видео )
  2. Переключения на более высокую частоту обновления достаточно, чтобы предотвратить возникновение молота с помощью большинства, но не всего оборудования, но не все BIOS позволяют изменять частоту обновления ( ссылка на вопрос в видео ).

В качестве контрмеры это может быть можно будет обнаружить атаку с помощью Rowhammer, но я не знаю, что это было сделано.

4
ответ дан 2 December 2019 в 20:11

Теги

Похожие вопросы