`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

«Двуликий закон Мура», потенциально очень нехорошие вирусы, а также о выборе DRAM для высоконадёжных серверов

+1010
голосов

«Закон Мура» - чуть ли не священная корова индустрии. Если эта корова плохо доится, всегда можно произвести некоторые манипуляции с «молоком» и показать очередное победное соблюдение эмпирического и недоказуемого правила. Этого аспекта «закона Мура» не буду даже касаться, неинтересно. Куда интереснее заметить на аппроксимирующей «закон» прямой точку, в которой происходят какие-то качественные изменения. Любые. Не обязательно хорошие и «светлые». В инженерии вообще таких понятий не существует. Так что обойдёмся без эмоций.

Мы будем говорить об уже случившемся – о той точке на «прямой Мура», в которой уменьшение физических размеров элементов интегральной микросхемы позволило изменять поведение всей системы, где используется эта микросхема, непредусмотренным разработчиками и очень опасным способом. Если менее заумно – есть способ, позволяющий полностью разрушить процесс нормального исполнения, например, операционной системы (что означает – всего вообще), и мало что этот способ основывается на… законе Мура, так ещё и разработчики микросхем никогда ничего «специального» не делали для возможности появления этого способа, ни умышленно, ни по недосмотру. То есть, этот способ не использует никаких традиционных «вирусных» приёмов, он даже не сугубо аппаратный, он фундаментален, он существует и работает именно потому, что закон Мура…

Теперь можно и переходить к сути. «Закон Мура» обычно иллюстрируют почему-то микропроцессорами, хотя это эмпирическое правило должно «работать» для полупроводниковых интегральных микросхем вообще. И микросхем динамической памяти – в частности. И вроде как «работает» (не буду утверждать, не проверял даже, а зачем?). Увеличение ёмкости микросхем DRAM при сохранении размеров кристаллов, на которых они реализованы, означает одно – размеры ячейки памяти (которая в DRAM по сути является конденсатором) уменьшаются. Очень сильно уменьшаются. Вот микрофотография «среза» кристалла DRAM, выполненного по 22 nm технологическому процессу, на ней видны характерные «колбочки» этих самых конденсаторов (capacitors), для иллюстрации плотности «упаковки»:

«Двуликий закон Мура», потенциально очень нехорошие вирусы, а также о выборе DRAM для высоконадёжных серверов

Даже если следовать самой простой неинженерной логике, то при уменьшении габаритов каждой ячейки памяти и «изолирующих прослоек» между ними должно когда-нибудь что-нибудь, да произойти (такая логика тоже полезна). Если воспользоваться инженерной логикой, то «выплывут» всевозможные нюансы, например простые соображения – с уменьшением размера хранящего заряд элемента памяти и увеличением количества этих элементов на единицу площади кристалла одновременно и уменьшается отношение сигнал-шум, и увеличивается электромагнитная связь между соседними элементами. И, наконец, есть технологический процесс, который с уменьшением технологической нормы производства отдаляется от представлений об идеальности и вносит значительный фактор случайности (хотя бы просто потому, что становится более чувствительным к самым малым вибрациям, чистоте и прочему). То есть, при каких-то габаритах всей конструкции должен наступить момент, когда заявленные технические параметры будут действительными не «вообще», а «в очень многих, но не всех, случаях».

Не стоит считать, что разработчики DRAM об этом не догадывались. Потому что команда, исследовавшая нехорошую сторону закона Мура, сформирована из специалистов университета Carnegie Mellon и Intel, именно тех специалистов, которые занимаются низкоуровневой архитектурой микросхем DRAM. Больше того, название для всего этого было придумано ещё в дремучие времена становления индустрии, когда Intel выпустила первую коммерческую микросхему DRAM 1103 – именно тогда прозвучал термин «возмущения в работе динамической памяти» (DRAM disturbance), были созданы и технологические методы снижения этого эффекта (например, увеличение качества «изоляции» между ячейками памяти), и усовершенствованы способы тестирования кристаллов памяти. И всё было в целом хорошо, пока не…

Пока повторно не открылось, что DRAM disturbance прекрасно работает в обычных «планках» памяти, выпущенных в 2012-2013 годах, причём в исследованных 129 образцах эффект ярко проявился в 110 "планках". Очень немаленькая цифра, чтобы её не замечать.

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

Ячейки памяти DRAM организованы в матрицу и соединены общими полупроводниковыми шинами строк. Последовательное выполнение большого числа активаций шины строки (например, операций чтения из одной и той же ячейки памяти) вызывает «возмущения» в работе всех соседних к строке ячеек памяти – их содержимое может быть разрушено. Более детально – «дёргающаяся» с высокой частотой шина строки вызывает ускоренную утечку заряда из соседних ячеек памяти, и если процесс регенерации памяти (а он повторяется очень нечасто по временным меркам современных DRAM) не успеет восстановить заряды – всё, правильное содержимое не восстановить вообще.

Исследования реальных образцов DRAM показали, что всего 139-140 тысяч последовательных изменений состояния шины строки может превратить в «мусор» содержимое до 2 тысяч ячеек памяти, к которым вообще не было никаких обращений, они аппаратно находятся в других строках DRAM. Эффект проверено и доказано повторим (что важно, речь идёт не о какой-то лабораторной работе «с уникальными результатами»).

То есть, появилась возможность уничтожать содержимое ячеек памяти непрямым методом, не обращаясь к ним вообще. Забавно, что никаких технических ухищрений для этого не требуется, достаточно возможностей штатного контроллера памяти фактически любой платформы (в мире x86 независимо от производителя – что Intel, что AMD, всё равно) и примитивной (но требующей исполнения в защищённом режиме) ассемблерной программки:

Disturber:
    mov (X), %eax
    mov (Y), %ebx
    cflush (X)
    cflush (Y)
    mfence
jump Disturber

Первые две команды (mov) выполняют операцию чтения из памяти (адреса X и Y) в регистр и, естественно, в кэш-память. Команды cflush «вычёркивают» из кэш-памяти только что прочтённое (например, за ненадобностью, чтобы не занимать кэш-память, совершенно законная и типовая последовательность операций), mfence гарантирует освобождение кэш-памяти до выполнения первой следующей любой операции с памятью. И, наконец, всё это абсолютно законное и формально правильное выполнятся в бесконечном цикле, команда jump возвращает управление по адресу Disturber.

Эта программка, исполняемая современными процессорами, вызывает «загрузку» контроллера памяти последовательностями запросов к DRAM, которые периодически «выстреливаются» в шины физической памяти. Итог её исполнения – разрушение содержимого ячеек памяти с адресами, ничего общего с использованными в ней не имеющими (выявлено даже правило выбора «разрушительных» адресов X и Y, обусловленное особенностями работы контроллеров памяти Intel и AMD).

Для проверки модулей памяти на подверженность disturbance разработана программа с символическим названием rowhammer. Она работает под управлением ОС Linux и доступна всем желающим. Ничего сверхсложного в её использовании нет, всё детально расписано, включая и недостатки реализованного метода тестирования.

Так что есть возможность для действительно высоконадёжных серверов, например, отбирать модули памяти менее подверженные disturbance DRAM эффекту (и потенциальным атакам, к слову, раз уж есть такой способ, ещё и очень просто реализуемый, то с очень большой вероятностью его используют для чего-нибудь плохого, слишком он «аппетитный»). Конечно, это приведёт к увеличению стоимости готового сервера, но «за бесплатно» ничего не бывает.

Вот такая вторая сторона «закона Мура» получается. Радикального решения проблемы, что очевидно, нет. Производители, безусловно, будут искать способы ослабить DRAM disturbance, но это очень дорогие решения – они ведь требуют исследований и модернизаций технологических процессов.

Традиционная рубрика «польза» - в следующей записи.

Откланиваюсь.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1010
голосов

Напечатать Отправить другу

Читайте также

Т.е. если последовательно, 139-140 тыс. раз вспомнить о хорошем, то все плохое забудется?

вот тут большая ошибка кроется
что-то точно забудется, без всякого сомнения
но будет ли забывшееся обязательно плохим - никаких гарантий вообще
:(

Осталось только вспомнить что в серверах все же используется ECC (в разных ее имплементациях) DRAM и все перестанет быть таким драматичным.

Зато в новых рабочих станциях такая память будет критичной. Проэкт на миллионы, и во время сохранения хитрый код убивает критичную часть.

И чем поможет ECC от массового разрушения содержимого от нескольких килобайтов до нескольких мегабайтов (и такое в отдельных модулях наблюдалось) RAM?
Строго ничем.
ECC защищает от сбоя в _одном бите_ слова, она не волшебная. Ничего она не даст ровным счётом - "разваленная память", если она в области адресов ядра ОС, что с ECC, что без ECC, приведёт к погрому.
Кроме того, даже не факт, что содержимое дополнительных, контрольных ячеек ECC, не уничтожается. Они ведь ничем не отличаются от прочих ячеек. Это, разве что, может дать очень забавные сторонние эффекты (в дело вовлекается ещё и невидимый железу и ОС контроллер ECC).

Ну для начала современные модули и контроллеры DRAM используют скремблеры и никогда не будут писать в одну и ту же строку полный байт а разбросают его по всему чипу по только производителю известному алгоритму, так что адресовать полную строку в реалистичных условиях это будет вряд-ли возможно, заметьте что шокирующие результаты тестирования были получены на FPGA специально запрограммированном так чтобы адресовать полную строку а совсем не котроллере памяти чипсета сервера.

А во вторых технологии ECC тоже не стоят на месте, Extended ECC, DDDC прекрасно справляются с мультибитовыми ошибками.

Я кстати обещаю завтра запустить rowhammer на обычном серверном E5-2600 v2 / 512GB и выложить результаты.

у Intel контроллер памяти "распыляет адреса" (для DRAM это совершенно не нужно, это не флэш, деградации от числа записей-считываний нет), потому в псевдокоде используются 2 адреса, а в pdf-описании приведена даже "формула", которой всё это "распыление" нивелируется
у AMD вообще всё детерминировано, не требуются никакие ухищрения

FPGA использовали только из-за масштабов эксперимента, чтобы сократить затраты времени, в остальном оно совершенно не принципиально.

Eh ?

"As an example, we were able to increase the number of errors from 1,000 to 10,000,000 for the exceptionally problematic DRAM module. The latter number was obtained using custom-built hardware equipment that allows us to test every row in the DRAM module (within a relatively short amount of time) using the best access-pattern and the best data-pattern."

По моему увеличение количества ошибок на четыре порядка при использовании FPGA это очень принципиально.

Ну и обещанный результат теста

http://i62.tinypic.com/x4oqr5.jpg

И какой вывод ? Либо тест просто нерабочий либо инженеры Intel проектирующие контроллеры памяти знают что они делают.

Кстати ни о какой дорогой серверной системе тут речь даже не идет, самый что ни на есть сервер начального уровня за $5K.

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

>> Т.е. если последовательно, 139-140 тыс. раз вспомнить о хорошем, то все плохое забудется?

Всё сводится к тому, что надо мыслить позитивно ;)
Вот здесь хорошо описано:
http://catta.livejournal.com/108339.html

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT