Разработчики ядра Linux обсуждают (https://lkml.org/lkml/2014/12/24/258) реализацию возможного обходного пути защиты от эффекта (ttps://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf) искажения содержимого отдельных битов памяти DRAM (https://ru.wikipedia.org/wiki/DRAM), выявленного исследователями из Университета Карнеги — Меллон и Intel Labs. Исследование показало, что можно легко инициировать повреждение отдельных битов в DRAM-памяти путём цикличного чтения данных из соседних ячеек памяти.
Проблема обусловлена (http://blog.sudhanshumishra.in/2014/12/memory-error-due-to-c... особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора. Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряди применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых ячейке данных.
Пример (http://blog.sudhanshumishra.in/2014/12/memory-error-due-to-c... ассемблерного кода, который может привести к повреждению смежных битов памяти (простой цикл с чтением содержимого памяти и очисткой кэша, чтение двух значений по разным адресам обусловлено необходимостью инициирования закрытия линии WL, если постоянно читать только одну ячейку линия WL остаётся открытой и эффект не проявляется):
<font color="#461b7e">loop:
mov X, %eax ; Читаем значения адресов X и Y,
mov Y, %ebx ; сохраняем значения в регистрах и кэше
clflush (X) ; Чистим содержимое кэша
clflush (Y)
mfence ; Убеждаемся, что данные точно вычищены из кэша
jmp loop</font>
Подобный эффект можно использовать для инициирования атак по искажению данных в буфере, к которому атакующий не имеет доступа, но при этом имеет доступ к смежным с данным буфером областям памяти. Отмечается, что старые чипы DRAM, выпущенные до 2011 года, значительно более устойчивы к возникновению подобных ошибок. Все из более ста протестированных новых модулей памяти, выпущенных в 2012 и 2013 годах, оказались подвержены проблеме. В качестве рекомендации пока предлагается использовать модули памяти с контролем целостности ECC, которые значительно понижают вероятность незамеченного изменения данных, но полностью не исключают, так как возможны ситуации, когда в результате эффекта одновременно два бита могут поменять свои значения.URL: https://lkml.org/lkml/2014/12/24/258
Новость: http://www.opennet.dev/opennews/art.shtml?num=41340
У eeprom тоже есть похожее, ошибка read disturb.
Постоянная вроде как память может потерять сохранённые значения.
Хм. Любопытно если бы кто-то из профильных специалистов провёл эксперимент по целенаправленному изменению данных в памяти с помощью этого метода. Т.е. сделать из ошибки уязвимость.
да, и ещё хорошо бы не на ассемблере, на на более высокоуровневом языке. Например на js.
Чё уж так толсто? Лучше бы сразу на Scala или Lisp.
> да, и ещё хорошо бы не на ассемблереНу так возьми и напиши. Если сможешь обеспечить должную предсказуемость поведения.
думаю не получится - процессорный кэш не сбросится.
А так заходишь на любимый опеннет, загружается js, и Kernel panic..хотя тут проскакивала новость про NaCl.. интересно там можно очищать процессорный кэш?
бабло у производителей заканчивается, вот теперь новую проблему 2000 придумали, бежим в магазины срочно менять память...
> бабло у производителей заканчивается, вот теперь новую проблему 2000 придумали, бежим в
> магазины срочно менять память...Прикольные у покупателей дефектных чипов отмазки нынче :)
http://mobile.opennet.ru/opennews/art.shtml?num=42730
Вообще-то, это дело JEDEC, а не разработчиков ПО.
Дожили. Вот и предел закону Мура.
Что-то там HP-шные маркетологи недавно пытались втереть про мемристоры. Хотя скорее всего и без этого найдут решения… В общем, скорее всего и не предел это вовсе никакой.
На каждый предел найдётся свой беспредел.
> На каждый предел найдётся свой беспредел.а на каждый беспредел свой "индус"
> Дожили. Вот и предел закону Мура.При чем тут вообще Мур? Перец понима как работает DRAM нашел баг в работе кучи чипов оперативки, основанный на том что чипмейкеры не подумали об одном краевом случае...
позвольте полюбопытствовать: а в чем, собственно, этот предел выражается?
чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно распределять память, то есть работать на уровне операционной системы. если есть такой уровень, то зачем геморроиться со всякими зацикливаниями?
> чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно
> распределять память, то есть работать на уровне операционной системы. если есть
> такой уровень, то зачем геморроиться со всякими зацикливаниями?Это принципиальная проблема, которая может приводить к внезапным неполадкам. «Геморроиться» нужно, чтобы изучить проблему получше.
У меня уже не раз было на долгоработающих высоконагруженных серверах ощущение сбоя ОЗУ (либо очень странного бага ядра), хотя, например, memtest показывает, что всё хорошо. Конечно скорее всего не связано с subj-ем, но а вдруг?
Приложение не может адресовать физический адрес в ОЗУ (именно нужную ячейку в микросхеме, для тех, кто далек от программирования) поэтому с вероятностью 99.999999999999999999999999% соседним битом окажется бит самой этой злонамеренной программы, которая сама же себя и завалит.
> Приложение не может адресовать физический адрес в ОЗУ (именно нужную ячейку в
> микросхеме, для тех, кто далек от программирования) поэтому с вероятностью 99.999999999999999999999999%
> соседним битом окажется бит самой этой злонамеренной программы, которая сама же
> себя и завалит.Во-первых, я не узнал ничего нового. Не понимаю зачем вы это написали мне в ответ.
Во-вторых, несмотря на присутствие виртуальной памяти, IIRC, страницы памяти обычно идут сплошными блоками (при отображении физической памяти). А значит некоторый элемент предсказуемости есть.
Во-третьих, в своём комментарии я ничего не говорил про злонамеренную программу. А самым вероятным аналогом «злонамеренной» программы в моём комментарии выступает ядро Linux. Я говорил не про взлом, а про обычный глюк.
> Во-третьих, в своём комментарии я ничего не говорил про злонамеренную программу. А самым вероятным аналогом «злонамеренной» программы в моём комментарии выступает ядро Linux. Я говорил не про взлом, а про обычный глюк.MMU выступает вероятным аналогом.
> memtest показывает, что всё хорошоКстати да, ждём появления проверки этой фигни в следующей версии memtest.
так отпишись им
Стесняюсь спросить - а что мониторинг ecc в этом случае выдавал? Обычно достаточно логи глянуть и сразу ясно - память или нет.
> достаточно логи глянуть и сразу ясно - память или нет.Мониторинг ... чего? В случае ECC там по идее будет много воплей про paity error.
> paity error.^^^^^^ ECC FAIL :(.
проблема - это когда у вас что-то не работает. А это, слава богу, только потенциально низковероятная, высосанная из пальца угроза
> только потенциально низковероятная, высосанная из пальца угрозаПотенциальная возможность уронить (DoS) или атаковать (внеплановое изменене хода выполнения кода) любую систему с DRAM - выглядит интересно.
Тем не менее - маловероятно. Кстати, интереснее всего выглядит возможность неспешной скрытой порчи данных. Это вам не DoS - здесь ни смена железа, ни бэкапы не помогут, когда жареным запахнет.
> Тем не менее - маловероятно.Из очевидного что в голову пришло:
- Неочевидные и наглые попытки объехать на кривой козе secure boot/trust zone/системы прав и привилегий/... путем контролируемого разрушения trusted данных/кода лишь потому что они были рядом с untrusted в DRAM. В ряде случаев это конечно учитывают, но упомянутая багофича нарушает столько програмерских и железячных допущений, что что-то где-то вполне может дать течь и все последствия даже предсказать невозможно - большинство систем элементарно не делалось с учетом таких подстав. Если что - я как-то раз "выигрывал джекпот" через переворот 1 бита в нужное время. Но это требовало хардварного приспособления. А тут нечто такое - софтварно, нахаляву.- Возможность попытаться спровоцировать DoS в системе которая без этого казалась бы трудноубиваемой. Тривиальный и безобидный код без каких либо подозрительных элементов может отправить всю систему в нокаут, одной левой. Даже в таком виде - это уже на уровне F00F бага в пентиумах.
> Тем не менее - маловероятно.проблема с маловероятными случаями обычно в том, что они действительно вылазят очень редко. зато очень метко.
нужный байт нужного приложения достать вряд ли получится, а вот вызвать случайные повреждения памяти других процессов или йадра - вполне реально
> чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно
> распределять память,Это не так. Физическое размещение данных в памяти не имеет ничего общего с адресами в приложениях - операционка транслирует логические адреса приложений в физические адреса в памяти через таблицы трансляций. При некоторой поддержке этого процесса железом. Поэтому вполне может выйти что какой-то кус данных некоей программы оказывается жил в том же чипе DRAM и довольно близко.
Исследование проведено по заказу продавцов памяти с ECC :)вообще ИМХО бред - вся память всех новых компов работает со сбоями уже 3 года, а заметили это только что. Ну не первое ж апреля сегодня.
> Исследование проведено по заказу продавцов памяти с ECC :)
> вообще ИМХО бред - вся память всех новых компов работает со сбоями
> уже 3 года, а заметили это только что. Ну не первое
> ж апреля сегодня.Алгоритм открыт и чрезвычайно прост. Проверьте сами…
что-то не хочется рисковать)
> что-то не хочется рисковать)Могу отсыпать памяти, если нужно)
вы уже проверили?
и как? через какое время содержимое "поплыло"?на самом деле даже если чтото произойдет - не факт что это память виновата.
есть еще многоуровневый кэш, микрокод процессора, да мало ли еще чего.
> вы уже проверили?Я не утверждаю что это херня. Я вполне доверяю тому, что написано (в рамках того, насколько мне требуется достоверно знать "правду" по данному вопросу). А вы видать считаете, что они врут/ошибаются. А ведь они сделали всё возможное, чтобы вы сами могли убедиться. Почему бы не проявить уважение и не воспользоваться предоставленным инструментом, если они врут/ошибаются по-вашему?
Я бы проверил на вашем месте, если бы действительно думал, что это «бред, проведённый по заказу продавцов памяти с ECC».
> и как? через какое время содержимое "поплыло"?
Если я увижу какую-то практическую пользу от данного знания для себя в работе или поводы думать, что это ошибка исследователей, то проверю. А иначе это впустую потраченное время. Ничего не опроверг, ничего нового не узнал и никак это не за чем не применить.
P.S.: Решил таки проверить, но осознал, что у меня везде память с ECC.
> P.S.: Решил таки проверить, но осознал, что у меня везде память с ECC.Так это замечательно - сразу как раз и будут вопли про парити.
У меня с данной программой на личном компе (с i5) в dmesg ничего не высыпалось.Проверил ещё на Xeon E5506. Аналогично ни в dmesg, ни в «edac-util -v» никаких признаков ошибки.
Может что-то не так делаю. Нужно статью прочесть внимательнее…
> вся память всех новых компов работает со сбоями
> уже 3 года, а заметили это только что.Потому что в реальных полезных программах нет таких циклов. Теоретически столкнуться с проблемой возможно, практически — нет.
на практике эта "фича", в первую очередь, появится в вирусне.
то есть память не читается много раз подряд. Хорошо, в компах возможно(хотя тоже сомнительно) но DRAM в разных местах используется.К тому же мне думается речь идет про время между циклами регенирации (~10мс), что при частоте выборки 1ггц дает как я понимаю всего 2-3 выборки из одной и той же ячейки согласно приведенному алгоритму при 32битных счетчиках. 2 выборки за 10мс не встречаются? смешно.
Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе и теперь исследует результат?
А насколько часто в реальных приложениях сбрасывается кэш?
> то есть память не читается много раз подряд.вообще-то она попадает в кэш процессора, и потом всё читается уже оттуда. поэтому вероятность в «обычном» коде налететь на такое весьма невелика. именно поэтому пример усердно чистит этот самый кэш.
> Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе
> и теперь исследует результат?может, ты всё-таки перестанешь бредить?
> Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе
> и теперь исследует результат?А вон тот допатченый мемтест86, запускаемый бутлоадером БЕЗ ВСЯКИХ ОПЕРАЦИОНОК как в ваш бред вписывается?
Да не, в обычном случае данные из кэша возмутся после 1 итерации, а там статическая память
Звонок в службу поддержки производителя памяти:
- Здравствуйте! У нас ОС ошибками на счет памяти сыпёт!?!?!? Что делать?
- Фамилия?
- Человечьков.
- Что то таких не знаем! А, вот, где то, на задворках ваша "Человечковская" организация.
- Ну слава Богу!
- Сейчас посмотрим... Вы покупали "трехгодичную" память.
- Да.
- Это было три года, три месяца и три дня назад?
- Да.
- .....
- ..........
- Ну в общем, ждем вас снова. Только в этот раз, забивайте чемодан под завязку, купюрами более крупного достоинства ;) Может все и уладится.
По-моему, ты болен.
> По-моему, ты болен.Хорошо! Пусть будет по вашему. Буду болеть, на здоровье!
Главное, что бы количество больных не превысило критическую массу (особенно среди производителей памяти ;)
Пелевенит.
Вы льстите автору сего опуса. Скорее уж петросянит с осложнением в виде графомании.
> Вы льстите автору сего опуса. Скорее уж петросянит с осложнением в виде
> графомании.Да. Захотелось улыбнутся (что бы так грустно не было ;)
> По-моему, ты болен.я не болен.
я спец по написанию диссертаций.
профессия.
"Спец по написанию диссертаций" - это либо диагноз, либо приговор, т.к. деяние сие по сговору, за третьих лиц, наказуемо, а в личных целях больше двух диссеров иметь не логично, так что точно не "профессия".
> деяние сие по сговору, за третьих лиц, наказуемоПруф? По-моему даже если официально выставить счет на "подготовку диссертации", официально получить за это деньги (ну и официально заплатить с этого налоги) - ничего не будет.
> я спец по написанию диссертаций.
> профессия.За тобой диссернет тоже придет...
что за поток мыслей?
Где ты тут мысли увидел? :)
на столько тонкая шутка, что режет на пополам сам бозон Хиггса
>на столькоправильно надо писать так: на стол ько
>Разработчики ядра Linux обсуждаютда уж... две бабки в Linux Kernel Mailing List написали по три сообщения, и об этом знаменательном событии уже пишут на опеннете
Если б приподъездные бабки вдруг обвиртуалились, то повреждения ячеек памяти увеличилось бы многократно, и ошибки наблюдались бы повсеместно )
> да уж... две бабки в Linux Kernel Mailing List
> написали по три сообщения, и об этом знаменательном
> событии уже пишут на опеннете-- А вы слышали: ячейка DRAM повредила своё содержимое циклическим чтением!
-- Наркоманка навреное.
похоже Нео съел таки красную таблетку...
Архитектура какая? Сгнившая intel x86/64?
Для RISC(PowerPC, ARM и иже с ними) работает? 99.9% что не работает.
> Архитектура какая?DRAM, туюмеме. Почитай ,pdf-чик?
> Сгнившая intel x86/64?
Ну, они [пишут в .pdf, что] "гоняли" на intel(-ах =смотрели на разницу между моделями), amd и самопальном _FPGA_.
> Для RISC(PowerPC, ARM и иже с ними) работает? 99.9% что не работает.
Да! Ваши графики впечатляют. Распределение наблюдаемого параметра однозначно подтверждает Ваши выаоды. Работа, достойная публикации на </opennet>.
там какая-то особенная память используется? при чем тут вообще процессоры?
>> при чем тут вообще процессоры?
> loop:
> mov X, %eax ; Читаем значения адресов X и Y,
> ...а с чем повашему работает память с ядром ?
кто манипулирует mov и так дальше инструкциями ?
тут и линукс не причем и процессор непричем, так что причем и как оно работает ?
DRAM - он и в Африке DRAM, с кем бы о ни работал, хоть с принтером на MIPS'е. Правда, у MIPS'а может силенок не хватить, чтобы зачитать ячейку до дыр до цикла рефреша.
давно так не смеялся
> давно так не смеялсяБояздэшники же. С putty.exe. И bOOster и IMHO. Два сапога пара.
> Бояздэшники же. С putty.exe. И bOOster и IMHO. Два сапога пара.Да какие они сапоги? Так, носки...
> Да какие они сапоги? Так, носки...Портянки. Проприетарщиков.
проблема в памяти, понимаешь в памяти? любой процессор работает с памятью, любая операционная система работает с памятью. почему ты так тупишь? не надо так.
> тут и линукс не причем и процессор непричем, так что причем и
> как оно работает ?При чем только сам паттерн доступа к памяти. Точка. Его можно сделать под разными ОС и из процссоров разных архитектур. Они вон как PoC даже на FPGA сделали. Какая у FPGA долбящейся в DRAM архитектура?
> Архитектура какая?какая разница, главное не линукс ))))
> какая разница, главное не линукс ))))Чемпионат бояздэшных ламаков по тормозизму на опеннете объявляется открытым!
> Архитектура какая? Сгнившая intel x86/64?Дядя, ты дypaк? Какая арзитектура у DRAM? (вопросы риторические)
Такую последовательность команд чтения DRAM можно закатить на более-менее любой архитектуре умеющей работать с DRAM - это технический дефект DRAM .
> Для RISC(PowerPC, ARM и иже с ними) работает?А, что на "RISC(PowerPC, ARM и иже с ними)" твои бздя с вендой работают?
>> Для RISC(PowerPC, ARM и иже с ними) работает?
> А, что на "RISC(PowerPC, ARM и иже с ними)" твои бздя с
> вендой работают?таки да.
> таки да.Боюсь что с доказательством этого тезиса на практике будет напряжно. Всякие вендофоны и RT не умеют винапи и потому от винды там в основном название. Да и wm не сильно лучше. С бздами не сильно лучше - плевок сообщений в uart и старт процессорногоядра - это далеко не все, что как правило хотят увидеть пользователи.
> Боюсь что с доказательством этого тезиса на практике будет напряжно. Всякие вендофоны
> и RT не умеют винапи и потому от винды там в
> основном название.о, пошёл любимый раскрут: скрытые условия. было спрошено про что? про винду. RT — вполне официальная винда. case closed.
> С бздами не
> сильно лучше - плевок сообщений в uart и старт процессорногоядра -
> это далеко не все, что как правило хотят увидеть пользователи.запускается? работает? в скрытые условия играй сам с собой. case closed.
> RT — вполне официальная винда. case closed.Ну ок, винда так винда. Удачи тебе в использовании этой винды. А так та да, маркетологи любят называть любое гуано на основе уже раскрученного бренда. Так появляются всякие дум 3, HMM5, windows RT и прочее. А то что от оригинала там нифига и не осталось - можно особо и не уточнять.
> запускается? работает? в скрытые условия играй сам с собой. case closed.
Главное понятие "работать" выбирать правильно :).
эта дырень -- теперь будет обнаруживаться в новых версиях memtest86\memtest86+ ?
Напоминает то, как делали дискеты. Некоторые годами работали без сбойных секторов. А потом все 100% стали повреждаться после первого использования.Можно вспомнить мнжество других носителей данных. Картринди для Денди. Раздил? Не важно: платка большая, вставляй так. А потом они становились всё меньше, и меньше, и меньше...
Память нынче дешёвая, говорите? СЛИШКОМ дешёвая.
Дейтствительно - почему дискеты, стоившие доллар, были надёжные (и крутились в дисководах стоимостью 40 долларов), а после рапростраенния писалок, когда дискеты стали по 10 центов, а дисководы - по 10 баксов - вдруг стали ненадёжными. Конечно, люди покупали бы дискеты втрое дороже, чем CD-R, угу.Конспирология и включение мозга несовместимы.
В чём ваша позиция? Я ни чего не понял.
> В чём ваша позиция? Я ни чего не понял.Наверное перец намекал что качество изготовления механики за 10 баксов и за 40 немного отличается. Да и электроники пожалуй тоже.
Но цена зависит не только от качества, но и от технологии изготовления, конкуренции...
> Но цена зависит не только от качества, но и от технологии изготовления,
> конкуренции...Однако если раздраконить флоп за 10 баксов и за 40, разница в качестве изготовления скажет за себя сама.
>> Но цена зависит не только от качества, но и от технологии изготовления,
>> конкуренции...
> Однако если раздраконить флоп за 10 баксов и за 40, разница в
> качестве изготовления скажет за себя сама.В смысле, независимо от цены, от "раздраконивания" придут в негодность оба? :D
который за десять — сам развалится. который за сорок — придётся молотком.
> В смысле, независимо от цены, от "раздраконивания" придут в негодность оба? :DВ смысле, раздраконив десятибаксовый - увидим гуано которое противно в руки брать.
- Необработанный металл с заусенцами, выглядящий как жестянка. Ведь обработка денег стоит. Копейки, но при 10 баксах на все - каждый цент на счету.- Максимально удешевленная печатка, заставляющая вспоминать СССРовскую промышленность и подвальный китай, ибо там может оказаться ссaный гетинакс (по сути прессованый картон) как в гунявой китаезной магнитоле. Стеклотекстолит - больно жирно. Ну подумаешь немного менее влагостойко, все дела. Зато пару центов сэкономили. Да и фрезы на станках поменьше изнашиваются (одно дело фрезеровать стеклотекстолит и другое - прессованый картон).
- Двигатель с алюминиевой обмоткой и ротором чуть ли не из консервной банки. Нуачо, как-то крутит вроде.
- Механика из г-на и палок.
- Кривые головы, юстировкой которых занимался клевавший носом рабочий, над которым надзиратель с кнутом орал "работать, китайцы! солнце еще высоко!".
Как все это работает - думаю понятно. Чтение и запись - на грани фола, малейшая неидеальность - получите read error. Ну то-есть записать 1 дискету в год может и сойдет. Если конечно в дискете при этом не протрется дырка а юстировка голов на этом 10-баксовом флопе не окажется диаметрально противоположной тому 10-баксовому флопу для которого флоп делался, иначе может не прочитаться вообще.
Ну а агрегат за 40 баксов - порадует глаз качественной механикой и печаткой, аккуратным движком, там уж как-нибудь работяга головы на место поставит нормально и прочее. Аналогичная фигня с сидюками и даже дешевыми моделями хардов.
Это когда разница в цене - единицы-десятки процентов, а не когда её надо срезать в разы.Плюс к тому - требования потребителей к надежности дискет рехко снизились, опять же из-за писалок. Последние лет пять жизни дискет я их видел исключительно в двух ситуациях - сдача отчета в дремучую налоговую или сдача электронного варианта диплома в дремучий ВУЗ. И там, и там - однократная запись и однократное чтение. На это дискет вполне хватало.
Гы. А некоторые бухи года до 2010 так отчеты носили... И высрись, но найди им чистую дискету ))) Я уж в свои запасы залезал ) Нашлись с дровами неюзанные дискетки.
Что, за бред. Для этого и существует кэш процессора, контролёры памяти, да и частота регенерации устанавливается согласно частоте конкретных модулей памяти. Частота выборки не может превышать эту частоту, а точнее не должна превышать и раз уж вы разгоняете озу так и получайте ошибки тогда. Какое-то извращённое преподавание основ микроэлектроники нам показали.
> Частота выборки не может превышать эту частоту, а точнее не должна превышатьПодзарядка конденсатора ячейки во время регенерации не мгновенный процесс. Не успевает регенерация компенсировать токи утечки, компренде?
Регенерация суть чтение (точнее прозрачно происходящая процедура чтения и обратной записи, причем по всей строке сразу). Поэтому либо память регенерируется, либо не работает. Функции чтения/записи представляют собой половинки процедуры регенерации (мультиплексируется по разному).Данная плюха - косяк арбитра шины который при постоянной выборке одного адреса забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.
Эти конфликты по шине первый раз еще 40 лет назад на 8-битных машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.
>Регенерация суть чтение (точнее прозрачно происходящая процедура чтения и обратной записи, причем по всей строке сразу). Поэтому либо память регенерируется, либо не работает. Функции чтения/записи представляют собой половинки процедуры регенерации (мультиплексируется по разному).
>Данная плюха - косяк арбитра шины который при постоянной выборке одного адреса забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.
>Эти конфликты по шине первый раз еще 40 лет назад на 8-битных машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.Прочел на одном дыхании. Давно так не цеплял интерес коментарии человека. Пиши еще!!
>косяк арбитра шины который при постоянной выборке одного адреса
> забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.
> машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.Не арбитр, а ~"мотсики"~. Не "забывает [регенерацию сделать]", а "увеличивает[изредка + если сильно напрячься] утечки в/с соседних ячеек".
"""When a wordline’s voltage is toggled repeatedly, some cells in nearby rows leak charge at a much faster rate.
> Эти конфликты по шине первый раз еще 40 лет назад на 8-битных
Везде-то Вы, тов.прапорщик, побывали!
> """When a wordline’s voltage is toggled repeatedly, some cells in nearby rows
> leak charge at a much faster rate.Ответьте себе на вопрос почему портится не та ячкйка, которая читается, а те которые рядом, и вам снизойдет просветление.
Да, был везде. Во всяком случае на такие грабли наступал лично. Только на меньших скоростях при подобных конфликтах память рассыпается вся, а не частично.
Самый приснопамятный косяк с арбитражом был воплощен в конструкции CGA видеоадаптера. Там правда портилось не содержимое видеопамяти а само изображение, но принцип тот-же, и вывод картинки в этом смысле от регенерации не отличается (более того именно через него она и реализована). Джедаи постарше этот "снег" хорошо помнят.
> Да, был везде. Во всяком случае на такие грабли наступал лично.Дядьку, тут прикол в том что все доступы - в пределах регламентов из даташитов. Просто как оказалось - можно вызвать столь сильные утечки, что когда приедет очередной цикл регенерации (который никуда деваться не собирался) - регенерировать уже нечего. И вот это как бы подстава, ибо об этом создателей контроллеов DRAM никто не предупреждал.
> Только на меньших скоростях при подобных конфликтах память рассыпается вся, а не
> частично.Одно дело если цикл регенерации не случился и другое - если он случился, но как оказалось этого недостаточно для неких хитрых краевых условий.
Так для этого и согласовывают все компоненты в системе, а не ставят колёса от велосипеда на самосвал.
> Для этого и существует кэш процессора,...который сбрасывают, вы подумайте хитрецы! :)
> контролёры памяти, да и частота регенерации устанавливается
> согласно частоте конкретных модулей памяти.Так оказалось что можно создать условия когда заряд утечет быстрее чем регенерируется при помощи хитрого паттерна доступа.
> Частота выборки не может превышать эту частоту,
Это кто вам сказал такую глупость?
>> Частота выборки не может превышать эту частоту,
> Это кто вам сказал такую глупость?он до сих пор верит, что всем компом управляет один кварцевый генератор.
Эта тема имеет большое значение для производителей маршрутизаторов и коммутаторов (больших понятное дело, не домашних). Там и так задолбались уже бороться с единичными отказами памяти. И ситуация постоянного чтения одних и тех же ячеек DRAM для коммутатора с высокой постоянной нагрузкой более вероятна, чем для PC.
> больших понятное дело, не домашнихв таких коммутаторах часто SRAM используют.
Описание конечно бредовое, я так понимаю, что поскольку конденсаторы находятся "рядом" и влияют друг на друга, то изменение состояния соседнего может вызвать утечку заряда с соседнего(близко расположенного), но в любом случае утечка через транзистор должна быть гораздо больше. Так что это или разгон или недоработка производителей памяти...
> недоработка производителейэто
Фееричное гонево. Для регенерации достаточно выставить адрес столбца (даже чип не обязательно выбирать). Все. Было чтение, не было чтения - сугубо перпендикулярно.Если уж совсем на пальцах и сфероконично, то механизм регенерации работает как раз через чтение.
Обсасывают эту тему в интернетах месяц уже. И за месяц не нашли хотя-бы одного человека который бы щитодату на dram микросхему прочел.
> Фееричное гонево. Для регенерации достаточно выставить адрес столбца (даже чип не обязательно
> выбирать). Все. Было чтение, не было чтения - сугубо перпендикулярно.
> Если уж совсем на пальцах и сфероконично, то механизм регенерации работает как
> раз через чтение.
> Обсасывают эту тему в интернетах месяц уже. И за месяц не нашли
> хотя-бы одного человека который бы щитодату на dram микросхему прочел.Даташит похоже здесь не причем. Просто емкости стали настолько маленькими и настолько расположены близко к друг другу, плюс видимо токи утечки и наводки от соседних цепей и цепей управления стали больше (в процентном отношении). Так что и контролер DRAM с его регенерацией скорее всего не виноват.
Производителям необходимо более подробно разобраться где у них "косяки". И подправить в Консерватории.
> Производителям необходимо более подробно разобраться где у них "косяки". И подправить в
> Консерватории.собственно, производители рассчитывают, что:
1. так никто делать не будет.
2. а если и будет, то читалка имеет свой кэш, поэтому так никто делать не будет.
Все проще, кэп. Когда нынче делается чип - там столько тонкостей, что точно замерять и характеризовать не могут и куда более очевидные параметры. Гонка емкостей и техпроцессов и прочая ставит свои рамки. Поэтому в даташитах все чаще встречается "TBD" для намного более очевидных параметров которые несложно померять для 1 чипа но сложнее сделать какие-то выводы и что-то гарантировать для целой партии.А тут какой-то перец из универа. Он явно в курсе как это работает. И озаботился вопросом креативного поиска worst case с использованием явления которое чипмейкеры могли вообще не брать во внимание и не характеризовывать в даташите вообще. А тут возьми и окажись что особо хитрый паттерн доступа за счет упомянутого эффекта способен вылезти за окно стабильной работы при регламентированных производителем циклах регенерации. Потому что скорее всего никто сроду и не думал о том что паразитные утечки могут жизнь испортить, если их целенаправленно гнать на максимум характерным паттерном. А поскольку в реальных ситуациях такие паттерны "крайне маловероятны" - обычное тестирование никаких дефектов не выявило и все были железно уверены что с чипами все ок и можно идти их продавать.
это никак не противоречит тому, что я написал. собственно, это и есть именно то, что я написал.
> именно то, что я написал.Не, не то. Я думаю что эти лабухи не "рассчитывали на", а "вообще не подумали про". В отличие от сообразительного кекса из универа, который нащупал ядреный worst case.
это примерно одно и то же. «не рассчитывали на» обозначает — в том числе — не только «давайте мы это выкинем», а и «нет никакого смысла думать об этом».
> хотя-бы одного человека который бы щитодату на dram микросхему прочел.А как ты себе представляешь написание работы с DRAM из FPGA без чтения даташита?
Судя по всему как раз почитали и очень креативно подумали что вон тот момент моли не учесть. При том очень хорошо понимая как это работает и какие там могут быть слабые места. Упомянутая утечка как я понимаю вообще не нормируется в даташитах и нигде не упоминается что такой патерн доступа чемто плох. Ясен фиг, производители контроллеров памяти и не парились недокументированной особенностью.
Да, вдогон, что касается "примера с чтением" - пущай разбираются в арбитре шины на глюкавой архитектуре, из-за чего у них при выборе адреса регенерация останавливается.
> шины на глюкавой архитектуре, из-за чего у них при выборе адреса
> регенерация останавливается.Вот прям на х86 системе и FPGA? Кому из них арбитраж чинить?
Да на любой системе. Проблема не в памяти.
> Да на любой системе. Проблема не в памяти.Ну да, конечно. Это контроллер виноват что у памяти нашелся недокументированный метод вызвать повышенные утечки, настолько крутые что к моменту очередной регенерации бит уже может перевернуться.
Кто там хотел тестилку на memtest?Собственно от одного из авторов статьи:
Memory tester for DRAM disturbance errors. Built on top of Memtest86+ v5.01. Also provides dataset for Kim et al., ISCA 2014.
http://github.com/CMU-SAFARI/rowhammer
> Кто там хотел тестилку на memtest?это конечно хорошо что есть способы затестить у себя память через нестандартный скрипт..
..но если (когда) сделают тест внутри официальных Memtest86\Memtest86+ -- то можно будет планки памяти возвращать в магазин обратно и требовать деньги (или замену), с фразой "прогнал мемтестом, показало ошибку.. ваша память говно.. давайте деньги обратно или не-бракованную-память"
а если лишь только нестандартный скрипт (или пропатченный Memtest86+) покажет ошибку -- то с таким результатом планку вернуть в магазин получится врядли
Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.
>Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.нельзя
>>Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.
> нельзяможно. примерно в тридцатидневный срок. или двухнедельный, не помню. возврату не подлежат медикаменты, еда и ещё какая-то фигня, список есть в соответствующих нормах. всё остальное можно вернуть — при условии, что «товарный вид» не испорчен и коробка не сломана (у кого есть коробка; картонные ящики не считают обычно).
причём насколько я помню, надписью «купленый товар возврату и обмену не подлежит» продавец может смачно подтереться, если товар не входит в список не подлежащих.
Не путайте возврат качественного товара, не подошедшего по какой-то причине, и возврат товара с выявившимися недостатками.
не разговаривай больше с зеркалом, это странно выглядит.
> не разговаривай больше с зеркалом, это странно выглядит.Извини, зеркало, не буду.
Если дивайс признаётся технически сложным, то нет, вернуть товар _надлежащего качества_ нельзя.
> можно. примерно в тридцатидневный срок. или двухнедельный, не помнюкакой ещё двухнедельный срок?
ты память мог купить ,например, полтора года тому назад (гарантия ещё действует).
а теперь прогонишь эту память уже современным тестом (в который *теперь* уже вклчили "row hammer test")... и если этот тест покажет FAIL -- то можно память будет поменять или взять деньги.
вот о чём разговор.
дебил, приучись сорок два раза читать то, на что отвечаешь, а потом всё равно молчать.
глупенький, я ответил на всё то что нужно
нудк ECC никогда блажью и не было ;)
и в теперяшнем, крайне урезанно виде - суровый компромисс.
но попробуйте обьяснить это кому-то из intel, например, люто урезающих контроллеры DRAM в своих процах или других вендорам. причем экономия кремения - мизерная, если вдумчиво посчитать, а узякое место не только в плане надежности/безопасности у систем получается и область применения, соотв.
Покуда локомотивом полупроводниковой индустрии будут такие криворукие предприятия как интел, мы все будем люто плавать в аппаратных ошибках.
У интела как не срачка (RDRAM), то болячка (NetBurst). А в перерывах - триппер (недоAtom и т.п.).
> Покуда локомотивом полупроводниковой индустрии будут такие криворукие предприятия как
> интел, мы все будем люто плавать в аппаратных ошибках.у тебя есть Хитрый План?
> у тебя есть Хитрый План?Пилково!
Если они локомотив - а они впереди всех и технологически и в доле рынка - то какие они, на фиг криворукие?P.S. При чём здесь вообще Интел?
> Если они локомотив - а они впереди всех и технологически и в
> доле рынка - то какие они, на фиг криворукие?
> P.S. При чём здесь вообще Интел?Гипертрейдинг и реально на интелах работает неадекватно (10GbE роутеры)
> Гипертрейдинг«hyper trading»? Может всё-таки «hyper threading» [ˈhaɪpər ˈθrɛdɪŋ]?
> и реально на интелах работает неадекватно (10GbE роутеры)
Чего неадекватного? Много раз тестировал на разных процессорах. Очень даже предсказуемо и адекватно.
> P.S. При чём здесь вообще Интел?_1_ соавтор из Intel Labs.
Yoongu Kim 1
Ross Daly *
Jeremie Kim 1
Chris Fallin *
Ji Hye Lee 1
Donghyuk Lee 1
Chris Wilkerson 2
Konrad Lai
Onur Mutlu 1
1 - Carnegie Mellon University2 - Intel Labs
* - Work done while at Carnegie Mellon University.
У вас бомбит, наверное процессор AMD сгорел?
http://www.opennet.dev/opennews/art.shtml?num=41340 компильнул отсюда программу. Пока гоняю и вроде ничего пока не вылезает. Что надо сделать, чтобы оно сработало?
Ссылкой ошибся. Вот правильная https://lkml.org/lkml/2014/12/24/279
Проверка уязвимости в userspace
http://pastebin.com/AnYkW566
У меня на домашнем серваке i3+4г дальше 12й итерации не доходило
i7 2600K @ 4.2 GHz, Corsair DDR3 @ 1800 MHz, тест пройден.
Компилировать надо с -O1, -O2, -O3?
> Компилировать надо с -O1, -O2, -O3?Похрену: критичный код на ассемблере и volatile. Оптимизатор просто не имеет права его трогать.
>> Компилировать надо с -O1, -O2, -O3?
> Похрену: критичный код на ассемблере и volatile. Оптимизатор просто не имеет права
> его трогать.Дану! Ниужто ктото созрел проверить? А мультиядерная система может жить без кеша?
Intel i5 2500, Corsair 1600MHz@1.4V DDR3 4x4GB - ошибок нет после 24 итераций. Надоело ждать.// b.
> Проверка уязвимости в userspace
> http://pastebin.com/AnYkW566
> У меня на домашнем серваке i3+4г дальше 12й итерации не доходилоНе уязвимость. Неисправность оборудования.
Причём объяснения, приведённые в статье (Sudhanshu Mishra), не обязательно правильны.
По факту код делает стрес-тест памяти и контролера. И возникающие ошибки значат лишь, что всё это оборудование по факту не может работать под такой нагрузкой по каким-то причинам :-)
И у разных фирм дело обстоит по разному. Некоторые вполне могут заведомый брак подсовывать...
> По факту код делает стрес-тест памяти и контролера. И возникающие ошибки значат лишь,
> что всё это оборудование по факту не может работать под такой нагрузкой по каким-то
> причинам :-)если оборудование во время стрес-теста ведёт себя некорректно, ...
...то это значит что в нормальных условиях -- это оборудование *тоже* будет вести себя некорректно, но лишь в редкие моменты. например раз в неделю сбой. или раз в месяц.
> Проверка уязвимости в userspace
> http://pastebin.com/AnYkW566
> У меня на домашнем серваке i3+4г дальше 12й итерации не доходилоПроверка уязвимости тоже не совсем неуязвима...
Я за SRAM.
> Я за SRAM.С ним одна проблема - бартер будет выглядеть как 1 модуль на 1 чемодан денег :). Т.к. емкость SRAM сильно ниже -> для достижения той же емкости чипов надо сильно больше.
Ого, вот это простор для эксплоитов, если есть доступ к R/O memory...
Косяк разработчиков памяти. Этот тест должен быть добавлен в штатную сборку memtest 86+
Осилил. i7 в ноутбуке.
#31 ........................................OK
#32 ........................................OK
#33 .DRAM seems works fine...
> #33 .DRAM seems works fine...Аналогично.
Core i3, 4+2 Gb DDR3, Acer (C) 2014.
Нас обманули, пацаны, расходимся... Опять Линукс не взломался, ну что такое ((( Я даже под рутом запустил специально.