Безопасность информационных технологий

О базовых целях и понятиях

Напомним, что, согласно текущим определениям в «Предварительный стандарт ТК-167. Термины и определения.», ПАК – комплекс радиоэлектронной продукции (РЭП) и программного обеспечения (ПО), работающих совместно для выполнения одной или нескольких специальных задач, функционально-технические характеристики которого определяются исключительно совокупностью ПО и РЭП и не могут быть реализованы при их разделении. Доверенность – это документированное (гарантированное, подтвержденное) свойство изделия соответствовать установленным требованиям функциональности (работоспособности, надежности, стойкости к условиям эксплуатации) и безопасности (функциональной, технологической и информационной). Доверенность обеспечивается достоверностью, информативностью и полнотой информации об изделии, полученных из рационального (т.е. необходимого и достаточного) сочетания данных о действующих системах менеджмента качества и информационной безопасности в ходе его стадий жизненного цикла и/или результатах тестирования и испытаний изделий.

Особенности сферы КИИ – в том, что от её беспрепятственного функционирования зависят жизни людей. Поэтому ПАК для КИИ должен отличаться повышенными функциональной безопасностью (надёжностью функционирования, отказоустойчивостью), информационной безопасностью и технологической безопасностью (локализация ключевых этапов жизненного цикла на территории России, устойчивость к санкциям, не иметь перебоев с поставками и поддержкой и т.п.). Это относится и к аппаратной, и к программной частям ПАК.

То есть, в идеальном случае ПАК должен быть:

– Функционально надёжный, отказоустойчивый;

– Информационно защищённый (если требуется);

– С жизненным циклом в России, включая российские:

– Разработку, происхождение основных технологий;

– Разработку и поддержку программного обеспечения;

– Разработку и производство ключевой ЭКБ;

– Разработку и производство изделия в целом;

– Поддержку и развитие продукта;

– С достаточной производительностью (под данную специальную задачу).

Дополнительные (желательные) свойства могут быть, в том числе, следующие:

– Масштабируемость (по мере роста нагрузки);

– Высокая экономическая эффективность (низкая стоимость жизненного цикла);

– Конкурентные характеристики, с экспортным потенциалом (для масштабирования рынка).

Разумное дополнительное требование к ПАК для КИИ – высокая эффективность взаимодействия ПО и аппаратуры (оптимизация ПО под возможности аппаратуры).

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

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

В составе ПАК, как и в целом в ИТ индустрии, наиболее дорогостоящая и важная часть стека технологий – это приложения, то есть тот компонент ПО из состава ПАК, который выполняет основную полезную работу. Все прочие уровни стека технологий выполняют служебные функции, обеспечивают функционирование приложений. Но в контексте данной статьи особенно важна та часть стека технологий, которые непосредственно обеспечивают взаимодействие аппаратной составляющей ПАК и приложений, а именно: операционная система, BIOS, компиляторы, система команд микропроцессора (Instruction set architecture, ISA) и ядро микропроцессора (логическая схема, которая непосредственно интерпретирует всё ПО в составе ПАК на основе спецификации ISA и выполняет предписанные аппаратные действия). В целом, их можно объединить под термином «аппаратно-программная платформа» (АПП), которая включает в себя спецификацию определённой ISA, и на неё ориентируются все программные составляющие АПП, а также приложения, собранные в двоичных машинных кодах.

Термин АПП сегодня не распространён, однако он имеет нормативное оформление в общем виде в стандарте ГОСТ Р 53622-2009 «Информационные технологии. Информационно-вычислительные системы. Стадии и этапы жизненного цикла, виды и комплектность документов» как «Единый комплекс средств вычислительной техники и системных программ» и в рамках общих технических требований Минобороны РФ «Общие ТТ к ОАПП МО» как «Совокупность совместно функционирующих технических и программных средств, включающая в себя: логическую схему вычислительных ядер центральных процессоров, предназначенную для интерпретации программ, средства разработки программного обеспечения и общее программное обеспечение». Именно в таком уточнённом составе АПП создаёт настоящую платформу для приложений – то есть слой, скрывающий детали реализации аппаратуры и операционной системы от приложений.

В условиях санкций и в целом турбулентности в международных взаимодействиях, мы должны быть готовы к неожиданным изменениям в аппаратной части ПАК (в частности, к отказу от поставок зарубежных процессоров с определённой ISA или к исчезновению возможности самостоятельной разработки процессоров с определённой ISA, к необходимости смены производственной площадки для процессоров, что влечёт изменение состава периферийных контроллеров и т.п.). Для этого нужно владеть жизненным циклом ПАК – всеми уровнями технологий, составляющих АПП, и быть готовыми мигрировать приложения на новую реализацию той же российской АПП (или на другую российскую АПП) с минимальными затратами.

О понятии доверенности

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

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

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

При таком подходе станет возможным по-другому подходить к сертификации программной составляющей ПАК. Например, в доказательстве правильности функционирования всей программной системы станет возможным опираться на результаты помодульного тестирования ПО и на аппаратные свойства платформы по разграничению модулей. Существующие зарубежные ISA процессоров этих возможностей не предоставляют.

Возможности российских ISA обсудим ниже.

О жизненном цикле ПАК

Определение жизненного цикла можно найти в ГОСТ Р 53622-2009, однако оно формально и не поясняет сути сложностей, выявляющихся при детальном рассмотрении стека технологий ПАК.

При разработке ПАК прежде всего разрабатывается его аппаратно-программная платформа (АПП), или берётся готовая АПП. То есть: система команд процессора, логика процессорных ядер и процессор в целом, эмуляторы, компиляторы для этой системы команд, операционная система. Далее готовятся образцы компьютеров с этим процессором, на новую АПП переносятся приложения для формирования ПАК, и дальше можно проводить отладку, поставки, обслуживание, модернизацию этого ПАК.

Если говорить о полной локализации жизненного цикла ПАК и потенциальном соответствии ПАК всем вышеуказанным требованиям, то идеальный базовый ПАК для КИИ выглядит, как минимум, так: в основе ПАК стоит процессор с российскими ядрами и с российской системой команд (Instruction Set Architecture, ISA), с российскими IP блоками, общий дизайн которого разработан в России, произведённый на российской фабрике, при его разработке использованы российские САПР. В составе ПАК установлены российская операционная система и российские прикладные программы (из российского репозитория), собранные российским компилятором в России.

В этой картине одним из главных спорных вопросов является тезис о необходимости российской разработки ISA. Но опыт АО «МЦСТ» позволяет понять с чем связана эта необходимость. Когда проводится разработка процессорного ядра в соответствии с определённой спецификацией ISA, в логику аппаратуры неизбежно попадают ошибки реализации, которые выявляются только после выпуска процессора «в кремнии». После этого есть два пути: или проводить исправление ошибок «в кремнии» и делать перевыпуск микропроцессора, или вводить программные обходы этих ошибок, если такое возможно. Программные обходы ошибок делаются на уровне операционной системы, BIOS, а для ошибок в ядре процессора – в основном в компиляторах, а именно – в подсистеме кодогенерации. Причём после внедрения обхода в компилятор требуется провести пересборку всего стека системного и прикладного ПО, чтобы наличие обхода был гарантировано для любого ПО, исполняемого в ПАК на данном выпуске процессора. Конечно, 2-й путь экономичнее (не нужно перевыпускать процессор, тратить средства, отзывать предыдущую партию процессоров с ошибкой), и в практике АО МЦСТ он доказал свою эффективность. Но если процессор разрабатывается с уже известной в мире ISA (например, x86, ARM, RISC-V) с целью быть совместимым с накопленным багажом ПО, то неисправленная ошибка вызовет несовместимость данного выпуска процессора с этим уже имеющимся объёмом ПО, собранным в двоичных кодах. Фактически, такой процессор, даже при возможности реализации программного обхода всех ошибок, выпадает из уже существующей мировой экосистемы ПО для данной ISA и требует отдельного процесса сборки ПО с учётом особенностей данного процессора – фактически, построения собственной экосистемы ПО. Чем более производительное и сложное ядро российская команда будет пытаться реализовать – тем выше вероятность внедрения ошибок, и тем меньше шансов обеспечить своими силами полную совместимость с уже известной спецификацией ISA, и пользоваться «бесплатно» экосистемой ПО, созданной за рубежом.

Поэтому, учитывая реальные возможности разработки в России, требование российского происхождения ISA – производное от требования полноты локализации жизненного цикла, а точнее, вытекает из требования возможности формировать собственные стандарты (ISA – разновидность стандарта) и вести согласно ним собственные разработки.

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

У России есть хорошая база – архитектура Эльбрус и уже созданная экосистема ПО. Тем не менее, нужно признать, что проведение собственной разработки архитектуры процессоров и перевод российской экосистемы программных продуктов, совместимых сегодня с зарубежными ISA, на свою новую доверенную платформу – затратное занятие. Поэтому одна из задач – найти оптимальный путь к развитию собственных архитектур процессоров, оснащению их совместимым ПО и их внедрением в составе ПАК, так, чтобы он был реализуем и экономически оправдан в масштабах КИИ России. 

О текущем положении в КИИ Российской Федерации

В настоящее время фактическая основа ИТ инфраструктуры в КИИ России – вычислительная техника с зарубежными процессорами, в основном х86. Значительная доля ОС – Windows разных поколений. Эта ситуация во многом повторяет общемировую. В мире сложилась олигополия аппаратно-программных платформ х86 и ARM. Вокруг них выстроены мировые экосистемы – конгломерат совместимых программных и аппаратных продуктов, каналов поставки, компетенций, который «привязан» к данной платформе и который сложно перевести на любую другую платформу. Коммерческие программные продукты дополнительно «сгруппированы» по аппаратно-программным платформам, включающим операционную систему – Windows+ARM, macOS+x86/ARM, iOS+ARM, Android+ARM, тогда как для Linux объём коммерческого ПО сравнительно мал (но уже заметен в сегменте серверного ПО, в частности в СУБД).

Введённое понятие «Доверенного ПАК» (ПП №1912 от 14.11.2023 г.) основано на уже действующих нормативных актах и фактически «легализует» status quo как норму.

А именно:

-      Требования к информационной безопасности решаются наложенными средствами и программными СЗИ (сертифицированными по требованиям ФСТЭК России), которые опираются на аппаратные свойства недоверенных процессоров.

-      Требования к технологической безопасности (иначе говоря, критерии «Российскости») задаются Постановлением Правительства №719 (для аппаратной основы) и Постановлением Правительства №1236 (для ПО), и на сегодня они позволяют использовать любые недоверенные аппаратные компоненты и ПО, не имеющее локализации жизненного цикла в России.

-      Требования к функциональной безопасности, общие для всей КИИ, отсутствуют, хотя есть ведомственные требования (например, в РЖД или Росатоме).

-      Разработчики ПО, аппаратуры, логистика и сервис в общей своей массе ориентированы на зарубежные процессоры с ISA x86 или ARM. В частности, в Едином реестре российского ПО и баз данных подавляющая часть номенклатуры ПО совместима только с архитектурой х86, реже – с ARM, и исчезающе мало – с российскими архитектурами. Аналогичная ситуация и в Реестре российской радиоэлектронной продукции.

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

О возможных путях построения доверенных ПАК для КИИ.

В 2014 г. Президент России впервые поставил задачу по развитию российской гражданской микроэлектроники. Далее за счёт государственной поддержки и регулирования рынка появились несколько моделей микропроцессоров, частично или полностью разработанных российскими дизайн-центрами и соответствующих функциональным потребностям российских гражданских информационных систем (Эльбрус-4С, Эльбрус-8С, Эльбрус-8СВ, Эльбрус-16С, Эльбрус-2С3, Байкал-Т, Байкал-М, Байкал-S, и ряд других моделей от АО МЦСТ, Байкал Электроникс, АО НПЦ Элвис, НТЦ Модуль, ПКК Миландр, НИИСИ РАН и др.). После начала СВО в 2022 г., из-за санкций, производство большинства этих процессоров остановлено, т.к. их дизайны были созданы под зарубежные полупроводниковые фабрики. Полупроводниковые фабрики на территории России по своему технологическому уровню сегодня могут производить процессоры для программируемых логических контроллеров (ПЛК), но не для персональных компьютеров и серверов.

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

Особняком стоит ISA RISC-V как возможная платформа для унификации усилий всего мира по разработке процессоров, альтернативных x86 и ARM. Не анализируя технически саму ISA, отметим следующие потенциальные «подводные камни» при принятии решения о массовом использовании процессоров с данной ISA в КИИ России (и, тем более, принятия её как приоритетного стандарта в России).

• Стандарт ISA распространяется консорциумом RISC-V International, зарегистрированного в Швейцарии. Описание ISA распространяется (как документ) под лицензией «Сreative Сommons Attribution 4.0 International License» за авторством четырёх граждан США. Эта лицензия даёт право на воспроизведение самого описания ISA, но не говорит про право на использование спецификации ISA при создании микроэлектроники.

Право на использование стандарта декларируется на официальном сайте riscv.org в разделе «Часто задаваемые вопросы» и звучит так: «The RISC-V ISA is free and open with a permissive license for use by anyone in all types of implementations. Designers are free to develop proprietary or open-source implementations for commercial or other exploitations as they see fit». Юридического документа вида «Лицензия на право использования ISA RISC-V для любых желающих» на сайте нет (в отличие от open-source ПО, где в каждом программном пакете стоит ссылка на юридически сформулированную лицензию, под которой данный пакет распространяется и может использоваться).

Эта правовая лакуна могла бы и не вызвать опасений, если бы в октябре 2023 г. в прессу не проникли сведения об обсуждениях в Конгрессе США вопроса о введении экспортного контроля на технологию RISC-V (https://www.reuters.com/technology/us-china-tech-war-risc-v-chip-technology-emerges-new-battleground-2023-10-06/), после чего исполнительный директор RISC-V Foundation Калиста Редмонд вынуждена была сделать апологетическую запись в корпоративном блоге в защиту открытых стандартов (https://riscv.org/blog/2023/10/risc-v-an-open-standard-backed-by-a-global-community-to-enable-open-computing-for-all/). Если в Конгрессе США обсуждается такой вопрос – значит, правовые рычаги для введения контроля имеются.

На сайте консорциума RISC-V International есть документ «RISC-V INTERNATIONAL ASSOCIATION AMENDED AND RESTATED INTERNAL REGULATIONS», который относится к членам ассоциации RISC-V, и в котором декларируется право на использования ISA RISC-V для членов Ассоциации: 5.1 Subject to the material compliance by the Member and any Affiliate with the terms and conditions of these Regulations including but not limited to this Appendix A, the Association agrees to and hereby grants to the Member a nonexclusive, perpetual, fully paid-up, royalty-free, copyright-only right and license throughout the universe, for so long as Member remains an Association Member, to use, reproduce, display, and implement the Final Specifications for the purpose of developing, manufacturing, distributing, selling, and otherwise exploiting Compliant Implementations (the "Member License"). Но право действует только на время членства в Ассоциации, что подтверждает наличие юридического контроля над использованием спецификации ISA RISC-V. В членство можно не допускать или его лишать по политическим причинам или в соответствии с текущим «code of conduct», а рычаги для этого имеются: Швейцария уже показала себя как не нейтральная страна, а среди топ-менеджмента RISC-V Foundation большинство – американцы и европейцы, CEO – выходец из IBM.

• Принятие новых технических решений в ISA RISC-V идёт через технические комитеты, где инициатива со стороны российских членов не обязана быть принята в общий стандарт. Если какое-то расширение ISA RISC-V будет реализовано со стороны России без внесения в стандарт, то все изменения для его поддержки в компиляторы, библиотеки и операционную систему придётся делать самостоятельно, и соответственно самостоятельно собирать весь стек ПО.
• В условиях конкуренции со стороны всех прочих мировых игроков, участвующих в разработке чипов по стандарту ISA RISC-V, шансы на лидерство именно у российских дизайн-центров сложно оценить как высокие, потому что (а) в России объективно мало опытных разработчиков RISC процессоров, (б) сложно вести разработку из-за санкций, и (в) на поле защиты технических решений (патентования) зарубежные дизайн-центры намного сильнее, чем российские. Более того, не исключено формирование расширений ISA RISC-V, которые будут проприетарными де-юре или де-факто, и если такие расширения введёт лидер (или олигополия лидеров) и «продавит» их повсеместное использование – то и вся экосистема RISC-V постепенно станет зависимой от этой олигополии, а не от российских разработчиков.
• Бизнес может решить, что ему выгодно лицензировать хорошее ядро RISC-V
  из-за рубежа (а не полноценно вести разработку ядра в России), но заявить при этом, что разработка была проведена самостоятельно. Такой подлог будет крайне сложно обнаружить и доказать, а по сути, он позволит такому бизнесу резко выйти в лидеры по выручке, захватить российский рынок и разорить конкурентов (при этом поставив КИИ под угрозу кибератак, нацеленных на уязвимости именно данной модели ядра процессора, известных зарубежной компании-вендору и неизвестных российской стороне).
• На прочих стадиях жизненного цикла (включая создание компиляторов, операционных систем, стека прикладного ПО) разработчики процессоров RISC-V будут решать менее сложную задачу, чем разработчики процессоров с российской системой команд, и за счёт этого получат над ними преимущество в time-to-market /cost redution, не создавая при этом в России полноценный жизненный цикл АПП (включая весь набор компетенций), но при этом будут подвержены более высоким рискам технологической зависимости. Если они реализуются – то снова потребуется возвращаться к основам – созданию полноценного жизненного цикла, но в худших условиях.

Указанные риски и вопросы не означают, что плодами экосистемы RISC-V нельзя пользоваться для построения ПАК для КИИ, но эти риски нужно хорошо понимать и стремиться воспроизводить жизненный цикл платформы на территории России во всей возможной полноте. Проектам на базе RISC-V необходим особый контроль за отсутствием фальсификаций, а господдержку в целом для достижения целей Указа №166 необходимо направить в первую очередь на путь, не зависящий от зарубежных ISA.

Единственный ясный и надёжный способ строить доверенные ПАК для КИИ – это разрабатывать для них собственные аппаратно-программные платформы (АПП), которые включают в себя архитектуры ISA, микропроцессоры, инструменты разработки ПО (компиляторы) и операционные системы с программными СЗИ, с российским жизненным циклом. При этом архитектура процессоров должна учитывать текущие и перспективные требования по безопасности. На основе такой АПП можно будет строить ПАКи, задействуя все полезные свойства архитектуры, и иметь обоснованно более высокие показатели доверенности.

Об опыте построения аппаратно-программной платформы Эльбрус
в контексте ПАК для КИИ

Опыт создания АПП Эльбрус может подсказать путь наиболее экономичного и реалистичного достижения цели – построения ИКТ в виде ПАК для КИИ на технологически независимой, информационно защищённой и функционально надёжной основе – без указанных выше рисков и компромиссов, с плавной «отстройкой» при внедрении от зарубежных платформ. При этом на примере АПП Эльбрус можно оценить сложности и затраты на построение как самой платформы, так и экосистемы совместимого ПО.

Жизненный цикл АПП Эльбрус состоит из следующих этапов:

• Разработка ISA Эльбрус для нового поколения процессора.
• Разработка Verilog описания ядра / процессора.
• Написание верификационных тестов.
• Создание прототипа процессора на основе ПЛИС.
• Разработка программных симуляторов ядра процессора и компьютера в целом.
• Разработка компилятора/двоичного транслятора для ISA нового поколения.
• Разработка генератора тестов для процессора (машинный код и ЯВУ).
• Создание базы направленных программных тестов.
• Разработка ОС под новое поколение процессора:
  • Портирование ядра и системных библиотек.
  • Перенос прикладного ПО на новое поколение системы команд.
  • Регулярные сборки в кроссовом режиме (на х86 серверах) .
  • Пред-кремниевая верификация описания процессора на прототипе с готовым дистрибутивом и инженерными тестами. 
  • Пост-кремниевая верификация чипов с готовым дистрибутивом и инженерными тестами.

Цикл разработки аппаратуры процессора включает в себя: разработку и производство прототипа на ПЛИСах, создание высокоуровневого описания, его всестороннюю верификацию, проведение физического проектирования, выпуск (тейп-аут), запуск инженерных образцов процессора на стендах и пост-кремниевый анализ/верификацию. Работа САПР верифицируется через кросс-проверки работы тулов от разных производителей.

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

Опыт показал, что в общей задаче подготовки новой платформы к внедрению (например, нового поколения архитектуры Эльбрус) очень большое время уходит на подготовку программной части, особенно компиляторов, на перенос прикладного ПО, отладку ошибок и шлифовку производительности. Правильно выстраивая порядок действий, АО «МЦСТ» проводит значительную часть работ, ещё не имея работающих кристаллов и даже до конца проработанного логического описания процессора.

Особенности аппаратно-программной платформы Эльбрус для КИИ

ISA Эльбрус изначально построена на принципе VLIW (если учитывать все механизмы, внедрённые в аппаратуру для повышения производительности – то она близка к EPIC). Подход был выбран исходя из условий работы коллектива МЦСТ в России (сильная команда разработки компилятора, опыт создания высокопроизводительных машин в советское время и проработка подхода VLIW на МВК Эльбрус-3, при невозможности набрать коллектив разработчиков аппаратуры в объёме, характерном для зарубежных лидеров) и оправдал себя. Результат – линейка высокопроизводительных процессоров Эльбрус 6-ти поколений, работоспособных и проверенных в ряде крупных проектов.

Сегодня процессоры последней (6-й) версии архитектуры Эльбрус имеет все необходимые общепринятые технологии, востребованные на широком рынке: многоядерная и многопроцессорная компоновка (до 64-х ядер на общей памяти), интеграция современных интерфейсов на кристалле (DDR4, PCIe 3), технологии виртуализации, энергосбережения, обеспечения надёжности (уровня серверных процессоров) и т.п.

Особые черты платформы Эльбрус следующие:

Производительность:

-      Возможность запланировать до 25-ти скалярных (не векторных) операций в широкой команде в такт в каждом ядре процессора. Из них: до 6-ти универсальных арифметико-логических операций, а при склеивании двух операций в одну
4-х аргументную (в стиле FMA) – до 12-ти; до 4-х операций загрузки (load)/до
2-х операций сохранения (store), до 4-х операций инкремента адреса, операция инкремента цикла, условное выполнение перехода, 3 логических сравнения.

-      Система программируемой асинхронной загрузки данных из памяти.

-      Программно-поддержанные спекулятивные операции и предикатные вычисления.

-      Наличие 3 дополнительных конвейеров для подготовки переходов.

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

В 7-й версии ISA Эльбрус дополнительно вводятся аппаратные средства автоматической предзагрузки данных в кэш (auto-prefetch) и предсказатели переходов, добавлены средства ускорения криптовычислений и нейровычислений.

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

Совместимость:

-      На уровне исходных кодов: поддержка компиляторами платформы Эльбрус формата расширений С/С++ в соответствии с практикой компиляторов GCC. Наличие Java-машины и .NET рантайма.

-      На уровне отдельных приложений в среде Linux: программный слой двоичной трансляции приложений в кодах х86/х86-64 в двоичные коды Эльбрус.

-      На уровне операционных систем: программный слой двоичной трансляции уровня системы из кодов х86/х86-64 в двоичные коды Эльбрус.

Возможна инкапсуляция существующих программных систем вместе с ОС в кодах х86 внутри виртуальных машин и их запуск на процессорах Эльбрус 6-го поколения. Накладные расходы на двоичную трансляцию в обоих сценариях – порядка 20%.

Информационная защищённость и технологии аппаратной изоляции:

- Защищённость от ряда кибератак за счёт особой структуры стеков

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

Технология может применяться ко всем компилируемым языкам (С/С++/Фортран/go/Rust) и придаёт им свойства managed языков типа Java и .NET.

(Продолжение следует)

 Константин А. Трушкин, заместитель генерального директора по маркетингу, АО «МЦСТ»

ул. Профсоюзная, д. 108, 117437, Москва, Россия

e-mail: trushkin_k@mcst.ru, https:/orcid.org/0009-0001-0053-3355