The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Разработан метод атаки на DRAM-память, позволяющий обойти защиту ECC

23.11.2018 11:49

Группа исследователей из Амстердамского свободного университета разработала (PDF) усовершенствованный вариант атаки RowHammer, позволяющей изменить содержимое отдельных битов в памяти на базе чипов DRAM, для защиты целостности в которых применяются коды коррекции ошибок (ECC). Атака может быть выполнена удалённо при наличии непривилегированного доступа к системе.

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

До сих пор использование ECC считалось наиболее надёжным способом защиты от вышеописанных проблем, но исследователям удалось разработать метод изменения заданных битов памяти, не приводящий к срабатыванию механизма коррекции ошибок. Метод может применяться на серверах с ECC-памятью для модификации данных, подстановки вредоносного кода и изменения прав доступа. Например, в ранее продемонстрированных RowHammer-атаках при наличии у злоумышленника доступа к виртуальной машине инициировалась загрузка вредоносных системных обновлений через изменение в процессе apt имени хоста для загрузки и модификации логики проверки цифровой подписи.

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

Метод основывается на факте, что при исправлении ошибки возрастает время чтения и возникающая задержка вполне измерима и заметна. Атака сводится к последовательным попыткам изменить каждый бит по отдельности, определяя успешность изменения возникновением задержки, вызванной корректировкой ECC. Таким образом выполняется поиск машинных слов с тремя изменяемыми битами. На последнем этапе необходимо добиться, чтобы три изменяемые бита в двух местах были разными, после чего попытаться за один проход изменить их значение.

Исследователи успешно продемонстрировали возможность атаки на четырёх разных серверах с памятью DDR3 (теоретически уязвима и память DDR4), три из которых были укомплектованы процессорами Intel (E3-1270 v3, Xeon E5-2650 v1, Intel Xeon E5-2620 v1 ), а один - AMD (Opteron 6376). При этом отмечается, что поиск необходимого сочетания битов в лабораторных условиях на неактивном сервере занимает около 32 минут. Совершить атаку на работающем сервере значительно труднее из-за наличия помех, возникающих в процессе активности приложений. На рабочих системах для поиска необходимого сочетания изменяемых бит может потребоваться до одной недели.

Итоговый вывод сводится к тому, что ECC полностью не исключает проведение атаки RowHammer, но существенно замедляет и усложняет её. Для выявления попыток совершения атаки администраторам многопользовательских систем рекомендуется включить в логах отображение фактов коррекции ошибок ECC и настроить мониторинг связанной с ними активности.

  1. Главная ссылка к новости (https://arstechnica.com/inform...)
  2. OpenNews: Эксплуатация уязвимости в DRAM-памяти через локальную сеть
  3. OpenNews: Уязвимость в NAND Flash может привести к повреждению чужих данных на SSD-накопителях
  4. OpenNews: Представлен метод скрытого изменения памяти чужих виртуальных машин
  5. OpenNews: Разработан метод атаки на уязвимость в DRAM-памяти с использованием JavaScript
  6. OpenNews: Продемонстрировано использование уязвимости в DRAM-памяти для повышения привилегий в системе
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: rowhammer
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (60) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Fracta1L (ok), 12:08, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –21 +/
    Бедные апологеты ЕСС, стабильности и надёжности, в каком страшном мире они живут))
     
     
  • 2.12, Аноним (12), 16:06, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +15 +/
    ECC нужен в первую очередь не для того, чтобы защищаться от RowHammer-а, чтобы при появлении сбойной ячейки памяти ловить не панику ядра или, что еще хуже, повреждение данных, а всего лишь уведомление от мониторинга, чтобы потом уже планово заменить сбойный модуль. В общем, роль примерно та же, что и у RAID-массива в системе хранения данных.
     
     
  • 3.14, Аноним (14), 17:41, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Внезапно и apparmor оказался не бесполезен.
     
     
  • 4.52, Аноним (52), 02:08, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    AppArmor вообще совсем никак тебе не поможет когда атакующий может на уровне физики железа битики вертеть. Это настолько мимо процессора и аппармора что ими совершенно не контролируется.
     
  • 2.51, Аноним (51), 01:53, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это вообще к чему ECC вообще изначально сделан для защиты от сбоев RAM Случайн... текст свёрнут, показать
     

  • 1.2, КГБ СССР (?), 12:18, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Так как память DRAM представляет собой двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора, выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.

    В этой связи было бы интересно увидеть такие же опыты для DDR и DDR2.

    > Итоговый вывод сводится к тому, что ECC полностью не исключает проведение атаки RowHammer, но существенно замедляет и усложняет её проведение. Для выявления попыток совершения атаки администраторам многопользовательских систем рекомендуется включить в логах отображение фактов коррекции ошибок ECC и настроить мониторинг связанной с ними активности.

    Ну как бы ECC создана не для противодействия таким атакам.

    Кроме того, судя по фоточкам в отчёте, они туда лезли физически, то есть подсоединялись к шине памяти. Читать весь текст мне было лениво, а фотка потешная. :)

     
     
  • 2.4, Аноним (4), 12:24, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Кроме того, судя по фоточкам в отчёте, они туда лезли физически, то есть подсоединялись к шине памяти.

    Это они обратный инжиниринг проводили и изучали как 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.

     
     
  • 3.5, КГБ СССР (?), 12:42, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не, я не против исследований надёжности и защищённости железа и софта. Очень даже за.
     
  • 2.53, Аноним (52), 02:11, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В этой связи было бы интересно увидеть такие же опыты для DDR и DDR2.

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

     
     
  • 3.64, КГБ СССР (?), 14:24, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> В этой связи было бы интересно увидеть такие же опыты для DDR и DDR2.
    > А кому они сейчас интересны? Сейчас даже в роутерах за 15 баксов
    > с али DDR3 везде. Производить археологические раскопки - мало мотивации. Так
    > что забутявив дос на 286 ты можешь побыть в относительной безпасности
    > неуловимого джо. Пока кто-нибудь не найдет на древней дискете вирус.

    Если б ты понимал, как устроена и работает оперативная память (и на чём вообще делают деньги производители электроники из песочка), ты бы не писал глупостей.

     

  • 1.3, fefe (?), 12:19, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Опять нужно недоверенный бинарный код выполнить, чтобы сработало?
     
     
  • 2.7, Аноним (7), 12:43, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Теперь можно взломать любой виртуальный или vps хостинг. Ура!
     
  • 2.54, Аноним (52), 02:12, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Были и потуги JS'ом в браузере пытаться вызвать тот же эффект. С переменным успехом, но сам факт...
     

  • 1.6, Аноним (6), 12:42, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Совершить атаку на работающем сервере значительно труднее из-за наличия помех, возникающих в процессе активности приложений.

    Ну хоть кто-то это честно написал.

     
     
  • 2.8, Онанимус (?), 13:16, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Ну хоть кто-то это честно написал.

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

     
     
  • 3.55, Аноним (52), 02:14, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    С другой стороны компьютеры никуда и не торопятся. Пустил хакер Васька брут на недельку на честно купленной впске, а через недельку пришел и забрал себе уже всю пачку вдсок, и хост вместе с ними. Поди плохо - куча ресурсов с дедиком, виртуалками и кучей айпишников за пару баксов. Еще какие-нибудь логины, пароли и ключи поди окажутся.
     

  • 1.9, A. Stahl Is Gay (?), 13:24, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Ну хоть кто-то это честно написал.

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

     
     
  • 2.10, нах (?), 13:34, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    ломанешь васян-сайт соседний с тобой по vps ? Ну а чо, проооофит!
    Насчет соседней vps уже возникают сомнения, поскольку неизвестно, где и что в ней лежит.

     
     
  • 3.56, Аноним (-), 02:19, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ломанешь васян-сайт соседний с тобой по vps ? Ну а чо, проооофит!

    Конечно профит. В полном варианте можно перехватить весь хост. И все васян-сайты на нем. С кучей айпишников. И все это за цену 1 вдски.

    > Насчет соседней vps уже возникают сомнения, поскольку неизвестно, где и что в ней лежит.

    С точки зрения результата логичнее смотрится вынос хоста. А потом можно спуститься и поиметь все стадо...

     

  • 1.11, Аноним (11), 15:47, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    В общем, компы стали слишком быстрыми и насилование соседних битов приводит к успеху
     
  • 1.13, Аноним (13), 17:01, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Скорее всего, самым надёжным методом защиты от атак RowHammer уменьшение периода регенерации до значения, когда сколько не насилуй одни и те же ячейки, заряд соседних не успеть уменьшить до начала следующей регенерации.
     
     
  • 2.15, Аноним (14), 17:42, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Наоборот, начинай майнить во весь проц.
     

  • 1.18, Aknor (?), 00:43, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А какой-нибудь fail2ban для процессора придумать нельзя ?? Чтоб эти множественные обращения детектить, а затем определять , кто из какой аппаратной Vm там долбится ??
     
     
  • 2.19, хотел спросить (?), 01:01, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    у меня сейчас 20000 айпи в блоке

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

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

    шчастя

     
     
  • 3.21, Аноним (21), 06:18, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пихтоне же не тормозит?
    А не тормзит, поэтому придумали sshguard;
     
     
  • 4.27, хотел спросить (?), 17:56, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Пихтоне же не тормозит?
    > А не тормзит, поэтому придумали sshguard;

    надо обязательно попробывать, спасибо

     
     
  • 5.29, Аноним (29), 19:21, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У проекта openbsd есть blacklistd, и у проекта powerdns есть блеклист демон. Не помню названия
     
     
  • 6.57, Аноним (-), 02:21, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > У проекта openbsd есть blacklistd

    Проблема именно в том что он именно у проекта openbsd. Где-то там. Примерно там же где бункер Гитлера и примерно настолько же удобное для повседневных применений.

     
  • 4.36, лютый лютик_ (?), 08:38, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Пихтоне же не тормозит?

    Если пихонописаки не догадались использовать структуру с эффективностью поиска О(1), это проблемы не пихона, а писак. 20k и 200k это ничто для hashset на любом языке.

     
     
  • 5.58, Аноним (-), 02:22, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если пихонописаки не догадались использовать структуру с эффективностью поиска О(1), это
    > проблемы не пихона, а писак. 20k и 200k это ничто для
    > hashset на любом языке.

    O(1) ничего не говорит о времени за которое операция завершается. Если лукап всегда завершается за 20 секунд - это O(1). Что совершенно не мешает ему быть неприемлимо медленным для большинства применений. А потому O(1) от сишника и от питониста - две большие разницы.

     
  • 3.39, Stanislavvv (?), 11:40, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем блокировать, добавляя каждый раз правило? Сделай через ipset и будет тебе щасте.
     
     
  • 4.41, хотел спросить (?), 13:00, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем блокировать, добавляя каждый раз правило? Сделай через ipset и будет
    > тебе щасте.

    речь о подсетях?
    они все практически из разных подсетей

     
     
  • 5.42, Аноним (42), 17:38, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ipset прекрасно работает с подсетями любого размера, от /0 до /128.
     
     
  • 6.44, хотел спросить (?), 01:02, 27/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > ipset прекрасно работает с подсетями любого размера, от /0 до /128.

    да какая разница, если все айпишники разные

    я ж не роскомнадзор подсетями банить

     
     
  • 7.49, Ananim (?), 18:41, 28/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хотел сначала съязвить в пользу интеллектуальных способностей автора, а потом раздумал.
    Кэп подсказывает, что CIDR /32 для IPv4 и /128 для IPv6 - это и есть единственный IP, хотя для IPv6 целесообразнее банить по /64, т.к. это именно столько, сколько довольно часто выдаётся хостером на один VPS, с которых брут частенько и бывает запущен.
     
     
  • 8.50, хотел спросить (?), 21:26, 28/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    IPv6 не используется, поэтому 64-ыми подсетями банить нет смысла кстати некторы... текст свёрнут, показать
     
  • 7.59, Аноним (-), 02:27, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > да какая разница, если все айпишники разные
    > я ж не роскомнадзор подсетями банить

    Так и не надо подсетями. Заносишь айпишники в ipset по одному - и бай-бай. Главное не забыть амнистию делать по какому-нибудь таймауту. А то при случае самозабанишься на вечно - и поимеешь много кайфа. Да и айпишники в собственности конкретной рожи, особенно v4 нынче как бы экзотика и потом можно много странных эффектов отхватить, когда через полгода какой-нибудь юзер не сможет на какой-нибудь сайт зайти, или что там у кого, потому что оказывается 2 года назад с того же айпи совсем другое некто спамнуло, а вы тут дескать очень злопамятный и радикально забанили все живое по этому поводу.

     
     
  • 8.63, хотел спросить (?), 14:11, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален 1 Т е если я правильно понял, внеся 20000 айпишников в... текст свёрнут, показать
     

  • 1.20, Ivan_83 (ok), 02:45, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Zen вроде как шифрует всю память, так что там с этим проблем нет, в том плане чтобы флапать нужные биты.
     
     
  • 2.28, хотел спросить (?), 18:00, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Zen вроде как шифрует всю память, так что там с этим проблем
    > нет, в том плане чтобы флапать нужные биты.

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

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

     
  • 2.60, Аноним (-), 02:28, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Zen вроде как шифрует всю память, так что там с этим проблем нет

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

     

  • 1.22, nrv (ok), 09:38, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Меня очень пугают такие вещи. Сначала меня испугал сам факт существования ecc памяти. Теперь оказывается, что и ecc не цифровая...

    Что значит понятие "цифровой"? Это значит 2+2 всегда 4. Что считывая ячейку памяти, мы получаем значение, которое было туда записано. в 1-й раз, во второй, в 1000002-й..

    То есть что получается, братцы? Получается, кодер не может гарантированно написать 100% валидную программу, даже если он знает как это сделать. Бит памяти поменяется самостоятельно.. и if пойдет не туда

    Кто=нибудь может просветить, как DRAM без ecc вляет на юзер экспириенс?
    Ок, ecc сбоит в каких-то экслюзивных случаях, а обычная - постоянно?
    Память течет? Ошибки? Или тупо зависание? Или сразу BSOD/Kernel panic?
    Как часто она сбоит-то?

     
     
  • 2.23, КГБ СССР (?), 11:32, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ещё, говорят, чем выше к небу, тем больше космических лучей пронзает кремниевые чипы, вызывая обилие интересных последствий. :)

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

     
  • 2.26, Аноним84701 (ok), 17:01, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > То есть что получается, братцы? Получается, кодер не может гарантированно написать 100%
    > валидную программу, даже если он знает как это сделать. Бит памяти поменяется самостоятельно.. и if пойдет не туда

    ...
    > Ок, 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.
    >

     
  • 2.32, macfaq (?), 23:22, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/

    > То есть что получается, братцы? Получается, кодер не может гарантированно написать 100%
    > валидную программу, даже если он знает как это сделать. Бит памяти
    > поменяется самостоятельно.. и if пойдет не туда

    Проснулись.

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

     
  • 2.35, пох (?), 07:09, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ну надо же, открытие.

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

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

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

     
     
  • 3.37, Аноним (37), 09:35, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не соглашусь с выводами: цифровой это не значит гарантированный уровень сигнала, т.е. если единица то это ровно 5 вольт (к примеру), а если нуль то 0 вольт. У цифры есть свои диапазоны, т.е. единицей считается напряжение от 2,7 до 5 вольт, а нулем - от 0 до 0,8 вольта (если питание 5 вольт). цифровой означает что уровень напряжения может изменяться в процессе передачи или хранения, но он не выйдет за пределы диапазона, в котором изначально был (отправлен или сохранен). Цифровые ячейки есть - триггеры, два (или четыре) транзистора на бит (с обвязкой в виде резисторов), но это дорого, потому и используют один транзистор плюс конденсатор (ОЗУ).
     
     
  • 4.45, pavlinux (ok), 21:48, 27/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Отец, спасибо за мамонтологию, но цифровой - это цифровой: 1, 0, ... -1, |0⟩,|1⟩, спин, полуспин,... итд.
    Как это реализуется, другой вопрос.  
     
  • 2.40, Ordu (ok), 12:42, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто=нибудь может просветить, как DRAM без ecc вляет на юзер экспириенс?

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

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

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

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

     
  • 2.43, Аноним (42), 17:45, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Мир неидеален. Просто прими это и живи спокойно.
     
  • 2.47, pavlinux (ok), 22:25, 27/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть что получается, братцы? Получается, кодер не может гарантированно написать 100%

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

     

  • 1.24, Аноним (24), 14:59, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Подозрительно что они тихо умолчали что ecc он всетаки очень разный бывает, к примеру chipkill конфигурацию этой мутью не пробить.
     
     
  • 2.31, InuYasha (?), 23:06, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    К тому же ECC настройки у серверов бывают разные. Не только ON/OFF, но даже background scrub rate можно настраивать.
     
     
  • 3.46, pavlinux (ok), 22:10, 27/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > К тому же ECC настройки у серверов бывают разные. Не только ON/OFF,
    > но даже background scrub rate можно настраивать.

    Bank Interleaving,  Channel Interleaving, Node Interleaving - через неделю работы брутфорсера,
    планировщик задач тупа перекинет процесс на другу NUMA-ноду, и память за ним уползёт. :)  

    Bank Swizzle Mode тоже по своему настроению работает.

    Background scrubbing нескольких типов бывает, чаще все вместе.  

     
  • 2.61, Аноним (-), 02:31, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > к примеру chipkill конфигурацию этой мутью не пробить.

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

     

  • 1.33, Аноним (33), 11:18, 25/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ребята, а как же кеш? По идее для того чтобы читать долгое время именно из dram, кеш нужно отключить. И как это сделать в непривилигированной программе?
     
     
  • 2.34, Аноним84701 (ok), 13:46, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ребята, а как же кеш? По идее для того чтобы читать долгое
    > время именно из dram, кеш нужно отключить. И как это сделать в непривилигированной программе?

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

     
     
  • 3.38, Аноним (37), 09:37, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    тогда это незаметно сделать не выйдет - сброс кэша заметно снизит производительность сервера (тем более если это будет длиться неделю).
     
  • 2.62, Аноним (-), 02:33, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ребята, а как же кеш?

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

     

  • 1.48, pavlinux (ok), 22:36, 27/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Группа исследователей разработала усовершенствованный вариант....

    Шо, теперь рута не надо?

    > Напомним, что

    А не, .... без рута и жизнь не мила.

    $ ./check /usr/bin/sudo
    Could not get physical address! Are you running this tool as root?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру