Продолжая почивать на лаврах лидера после выпуска архитектуры Sandy Bridge (SB) в 2011 г., Intel продолжает следовать своей стратегии «тик-так», приготовив очередной «тик»: переход на новый, 22-нанометровый техпроцесс с 3-сторонними затворами у транзисторов (описанный в третьей части нашего микроэлектронного обзора) совмещён с небольшими изменениями в архитектуре. Причём большая часть изменений касается помощневшего графического (со)процессора (ГП): версия HD2000 обновилась до HD2500 (оставив те же 6 графических трактов), а HD3000 (12 трактов) доросла до HD4000 (16 трактов). QuickSync (аппаратный перекодировщик видео) обновлён до версии 2.0, которой рекламируют удвоенную скорость. Заявлена поддержка библиотек DX11, OpenGL 3.1, OpenCL 1.1 (на этот раз — настоящая, т. е. аппаратная, а не эмуляция на x86-ядрах) и MFX (Multi-Format Codec), а также разрешений до 4096×4096 и до трёх экранов. Детали производительности ГП описаны в этих двух тестированиях, а сила x86-ядер изучена как в абсолюте, так и в равных условиях. Нам же осталось посмотреть, какие мелочи решила добавить Intel к и так передовому «песчаному мосту», превратив его в «плющевый».
Устройство процессоров Core 3-го поколения с x86-ядрами архитектуры Ivy Bridge. Иллюстрация PC watch (с исправленной ошибкой).
С точки программно доступных изменений, Ivy Bridge (для краткости будем называть его IB) получил несколько мелочей:
- поддержка мини-поднабора CVT16 (ранее доступного лишь последним ЦП AMD), причём сразу в полноконвейерном режиме (преобразование вектора имеет задержку 6–10 тактов);
- быстрый доступ к сегментным регистрам FS и GS (только эти из 6 сегментных регистров разрешены к использованию после внедрения x86-64) с помощью 4 новых команд — пригодится для ускоренного управления переключением контекста задач со стороны программы;
- DRNG (digital random number generator) — цифровой генератор случайных чисел (ГСЧ) и команда для их чтения (строго говоря, сам ГСЧ расположен во внеядре, но командно доступен всем ядрам);
- SMEP (supervisory mode execution protection) — защита исполнения в режиме супервизора.
О ГСЧ и SMEP, наличие которых удостоено дополнительными битами в паспорте ЦП (читаемому командой CPUID), детально напишем ниже.
Что касается чисто аппаратных улучшений, то начнём с блока, ускорение которого в тестах едва чувствуется: один из двух видов предзагрузчиков для кэша L1D теперь может переходить через 4-килобайтовые границы виртуальных страниц. В момент пересечения он инициирует (как при явном обращении в L1D) чтение(я) из TLB (и L1, и L2), а если там будет два промаха — то даже и трансляцию адреса в PMH. Причём если PMH наткнётся на ошибку доступа или нерезидентную страницу (перемещённую из ОЗУ в файл подкачки), то вместо фиксирования исключительной ситуации и вызова её обработчика PMH просто остановится. Ведь предзагрузка это упреждающее действие, поэтому ЦП не может быть уверен, что данные по этому адресу точно потребуются, так что преждевременное прерывание делать неверно. В подсистеме кэшей есть также некие улучшения при чтении невыровненных 32-байтовых слов из L2, о чём в официальных документах ничего не сообщается — видимо, из-за крайне малого влияния на что-либо.
Ну а остальные улучшения измерены куда детальней и приносят бо́льшую пользу. Во-первых, ускоренный вещественный делитель-корнеизвлекатель: деление для точностей SP, DP и EP теперь исполняется за 7, 14 и 18 тактов (было — 14, 22 и 24); почти так же ускорено и извлечение квадратного корня. Тем не менее, это ФУ осталось единственным крупным 128-битным в векторном тракте — все остальные имеют полную ширину в 256 бит. Также сюда можно добавить несколько команд (таких как некоторые простые битовые сдвиги и вращения), ускоренных на 1 такт или исполняющихся парами, а не по одной, что из всех алгоритмов пока заметно ускоряет лишь вычисление хэшей типа SHA1 и SHA256.
Пара (по одному на поток) буферов мопов (IDQ), находящихся между декодером и кэшем мопов со стороны фронта и диспетчером со стороны тыла конвейера, теперь для 1-поточной нагрузки умеет притворяться единым буфером на 56 мопов — SB в таком случае просто отключал второй буфер. В идеале, конечно, было бы ещё лучше, если бы это физически был единый буфер, который при 2-поточной загрузке делился бы не поровну, а динамически, как большинство остальных структур ядра. На производительность это почти не влияет (ибо кэш мопов и так гарантирует, что тыл почти всегда сможет получать по 4 мопа/такт), однако становится ясно, почему Intel оставила эту структуру — при блокировке цикла в буфере (за счёт функции LSD) можно отключить даже кэш мопов, экономя таким образом ещё немного энергии. И если для 1-поточной нагрузки буфер оказывается вдвое больше, то шансов на то, что очередной цикл там поместится, куда больше. За подробностями о правилах работы IDQ и о 4 видах разделения ресурсов между потоками отправляем к соответствующим описаниям в обзоре SB по данным тут ссылкам.
Также появились «бесплатные» копирования из одного регистра в другой, «исполняющиеся» уже на стадии переименования регистров и не занимающие ресурсы планировщика и ФУ:
- скалярные MOV для 32- и 64-битных РОНов (8- и 16-битные копирования — обычные);
- скалярные MOVZX (беззнаковое расширение РОНов с заполнением старших битов нулями) типа 8→32 и 8→64, кроме случаев, когда 8-битный источник это регистр AH/BH/CH/DH (т. е. старшие байты младшего слова первых 4 РОНов) — такие варианты исполняются штатно, как и все виды MOVSX (знаковое расширение с заполнением старших битов копией бита знака аргумента);
- векторные MOV*** (6 видов) для xmm и ymm и обоих типов элементов (целые или вещественные).
Таким образом, к обнуляющим идиомам в SB, которые также «бесплатны» и могут исполняться до 4 за такт, в IB добавили и самые частые копирования, что в некоторых программах может чуть поднять среднюю величину IPC и сэкономить несколько миллиджоулей. Физическая реализация очевидна: т. к. планировщик (как и у SB) оперирует не содержимым регистров, а ссылками на физический РФ, то копирование регистра можно заменить копированием 8-битной ссылки, и реализовать это можно было ещё в SB.
Сложнее с частичным доступом в эти регистры (детали этого непростого действия описаны в конце этой главы). Согласно требованиям x86-64, запись в 32-битную младшую половину РОНа обнуляет его старшую часть (а обнуление, как мы помним, также бесплатно), а вот запись в 16- или 8-битные порции сохраняет остальные биты. Однако команда MOVZX всё же их обнуляет, и потому она в «бесплатном» варианте допустима с 8-битным источником. Могла бы сработать и с 16-битным, но по историческим причинам (восходящим к далеко не идеальному способу, которым Intel в 1985 г. свою изначально 16-битную архитектуру IA-16 доработала до 32-битной IA-32, ныне называемой x86) почти все 16-битные команды в современных x86-ЦП давно попали в разряд вредных и медленных.
Данное выше описание считалось верным до тех пор, пока независимое тестирование не показало странности работы этой «копировальной машинки». Запустив простой цикл, тело которого состоит из 2–4 команд MOV в разных вариантах, а эпилог — в виде макросливаемой пары команд (генерирующей только 1 моп), обнаружено, что обещанный в документах темп в 4 копирования за такт не получается нигде. Для РОНов 1-тактное исполнение итерации цикла выходит с одной-двумя командами MOV, а с тремя — уже за 2 такта (хотя такой цикл займёт 4 мопа, передающиеся из фронта в тыл за такт). Добавление 4-го MOV увеличивает темп до 2,33 тактов на итерацию.
При копировании векторных регистров все задержки увеличиваются ещё на 1 такт, причём уже проявляется зависимость от операндов (далее цифрами обозначены номера регистров xmm): перемещение 0→1→2 + 0→1→2 — 3 такта, 0→1→2→3→0 — 3,33, 0→1→2→3→4 — 3,5, а 0→1 + 2→3 + 4→5 + 6→7 — 3,67. Т. е. 4 копирования в цикле будут исполняться за 2,33–3,67 такта, хотя в идеале должно быть 1,25 (5 мопов). Есть, конечно, остаточная надежда, что тесты оказались неточными (как это уже бывало), но пока результаты по этому пункту крайне странные…
Ещё одно видимое улучшение (тоже отдельно отмеченное в паспорте ЦП битом ERMSB) — скоростные операции со строками. Речь идёт не об обработке текста, а об особом виде данных из терминологии x86. Для программиста «строки» это располагаемые в памяти линейные массивы произвольной длины с целочисленными элементами размером 1, 2, 4 или 8 байт. Для их обработки ещё со времён самого первого ЦП «нашей эры» — i8086 — существует 7 команд, обрабатывающих 1 элемент строки (и неявно использующих почти все нужные им регистры), REP-префиксы для их повторения (в т. ч. с досрочным выходом из цикла) и специальный бит управления в регистре флагов. Команды позволяют копировать строку (MOVS), сравнивать строки до первого (не)совпадения (CMPS), заполнять строку константой (STOS), загружать очередной элемент строки в регистр (LODS), сравнивать строку с константой (SCAS) и выводить или вводить строку в/из порт(а) ввода-вывода (OUTS и INS, добавленные уже в 286).
Из этого разнообразия сегодня наиболее употребительными остались лишь комбинации REP MOVS и REP STOS, используемыми библиотечными функциями языка Си memcpy(), memset() и memmove(), которые в том или ином виде встречаются почти везде, выполняя, например, копирование объектов. Поэтому за последние лет 5 процессоры научились ускорять эти команды (особенно, когда копируются или заполняются десятки элементов, расположенные как минимум в нескольких строках кэша) за счёт переноса данных только в пределах самого кэша. В IB такой аппаратный ускоритель оптимизирован, причём только для байтовых элементов (т. е. наиболее общего случая). При обработке ≥256 байт экономия составит аж 30–50 тактов. Однако Intel предупреждает, что не смотря на скорость режима ERMSB и компактность спецкоманд, обработка строк векторными командами всё равно оказывается чуть быстрее, если операнды выровнены, а их размер нацело делится на длину вектора. Режим SMEP
SMEP является защитой от атак типа «повышение привилегий», когда вредоносный код с уровнем привилегий 3 (пользовательский и самый низкий), не имея возможности запуститься на высоком уровне, разными способами передаёт ссылку на себя в ОС, чтобы исполниться с более высокой привилегией (обычно уровни 2 и 1 занимают компоненты ОС, а 0 — её ядро). При включении режима SMEP (через бит в одном из управляющих регистров) ядро не сможет исполнять команды из линейного адресного пространства, в дескрипторе виртуальной страницы которого выставлен бит её принадлежности к пользовательскому коду. Проще говоря, если ядро ОС поддерживает включение SMEP, то система с имеющим этот режим процессором станет чуть более защищённой. По крайней мере, так обещали в прошлый раз, когда внедряли похожую защитную функцию — бит NX, который разные вирусы и трояны весьма быстро научились обходить. На этот раз взлом произошёл ещё быстрее.
IB был официально объявлен в продаже 29 апреля 2012 г., а уже в сентябре Артём Шишкин, эксперт компании Positive Research, специализирующейся на инфобезопасности и защите, опубликовал подробный отчёт о частичном обходе SMEP на Windows 8 (пока ни для какой другой ОС поддержка SMEP не заявлена). Более того, автор указывает, что могут существовать и другие способы обхода — с помощью сторонних драйверов. «Тем не менее, в том виде, в каком реализована поддержка SMEP на x64-версиях Windows 8, она может считаться достаточно надёжной и способной предотвратить различные атаки.» В общем, бой меча и щита никогда не закончится, как и ожидалось. Цифровой ГСЧ и Большой Брат
Сначала сделаем небольшое, но важное отступление. Внимательный Читатель, пересматривая предыдущие обзоры процессорных микроархитектур и технологий, наверняка заметит, что мы как-то обошли такую популярную тему как мировые заговоры. Непорядок-с :) Ну, многие помнят, как в 1999 г. при выпуске Pentium III мировая конспирологическая общественность обратила внимание на уникальный серийный номер (PSN), которым Intel собиралась помечать каждый ЦП, и так громко завопила «Ага, попались!», что в уже ноябре Оценочная комиссия по наукам и технологиям (STOA) при Европарламенте всерьёз стала обсуждать запрет на импорт новых «Пней» в Европу, опасаясь цифровой слежки. Так что Intel пришлось через 2 года убрать PSN в чипах Tualatin. Точнее, так нам сказали ;)
Но главные компьютерные заговоры, разумеется, лежат в логовах штаб-квартирах коварных спецслужб (например, американского Агентства Национальной Безопасности, АНБ) и охмуряемых ими фирм-гигантов (например, ненавистной многим Microsoft). Причиной охмурения стало то, что «с появлением быстрых компьютеров, с бесконтрольным распространением сильных криптографических алгоритмов […] у всех желающих появились возможности для надёжного засекречивания не только текстовых, но и речевых коммуникаций». Поэтому ещё со времён Windows NT, как утверждают аналитики, АНБ пыталось внедрить чёрный вход в самую популярную серию ОС. Если бы это удалось, то «граждане, фирмы, организации и государственные ведомства в случае засекречивания своих коммуникаций должны использовать лишь такие криптосредства, которые без проблем могут быть расшифрованы правоохранительными органами».
Естественно, АНБ в этом не одинока — в 2006 г. обнаружилось, что «Британские власти ведут переговоры с представителями Microsoft по поводу умышленного создания уязвимостей в системе защиты новой операционной системы Windows Vista, чтобы сотрудники спецслужб могли проникать в компьютеры злоумышленников […] — это “поможет предотвратить террористические акты”» (ну разумеется, куда же мы без борьбы с мировым тараканизмом…). MS быстро заверила, что «в Windows Vista не будет “чёрных ходов” для спецслужб», но через год появилось продолжение — «В работе над Vista принимало участие АНБ, …[чтобы] убедиться в том, что новая ОС Microsoft соответствует всем необходимым требованиям Пентагона… Правозащитники полагают, что при участии АНБ в состав ОС могли быть включены средства […] доступа к конфиденциальным данным.»
В общем, Мировая Закулиса не дремлет. Ну, кто бы сомневался, но причём же тут случайные числа? А вот тут и начинается самое интересное. Дело в том, что крипто в Windows и др. ОС может быть взломано «плохим» ГСЧ (реализованным в ОС программно) или случайной ошибкой в процессоре. (Да простят читатели автора за столь обильное цитирование, но в выжимке ниже сказана вся суть.)
«Примером тому может служить случайное открытие в середине 1990-х глубоко спрятавшегося “бага деления” в процессорах Pentium… Если какая-нибудь спецслужба […] обнаружит (или тайно встроит) хотя бы лишь пару таких целых чисел, произведение которых микропроцессор вычисляет некорректно, то […] любой ключ в любой криптопрограмме на основе RSA, работающей на любом из миллионов компьютеров с этим процессором, может быть взломан… Если взломан ГСЧ, то в большинстве случаев можно считать взломанной и всю систему безопасности…
В новый спецвыпуск Национального института стандартов США, […] описывающий 4 одобренных к использованию схемы RNG, включен генератор Dual_EC_DRBG, разработанный в недрах американского АНБ… Выяснилось, что …[константы шифрования] связаны со вторым, секретным набором чисел… Если вы знаете эти секретные числа, то всего по 32 байтам выхода можно предсказывать всю генерируемую “случайным генератором” последовательность… [Dual_EC_DRBG] используется во всех приложениях [Windows 2000]… Функция запускается в режиме пользователя, […] что делает очень лёгким доступ к состояниям генератора… Никто толком не знает, как устроен ГСЧ в XP, но есть веские основания полагать, что он не слишком отличается от Windows 2000.»
Наконец, «Dual_EC_DRBG вошёл как опция в пакет обновления Service Pack 1 ОС Windows Vista».
Таким образом, начиная с 1995 г., история шифрования в Windows и пакета Office показывает систематически кочующие из версии в версию уязвимости, объяснить которые можно только намеренным ухудшением защиты по приказу Большого Брата. А чтобы пингвинофилам не стало обидно за обделение вниманием — в прошлом году всплыла история о том, «как ФБР и АНБ США встраивали закладки-бэкдоры в криптографию операционной системы с открытыми исходными кодами»:
«В 2003 г. программисты-разработчики, занимавшиеся созданием […] ядра ОС Linux, […] обнаружили и ликвидировали в открытых исходных кодах системы тайный бэкдор. Причём реализован этот бэкдор был настолько хитро и искусно, что […] разговоры о неуловимых троянах в открытом ПО перестали звучать как бред… Человек, знавший […] экзотическое сочетание управляющих флагов плюс место, где их следует применить, получал бы благодаря этим двум строчкам полный, с максимальными привилегиями Root, контроль… В сообществе OpenBSD начались аудиторские проверки криптоподсистем этой ОС. Первые же дни пристрастных перепроверок позволили выявить в кодах пару существенных и прежде незамеченных багов.»
Итак, мы уже трепещем: Большой Брат достал своими щупальцами до каждого ПК (кто-нибудь сомневается, что и продукция Apple не обойдена стороной?). Более того, по требованию АНБ и производители невычислительных устройств могут укоротить фактически используемую длину ключа, заполняя часть битов константой. Так это сделано в телефонах стандарта GSM и противоугонных автомобильных системах: в применявшихся до этого года чипах радиочастотной идентификации (RFID) фирмы Texas Instruments фактическая длина ключа составляла лишь 40 бит из 64, а в системах на основе KeeLoq фирмы Microchip — 28 из 64. Впрочем, взлом телефонов и угон авто — это совсем не наша тема, а вот как насчёт компьютеров?
И тут все в белом выходят маркетологи Intel и как-бы говорят: Аллилуйя! Свершилось! Повальная интеграция всего и вся в процессор достигла и случайных чисел! Тем более, что ускорение шифрования, где они так нужны, тоже давно добавлено в виде AES-NI и некоторых отдельных команд. Что говорите? Аппаратный ГСЧ ещё с 2003 г. как есть в процессорах VIA (в составе PadLock), начиная с C3 и заканчивая последними Nano? Да кто эти Нано видел-то? Вот то-то же, а вот мы — великая Intel! Поэтому с нашими Ivy Bridge ваши, граждане, случайные числа будут на 146% случайней обычных. Аминь! Ура, товарищи!
Технология аппаратного ГСЧ получила кодовое имя Bull Mountain («Бычья гора») в честь селения в штате Орегон рядом с городом Хиллсборо, где расположился исследовательский центр Intel’s Circuit Research Lab, в недрах которого технология и родилась. Перед тем как описать её суть, следует сделать теоретический экскурс, поясняющий суть задачи. Ещё Клод Шеннон показал, что лучший способ сделать так, чтобы никто, кроме целевого получателя, не мог восстановить дискретную информацию — максимально исказить её шифрованием. Более того, существует абсолютно стойкий шифр, принципиально невскрываемый аналитически — даже при наличии бесконечных петафлопсов и времени. Для этого надо всего лишь для каждого шифрования генерировать идеально случайный ключ длиной с весь шифруемый текст, причём использоваться он должен только раз.
Шеннон позаимствовал для своей теории понятие энтропии — математической меры хаотичности термодинамической системы. Энтропия по Шеннону стала мерой хаоса сигнала. И до сих пор наиболее качественными источниками хаоса являются физические явления, а не алгоритмы ГСЧ. Но т. к. программный генератор есть вещь нематериальная, то именно такой вид и применяется чаще всего, ибо он наиболее прост. И т. к. числа в нём на самом деле не очень-то случайные, то вернее его называть генератором псевдослучайных чисел (ГПСЧ, PRNG). Помимо простоты «конструкции» ещё одно важное преимущество перед аппаратными генераторами истинно случайных чисел (ГИСЧ, TRNG) — программная сущность позволяет им куда быстрее работать, что очень важно, когда шифровать надо много (для сетевых служб и устройств это особенно востребовано). Однако результат ГПСЧ должен быть криптографически стойким на случай атак и взломов, суть которых проста: следует наблюдать выходные числа или менять стартовое состояние ГСЧ, чтобы предсказывать следующие его значения, либо как-то ещё вмешиваться в его работу. И чаще всего это получается.
Дело в том, что обычные ГПСЧ, как и любая другая программа для машины с конечным числом состояний (а таков любой цифровой компьютер), основаны на детерминированном алгоритме, потому их числа лишь притворяются случайными. Для начала генерации им требуется посевное число или затравка (seed), из которого конкретный ГПСЧ всегда выдаст одну и ту же последовательность чисел, которые к тому же ещё и неизбежно начнут повторяться (хоть и с очень большим периодом — для 32-битного ГПСЧ Mersenne Twister MT19937 период равен 219937−1). Такие псевдослучайные числа подойдут для управления ИИ-соперниками в играх или в приближённых моделях в прикладной науке. Но для криптографии ГПСЧ неприменимы. Поэтому появился подвид «криптографически безопасных» ГПСЧ (КБ-ГПСЧ, CSPRNG). Он значительно лучше удовлетворяет основным требованиям к случайным числам для шифрования:
- последовательность должна быть статистически неотличима от случайной;
- восстановление прошлых или будущих состояний алгоритма по текущему должно быть максимально затруднено, а в идеале — невозможно. (Для вышеупомянутого MT19937 достаточно протестировать всего 624 числа для точного предсказания всех следующих.)
Лучший способ превратить обычный ГПСЧ в криптографически безопасный — обеспечить ему периодическую «рандомизацию», подмешивая настоящие случайные числа, полученные извне, т. е. от ГИСЧ. Таким образом можно получить много чисел, которые будут куда случайнее, чем от ГПСЧ, но при этом на единицу времени их будет куда больше, чем от медленного ГИСЧ. Но почему же медленного? А потому, что эти генераторы ничего сами не считают, а выделяют энтропию из некоего физического источника и оцифровывают её. Таким источником могут быть тепловые шумы в усилителе или специальном шумовом диоде, случайные распады радиоактивного вещества (с поправкой на темп полураспада согласно известному периоду), колебания атмосферы, хаотичное поведение микро- или макрообъектов в жидкости, и пр. Датчики, преобразующие это в последовательность нулей и единиц, работают не очень быстро.
Более того, не смотря на «природность» источника энтропии, и его статистические свойства бывают неидеальны. Например, тепловые шумы, очевидно, зависят от температуры, а броуновское движение — ещё и от внешних толчков и колебаний (даже малейших). Поэтому самые крутые ГСЧ имеют составную или «каскадную конструкцию» (КГСЧ, CCRNG): числа от встроенного ГИСЧ попадают в буфер, названный «бассейном (пулом) энтропии». Оттуда они периодически читаются в качестве недетерминированных «затравок» для КБ-ГПСЧ. Таким образом получаются и качественный хаос на выходе, и высокий темп его генерации.
Так что же нового сделала Intel? Она попыталась уместить на кристалле (причём дешёвом и массовом) все компоненты КГСЧ, чтобы любой пользователь мог иметь настоящие случайные числа, не покупая за большие деньги приставку к ПК, считающую колебания луча лазера от пролетающего за окном комара. Если не вспоминать про других производителей (тем более, что об их решениях не так уж и много известно), то конкретно Intel впервые сделала такую интеграцию ещё в 1999 г., встроив в микросхему БИОСа ГИСЧ, фиксирующий тепловой шум в виде разности сопротивлений близко расположенных резисторов. Шум усиливался и подключался к кольцевому генератору, постоянно меняя его период. Выход генератора оцифровывался через равные промежутки, фильтровался от псевдослучайных влияний (внешние электромагнитные наводки, температура и колебания шины питания) и подавался в буфер, откуда его можно было читать спецкомандой.
Часть этой схемы является аналоговой и потребляла довольно много энергии, особенно на стадии усиления — причём постоянно, пока подано питание. 13 лет назад на лишние милливатты никто внимание не обращал, но сегодня это катастрофично. Другой минус аналоговых схем — крайне трудное моделирование, которое требуется проводить не только при проектировании первого образца, но и каждый раз при переводе чипа с этой схемой на новый техпроцесс. Разумеется, цифровые схемы также моделируются, но для них это проще благодаря детерминированности. Аналоговые же компоненты всякий раз требуют ещё и коррекции для обеспечения нужного качества сигнала, причём начиная с 45 нм это оказывается крайне трудно. Так что помимо ваттов хорошо бы сэкономить и человеко-часы инженеров. Да и 75 Кбит/с на выходе этого ГСЧ сегодня кажутся смешными — профессиональные ГИСЧ выдают 10–20 Мбит/с.
Поэтому в 2008 г. конструкторы Intel занялись созданием полностью цифрового ГИСЧ, отвечающего американским государственным стандартам на такие приборы (NIST SP800-90, FIPS-140-2 и ANSI X9.82). Спустя 4 года именно его мы и получили в IB в составе встроенного каскадного ГСЧ. Этот генератор формально нарушает одну из аксиом построения цифровой схемы: она должна находиться в точно определённом и предсказуемом состоянии. Очевидно, новый ГИСЧ должен делать прямо противоположное, но теми же транзисторами, что и обычные вентили. Для этого генератор стал метастабильным, что для обычной логики является дефектом.
 Упрощённая схема кольцевого инвертора и график одного из двух вариантов его срабатывания (второй — очевидно, инвертированное состояние первого). |
Состоит он из обычного кольцевого инвертора, который применяется в любой ячейке СОЗУ для хранения бита. Сигналом сброса оба вывода (прямой и инверсный) на очень короткое время подключаются к шине питания (т. е. логической «1»), образуя короткое замыкание. Чтобы не закоротить весь чип до снятия сброса, к питанию подключаются изолированные диодами буферные конденсаторы, которые и запитывают выводы генератора до снятия сброса. После этого каждый инвертор генерируют на выходе «0», которая смешивается с «1» и попадает на вход другого инвертора. Срединное значение на входах приводит к неустойчивому равновесию, когда малейшее отклонение из-за теплового шума сдвигает баланс к случайному из крайних состояний. Достаточно одному из инверторов хоть немного перетянуть вольтаж от центра, как его выход «убедит» напарника сдвигать своё значение в противоположном направлении — в результате через короткое время с любого инвертора можно читать бит. Момент фиксации также генерирует импульс для местного тактирования, нужный для схемы сброса и 1-й стадии обрабатывающей случайные биты логики.
|
Расположенный во внеядре ГСЧ Bull Mountain оформлен как частично асинхронный 4-стадийный конвейер (см. схему-таблицу). Стадия №2 срабатывает только после заполнения буфера перед ней. А стадии №3 и №4 имеют внешнее тактирование; причём, являясь по сути одной схемой, они не могут работать одновременно. 1-я стадия — метастабильный кольцевой инвертор, генерирующий хаос с энтропией >80%. Далее каждый бит потока смешивается с предыдущим, а результат подаётся в 512-битный регистр сдвига. Формируемые на выходе порции подаются на статистический тестер (стадия №2), который проверяет фактическую случайность порции — побитным сравнением с результатом математической модели кольцевого генератора и плавающим окном на 64 Кбит. Если энтропия недостаточна, то такую порцию отбрасывают. Т. о. после тестера темп потока качественных порций непредсказуем.
Проверенные порции подаются в очиститель (стадия №3), где делятся на половинки, которые проходят через сложные взаимные преобразования, чтобы сделать 256-битное слово-результат ещё случайней. Причина такой обработки — те самые псевдослучайные влияния, от которых пришлось защищаться ещё в 1999 г. К вышеописанному списку сегодня добавляется ещё как минимум разброс параметров транзисторов, который сильно мешает жить и дизайнерам обычных цифровых схем. На выходе очистителя стоит КБ-ГПСЧ (стадия №4), представляющий чуть изменённый аппаратный шифратор по алгоритму AES. 256-битные слова-затравки подмешиваются в поток генерируемых им 128-битных векторов псевдослучайных чисел, которые буферизуются и становятся доступными командой RDRAND. Также присутствуют схемы стартовой самопроверки и отладочные блоки. Когда все буферы заполнены, вся логика, включая кольцевой генератор, отключается от питания для сохранения энергии.
Производительность самосинхронизированного генератора энтропии — 2,5–3 Гбит/с, что зависит от параметров конкретной пары инверторов. Поэтому он сильно подвержен джиттеру (уходу частоты), с которым обычно нещадно борются. Тестер имеет собственный источник тактирования, который, как нетрудно подсчитать, считывает 512-битные порции с частотой не более 5–6 МГц. А вот очиститель и ГПСЧ тактируются твёрдыми 800 МГц (непонятно только, с какого умножителя частоты их подают — неужели с отдельного?). Очиститель, судя по всему, срабатывает за такт, а вот ГПСЧ требует 11 тактов для каждого 128-битного вектора, генерируя 0,8/11×128≈9,3 Гбит/с. Впрочем, на одной из иллюстраций указано, что верная цифра — ≈6 Гбит/с… Как только новая порция готова и протестирована, из неё тут же вычислят очередную затравку, которая сначала попадает в буфер, а в ГПСЧ будет использована через некий определяемый им самим интервал. Согласно теории (делим 800 МГц на пиковую частоту подачи порций), затравки в среднем хватит на 12–15 векторов, но документ Intel говорит, что максимум из неё можно сделать аж 511 векторов, из чего можно сделать вывод, что тестер, видимо, пропускает в среднем примерно каждую 20-ю порцию.
Аргумент RDRAND — 16-, 32- или 64-битный РОН, причём если в момент обращения буфер пуст, то вместо числа будет выставлен флаг переноса. Происходит это, когда ядра слишком часто читают буфер, быстро его опустошая. С ядрами ГСЧ связан через ту же кольцевую шину, что и остальные компоненты чипа, а потому её частота (равная частоте ядер) теоретически тоже может оказаться ограничивающим фактором. Например, если от внеядра к любому запросившему ядру передаётся только 2/4/8 байт(а)/такт (а не 32, на что способна шина), то именно эта скорость — 8 байт/такт на все ядра — и является пиковой в этом месте. Но буфер всё равно можно опустошить, т. к. темп его заполнения ещё меньше — например, для частоты ядер в 3,5 ГГц это ≈24 такта на 8-байтовое число (или даже ≈37, если цифра ≈6 Гбит/с верна). Более того, в реальных тестах время задержки при непрерывном чтении оказалось и вовсе 104 такта, что всего вдвое меньше чтения из ОЗУ. Почему — неясно.
В официальном учебнике по оптимизации для x86-ЦП Intel написано: «the total bandwidth to deliver random numbers via RDRAND by the uncore is about 500 MBytes/sec». При этом даже 2-ядерный ЦП с частотой 3 ГГц при задержке ГСЧ в 100 тактов будет читать 480 МБ/с. А если он 4-ядерный?… Другие, не менее официальные источники пишут о 800 МБ/с (т. е. 4 Гбит/с) или «70 million RDRAND invocations per second» (т. е. 560 МБ/с, если читать 8-байтовые числа), и даже «RDRAND Response Time and Reseeding Frequency — ≈150 clocks per invocation» (т. е. аж 150 тактов задержки). Все эти цитаты с детальным анализом цифр каждой из них собраны в этом обсуждении, вывод из которого простой: какая бы цифра ни была верной, темп генерации всё равно оказывается недостаточным для удовлетворения вала запросов от всех ядер, а потому уже придумана схема возможной атаки — повесить на два ядра потоки-паразиты, постоянно запрашивающие случайные числа, чтобы из вечно пустого буфера остальным программам ничего не досталось…
Тем не менее, несмотря на некоторые странности, можно заключить, что благодаря стараниям инженеров Intel мир впервые получил массовый, дешёвый и качественный источник случайных чисел. Вроде бы всё хорошо, если бы не ложка дёгтя: некоторые из прошлых криптоидей Intel также описывались как абсолютно надёжные, например — система CSS для защиты DVD. Сегодня программы копирования дисков так легко её «ломают», что большинство их пользователей и не подозревают о само́м факте взлома шифра, некогда отрекламированного как очень сильный. Почему так получилось — официально никто не объяснял. Однако в сетевых дебрях гуляют анонимные признания сотрудников, согласно которым Intel, наряду с Microsoft и другими фирмами, попала в список «охмуряемых» — некто «попросил» её реализовать слабую защиту, понадеясь на сохранение решения в тайне.
Ныне же всё может измениться. Благодаря компьютерам с процессорами IB кто угодно, включая террористов, хакеров и педофилов (любимый контингент жупелов в доводах государства за ослабление шифров…), получает возможность быстро и дёшево создавать шифры, абсолютно невзламываемые даже для самого АНБ! Неужели нам следует поверить, что на этот раз в таинственной спецслужбе внезапно перестали пробивать внедрение очередной лазейки? Или же мы всё-таки чего-то не знаем? Пока… Внеядро и ГП
Помимо добавления ГСЧ, остальные блоки внеядра («системного агента») изменились немного. ИКП для памяти DDR3 поддерживает штатные частоты до 1600 МГц, а разогнанные — до 2800 (SB — до 2133). Причём теперь их можно задавать не только с шагом 266,(6) МГц, но и 200 — в частности, 2800 это не 266,(6)×10,5 (в отличие от большинства остальных, этот множитель не может быть полуцелым), а 200×14. Мобильные ЦП смогут поддерживать экономную LP-DDR3 (с неизвестной пока частотой — тем более, что ни один ноутбук или планшет с такой памятью пока не вышел), причём у модуля памяти теперь может быть своё значение TDP для защиты от перегрева. Контроллер PCIe дорос до версии 3.0. (У Xeon на базе SB такой уже есть, но серверный чипсет X79 почему-то позволяет ЦП включать только режим 2.0…) 16 полос PCIe могут использоваться как 16, 8+8 и 8+4+4 — но не всем моделям доступны все комбинации. Шина DMI (по сути — та же PCIe на 4 полосы) осталась версии 2.0 и обеспечивает пропуск в 20 Гбит/с.
