Обнаружение бит-флип для программной памяти для платформ без ECC

Большинство доступных настольных (дешевых) платформ x86 теперь не имеют поддержки памяти ECC (Проверка ошибок и исправление). Но скорость ошибок бит-флип памяти все еще растет (не лучший поток SO, Large масштабное исследование CERN 2007 "Целостность данных" : "Скорость битовых ошибок 10 ^-12 для их модулей памяти... наблюдаемая частота ошибок на 4 порядка ниже, чем ожидалось"; "Ошибки DRAM в дикой природе: исследование крупномасштабного поля" ). Для текущего аппаратного обеспечения с интенсивной нагрузкой (8 ГБ/с чтения) это означает, что однократная флип может возникать каждую минуту (10 ^-12 поставщиков BER от CERN07) или один раз в два дня (10 ^-16 BER от CERN07). В Google09 говорится, что может быть до 25000-75000 однобитовых FIT на Мбит (неудачи во времени в миллиард часов), что равно 1 - 5 бит в час для 8 ГБ ОЗУ ( "средние исправляемые частоты ошибок 2000- 6000 на ГБ в год" ).

Итак, я хочу знать, возможно ли в какой-либо системе добавить какое-либо обнаружение ошибок программного обеспечения (проверьте как память пользователя, так и ядро). Например, создайте патч для ядра Linux и/или системный компилятор, чтобы добавить некоторые контрольные суммы на каждую страницу памяти и попытаться обнаружить повреждение памяти (бит-флип) путем регулярной перекомпоновки контрольных сумм?

Например, можем ли мы видеть все записи в памяти (как из пространства пользователя, так и из ядра), чтобы различать предполагаемые изменения памяти из бит-бит в памяти? Или мы можем каким-то образом использовать все коды с помощью какого-то помощника?

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

Я также понимаю, что лучший способ защиты данных от битфлипсов памяти - переключиться на аппаратное обеспечение ECC, но на большинстве ПК все еще есть не-ECC.

Ответ 1

Дело в том, что ECC дешево по сравнению с "программными ECC-контрмерами". Вы можете легко определить, есть ли у них модули ECC и жаловаться (или печатать предупреждение), когда они этого не делают.

http://www.cyberciti.biz/faq/ecc-memory-modules/

Например, можем ли мы видеть все записи в памяти (как из пространства пользователя, так и из ядра), чтобы различать предполагаемые изменения памяти из бит-бит в памяти? Или мы можем каким-то образом использовать все коды с помощью какого-то помощника?

Э-э, вы никогда не увидите "битов" на автобусе. Они буквально вызваны частицей, поражающей ОЗУ, немного перевернувшись. Только намного позже вы заметите, что вы зачитали что-то другое, чем написали. Чтобы обнаружить это только через шину, вам понадобится дубликат всей вашей ОЗУ (т.е. Создайте теневую копию того, что находится в вашей реальной ОЗУ, поэтому вы можете проверить, что каждое чтение возвращает то, что было написано в этом месте.)

попытаться обнаружить поврежденные повреждения памяти (бит-флипы) путем регулярной пересчеты контрольных сумм?

У парня Redis есть хорошая рецензия на алгоритм тестирования ОЗУ для проблем. http://antirez.com/news/43 Но это действительно ищет ошибки ОЗУ, а не случайные бит-флип.

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

Чтобы уловить 100% ошибок, каждая запись должна быть предварительно принята путем вычисления контрольной суммы этого блока памяти, а затем сравнения с записанной контрольной суммой (чтобы убедиться, что блок не ухудшился в ОЗУ). Только тогда безопасно делать запись, а затем обновлять контрольную сумму. Как вы можете себе представить, производительность этого будет ужасной (по крайней мере, на 100 раз медленнее).

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

Ну, есть простой способ обнаружить 100% ошибок со стоимостью 50%: просто запустите вычисление на 2 ящика одновременно (или на одной коробке в два разных раза, возможно, с тестом RAM между вами, если вы параноидны.) Если результаты отличаются, вы обнаружили ошибку.

См. также:

https://www.linuxquestions.org/questions/linux-hardware-18/how-to-detect-ecc-memory-errors-under-linux-886011/

Ответ 1

Ответ 2