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

Do you need physical access for ECCploit?

No. While we use several techniques that require physical access to reverse engineer the ECC engine, the attack works via an unprivileged remote shell. The gist is that an attacker gathers information about the ECC engine in his own secluded/controlled environment that is similar to the target system. Then, using this information, they can launch the attack.

А кому они сейчас интересны? Сейчас даже в роутерах за 15 баксов с али DDR3 везде. Производить археологические раскопки - мало мотивации. Так что забутявив дос на 286 ты можешь побыть в относительной безпасности неуловимого джо. Пока кто-нибудь не найдет на древней дискете вирус.

"На рабочих системах для поиска необходимого сочетания изменяемых бит может потребоваться до одной недели" - Так Вам легче?

SSH жутко тупил на передаче файлов

забил сгенерировал сертификат, запретил логиниться по паролю

шчастя

Zen это тот который AMD?

Тогда все плохо - только Epyc или Ryzen версии Pro (которых я в рознице не видел)

Ниоткуда не следует. Кто сказал что шифрование нельзя спровоцировать на неудачные доступы к памяти? При этом даже детали его работы знать не обязательно, методом черного ящика нащупать проблемные доступы - и порядок.

Интересуясь выше о гипотетических экспериментах такого рода над морально устаревшими типами DRAM, я подразумеваю, что миниатюризация и высокие скорости не всегда во благо, как про то вещают рекламы. Например, для DRAM это не на пользу: из тощей ячейки заряд быстрее утекает, чем из жирной. И латентность возрастает до кошмарных значений. Нам-то сказывают о высокой скорости «новых типов ОЗУ», а на самом деле речь о пропускной способности, о ширине шины — и более ни о чём. Если юзернейм работает с огромными кусками мультимедийных данных, ему это может быть на пользу, поскольку они как бы быстрее туда-сюда ворочаются (а дальше все вопросы к CPU), а если тихонько и по-старому — то нет. Ведь у чипов-то «внутренняя» скорость не менялась уже многие годы. Вреда много получается от их большой скорости.

...
> Ок, ecc сбоит в каких-то экслюзивных случаях, а обычная - постоянно?

Sun своими ультаспарками на эти грабли еще 20 лет назад налетела:
http://www.sparcproductdirectory.com/artic-2001-dec-1.html
> Sun's CEO Scott McNealy seems to draw a line under the problem, which Sun now blames on process or design problems in the high speed SRAM chips its was buying from IBM to use in its cache. [B]Sun claims that data bits in the IBM supplied SRAM were being randomly flipped by alpha particles[/B].

[...]
> ([B]ECC was not an option[/B] because the logic [B]delay penalty[/B] cancels out the speed advantage of using SRAM in the cache).

[...]
> This problem affected thousands of users, and one Sun customer wrote to tell us their company had replaced over 1000 UltraSPARC 2 400MHz CPUs because of the ecache issue.
>

Проснулись.

Читайте Андерсона, Orange Book и остальные книжки из "радужной" серии, EAL.

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

"цифровой" был только арифмометр "феликс" - там, если шестеренки попадали мимо зубца, его клинило, и приходилось нести в ремонт.

P.S. а сколько тебя открытий чудных ждет при знакомстве с устройством современных hdd...

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

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

Но в большинстве случаев инверсия одного бита никак заметно не повлияет на работу. Толку-то от того, что в дисковом кеше один бит поменяется? Ещё надо дождаться, когда этот бит повлияет как-то на ход выполнения кода. Если он вообще повлияет. Огромные объёмы памяти заняты информацией, которая не критична к искажению. Распакованный jpg может занимать мегабайты, но что ему будет от искажения одного бита?

Но при этом есть вероятность всего чего угодно, из того списка, который ты предложил. Просто ты замучаешься ждать, когда это случится, а когда случится никогда не узнаешь почему это случилось. Потому что помимо нестабильности памяти есть множество других причин для утечек памяти, зависаний и kernel panic'ов, эти другие причины гораздо более вероятны, и их очень сложно отмести как возможные причины, при диагностике внезапного единичного падения системы или программы.

Юзай Эльбрусы, там работа с памятью похожа на придуманный ZebRAM  
https://www.usenix.org/system/files/osdi18-konoth.pdf

Ну, хорошо, постепенно у тебя просто "умрут" все чипы памяти. А дальше чего? Наверное, компьютер без RAM работать не может, так что как минимум DoS атака все же выйдет :)

cflush? В "оригинале" (RowHammer) использовали его.

С кэшом все сложно. Его можно обдурить, вплоть до того что умники даже из JS это пытались делать. К тому же у него оказалось своих проблем немеряно - с спектрами и мелтдаунами воюют в соседних ветках.