Цифровой журнал «Компьютерра» 2011 № 41 (89) - [4]

Это произошло более пяти лет тому назад одновременно с внедрением шестидесятичетырёхбитного режима, и оказалось малоэффективной мерой — хакеры научились обходить эту защиту. Была понятна и основная причина такой слабости: защитные механизмы работали на том же программном уровне, что и вирусные программы. Короче говоря, вирусы научились сначала отключать эту аппаратуру, а затем уже выполнять свои функции.

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

Конечно, можно ограничиться мыслью, что рынок «созрел», пора отправляться бизнесменам в Страну Дураков и выкапывать на поле чудес кучи «золотых сольдо». Но, думаю, есть ещё один фактор, который существенно повлиял на принятие такого серьёзного финансового решения. Этот фактор можно образно назвать фактором красного (жёлтого) дракона.

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

После информации об организационном масштабе (покупка фактически непрофильного актива) и огромной сумме вложений (называлась сумма в семь миллиардов долларов) стало понятно, что решаться проблема безопасности будет комплексно и радикально. Похоже, решили устранить самые принципиальные корневые проблемы — так сказать, «ахиллесовы пяты» самой архитектуры вычислительного процесса. Отложенные про запас, но очевидные для специалистов изменения и дополнения в архитектуре вычислительного процесса начнут постепенно реализовывать в кремнии.

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

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

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

Инфраструктура защиты должна быть вынесена с уровня программирования, доступного операционной системе и тем более прикладным программам. Не вдаваясь в подробности, можно сослаться на печальный опыт внедрения защиты с использованием NEX бита: его просто научились отключать.

На данный момент в архитектуре х86/64 таких независимых уровня два: это уровень режима системного менеджмента (SMM режим) и уровень хоста Гипервизор. Кроме этого, у Intel есть один малоизвестный режим работы процессора – логический режим доверенного выполнения (XSMM). Если всерьёз подходить к борьбе с вирусами, то, конечно, аппаратура контроля вирусной активности должна управляться программами, работающими именно в этих режимах, хотя ничего не мешает ввести новый режим, специально заточенный под специфику решаемой задачи.

Кроме этого, для антивирусных программ пользовательского уровня и уровня ОС следует предоставить доверенный командный интерфейс, по типу реализованного в ТРМ-модулях. Заодно можно побороться с пиратами, на радость блюстителей авторских прав, заставив контролировать в точках старта программ наличие легальных сертификатов с помощью того же ТРМ-модуля.

С инфраструктурой понятно, теперь вопрос: что контролировать?

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

В сумме эти методы эксплуатируют всего ТРИ архитектурных уязвимости. Следовательно, можно поставить на аппаратный контроль нарушение архитектурных соглашений, которые декларируются, но не контролируются на настоящий момент. Пока звучит туманно, но думаю, из дальнейшего сразу станет понятным.

Первая и самая серьёзная архитектурная уязвимость — это однородность оперативной памяти: в ней все можно хранить в произвольном порядке. Конечно, имеются соглашения на уровне ОС о распределении адресных пространств, часть этих соглашений уже давно контролируется аппаратурой (в области ОС нельзя работать прикладным программам), но только часть. Атака, направленная на повышение уровня привилегий, как раз и эксплуатирует уязвимость в архитектуре, не защищённую аппаратурой. В области прикладных программ пока разрешено работать программам с привилегиями уровня ядра ОС, и именно этим пользуются хакеры.