Row hammer: причина сбоев DDR3
Недавно был обнаружен новый механизм сбоев DDR3 памяти и его удачно назвали Row hammer. Сбой происходит когда большое количество активаций некой строки памяти влияет на заряд конденсаторов близлежащих строк вплоть до изменения логического состояния битов в ней. Активации «выбивают» заряд. Картинка — Marc Greenberg
Спецификации DDR3 никак не запрещают row hammering, и производители никак не тестируют свои микросхемы на предмет появления этого эффекта, хотя, очевидно, что он существенен. Вот, к примеру, код:
Вполне может повлиять на содержимое памяти даже не принадлежащей текущему процессу. Самое интересное, что тесты памяти которые используются сейчас не могут найти такие ошибки.
ECC тут тоже не особо поможет. Дело в том, что ECC (кроме того, что дорогой и медленный) может исправить ошибку всего в 1 бит. А когда происходит Row hammering портится вся строка. Скорее-всего, при этом контроллер просто обнаружит ошибку, а дальше все будет зависеть от того, как эта ошибка обработается.
А почему-же мы не видим этой ошибки каждый день, работая за компьютером? Дело в том, что в современных процессорах есть кэш и ячейка памяти к которой необходим постоянный доступ просто «переносятся» во внутреннюю SRAM процессора. А вот если вы разрабатываете систему с ПЛИС, где непосредственно управляете контроллером памяти, то придется задуматься, как бы избежать этой проблемы. Самое очевидное решение — перенести память к которой будет постоянный доступ во внутреннюю память ПЛИС или во внешний SRAM.
Вот видео от производителя девайса для обнаружения Row hammer:
И пара статей на тему:
Achieve Reliability, Availability, And Serviceability For Memory Interfaces
The Known Failure Mechanism in DDR3 memory called “Row Hammer”
Спецификации DDR3 никак не запрещают row hammering, и производители никак не тестируют свои микросхемы на предмет появления этого эффекта, хотя, очевидно, что он существенен. Вот, к примеру, код:
volatile int i=100500;
while(i--) {}
Вполне может повлиять на содержимое памяти даже не принадлежащей текущему процессу. Самое интересное, что тесты памяти которые используются сейчас не могут найти такие ошибки.
ECC тут тоже не особо поможет. Дело в том, что ECC (кроме того, что дорогой и медленный) может исправить ошибку всего в 1 бит. А когда происходит Row hammering портится вся строка. Скорее-всего, при этом контроллер просто обнаружит ошибку, а дальше все будет зависеть от того, как эта ошибка обработается.
А почему-же мы не видим этой ошибки каждый день, работая за компьютером? Дело в том, что в современных процессорах есть кэш и ячейка памяти к которой необходим постоянный доступ просто «переносятся» во внутреннюю SRAM процессора. А вот если вы разрабатываете систему с ПЛИС, где непосредственно управляете контроллером памяти, то придется задуматься, как бы избежать этой проблемы. Самое очевидное решение — перенести память к которой будет постоянный доступ во внутреннюю память ПЛИС или во внешний SRAM.
Вот видео от производителя девайса для обнаружения Row hammer:
И пара статей на тему:
Achieve Reliability, Availability, And Serviceability For Memory Interfaces
The Known Failure Mechanism in DDR3 memory called “Row Hammer”
8 комментариев