О базовых целях и понятиях Напомним, что, согласно текущим определениям в «Предварительный стандарт ТК-167. Термины и определения». [2], ПАК – комплекс радиоэлектронной продукции (РЭП) и программного обеспечения (ПО), работающих совместно для выполнения одной или нескольких специальных задач, функционально-технические характеристики которого определяются исключительно совокупностью ПО и РЭП и не могут быть реализованы при их разделении. Доверенность – это документированное (гарантированное, подтвержденное) свойство изделия соответствовать установленным требованиям функциональности (работоспособности, надежности, стойкости к условиям эксплуатации) и безопасности (функциональной, технологической и информационной). Доверенность обеспечивается достоверностью, информативностью и полнотой информации об изделии, полученных из рационального (т.е. необходимого и достаточного) сочетания данных о действующих системах менеджмента качества и информационной безопасности в ходе его стадий жизненного цикла и/или результатах тестирования и испытаний изделий. Особенности сферы КИИ – в том, что от её беспрепятственного функционирования зависят жизни людей. Поэтому ПАК для КИИ должен отличаться повышенными функциональной безопасностью (надёжностью функционирования, отказоустойчивостью), информационной безопасностью и технологической безопасностью (локализация ключевых этапов жизненного цикла на территории России, устойчивость к санкциям, не иметь перебоев с поставками и поддержкой и т.п.). Это относится и к аппаратной, и к программной частям ПАК. То есть, в идеальном случае ПАК должен быть: – Функционально надёжный, отказоустойчивый – Информационно защищённый (если требуется) – С жизненным циклом в России, включая российские: – Разработку, происхождение основных технологий – Разработку и поддержку программного обеспечения – Разработку и производство ключевой ЭКБ – Разработку и производство изделия в целом – Поддержку и развитие продукта – С достаточной производительностью (под данную специальную задачу) Дополнительные (желательные) свойства могут быть, в том числе, следующие: – Масштабируемость (по мере роста нагрузки) – Высокая экономическая эффективность (низкая стоимость жизненного цикла) – Конкурентные характеристики, с экспортным потенциалом (для масштабирования рынка). Разумное дополнительное требование к ПАК для КИИ – высокая эффективность взаимодействия ПО и аппаратуры (оптимизация ПО под возможности аппаратуры). Не все эти свойства сразу могут быть выполнены одновременно (например, сложно добиться дешевизны и конкурентоспособности при условии локализации жизненного цикла), но цель от этого не меняется. При этом может быть выбран тот или иной путь достижения цели. Проблема выбора пути заключается в комплексном характере решаемой задачи и большом (в настоящее время) расстоянии между желаемым и действительным состояниями дел. Кроме того, выполнение всех указанных выше свойств требует декомпозиции стека технологий, включённых в состав ПАК, и применение данных требований к каждому уровню технологий по отдельности.
В составе ПАК, как и в целом в ИТ индустрии, наиболее дорогостоящая и важная часть стека технологий – это приложения, то есть тот компонент ПО из состава ПАК, который выполняет основную полезную работу. Все прочие уровни стека технологий выполняют служебные функции, обеспечивают функционирование приложений. Но в контексте данной статьи особенно важна та часть стека технологий, которые непосредственно обеспечивают взаимодействие аппаратной составляющей ПАК и приложений, а именно: операционная система, BIOS, компиляторы, архитектура системы команд микропроцессора (Instruction set architecture, ISA) и ядро микропроцессора (логическая схема, которая непосредственно интерпретирует всё ПО в составе ПАК на основе спецификации ISA и выполняет предписанные аппаратные действия). В целом, их можно объединить под термином «аппаратно-программная платформа» (АПП). Наличие или отсутствие суверенитета в части АПП определяет, будет ли обеспечен технологический суверенитет для ПАК в целом. Термин АПП сегодня не распространён, однако он имеет нормативное оформление в общем виде в стандарте ГОСТ Р 53622-2009 «Информационные технологии. Информационно-вычислительные системы. Стадии и этапы жизненного цикла, виды и комплектность документов» как «Единый комплекс средств вычислительной техники и системных программ». Если попытаться выбрать абсолютный минимум из полного стека технологий, соответствующий определению из ГОСТ Р 53622-2009, то можно его сформулировать как «Совокупность совместно функционирующих технических и программных средств, включающая в себя: логическую схему вычислительных ядер центральных процессоров, предназначенную для интерпретации программ, средства разработки программного обеспечения и общее программное обеспечение». Именно в таком уточнённом составе АПП создаёт настоящую платформу для приложений – то есть слой, скрывающий детали реализации аппаратуры и операционной системы от приложений. АПП включает в себя спецификацию определённой ISA, и на неё ориентируются все программные составляющие АПП, а также приложения, собранные в двоичных машинных кодах. В условиях санкций и в целом турбулентности в международных взаимодействиях, мы должны быть готовы к неожиданным изменениям в аппаратной части ПАК (в частности, к отказу от поставок зарубежных процессоров с определённой ISA или к исчезновению возможности самостоятельной разработки процессоров с определённой ISA, к необходимости смены производственной площадки для процессоров, что влечёт изменение состава периферийных контроллеров и т.п.). Для этого нужно владеть жизненным циклом ПАК – всеми уровнями технологий, составляющих АПП, и быть готовыми мигрировать приложения на новую реализацию той же российской АПП (или на другую российскую АПП) с минимальными затратами. О понятии доверенности В определении доверенности, приведённом в «Предварительный стандарт ТК-167. Термины и определения», указана альтернатива: обосновывать какие-либо свойства контролем жизненного цикла (процесса разработки) и/или результатами тестирования и испытания изделий. Путь «тестирования и испытаний» кажется привлекательным в силу его кажущейся простоты: не требуется проводить доказательства правильности поведения того или иного механизма, регламентировать и изучать путь его разработки, достаточно провести сколь возможно тщательное его тестирование. Но чем сложнее рассматриваемая система – тем сложнее обосновать какие-либо её свойства через тестирование, даже длительное и изобретательное. Пространство внутренних состояний логической схемы процессора или средней прикладной программы настолько велико, что никаким внешним тестированием или фаззингом невозможно перебрать его полностью. Поэтому гарантировать свойства доверенности таких сложных систем, как современные высокопроизводительные ПАК можно только через полноценное освоение их жизненного цикла силами отечественных предприятий и введением контроля над процессом разработки, который должен быть ориентирован на надёжность и безопасность, с многоуровневой системой верификации, с применением инструментов поиска/изоляции ошибок на всех этапах жизненного цикла. Особые возможности могла бы дать сквозная интеграция средств защиты информации (СЗИ) в архитектуру ПАК и внедрение в аппаратуру процессора средств разграничения программных модулей, с последующей целенаправленной верификацией этих подсистем аппаратуры (включая доказательство правильности функционирования). При таком подходе станет возможным по-другому подходить к сертификации программной составляющей ПАК. Например, в доказательстве правильности функционирования всей программной системы станет возможным опираться на результаты помодульного тестирования ПО и на аппаратные свойства платформы по разграничению модулей. Существующие зарубежные ISA процессоров этих возможностей не предоставляют. Возможности российских ISA обсудим ниже. О жизненном цикле ПАК Определение жизненного цикла можно найти в ГОСТ Р 53622-2009, однако оно формально и не поясняет сути сложностей, выявляющихся при детальном рассмотрении стека технологий ПАК. При разработке ПАК прежде всего разрабатывается его аппаратно-программная платформа (АПП), или берётся готовая АПП. То есть: выбирается/разрабатывается система команд процессора, разрабатываются логика процессорных ядер и процессор в целом, эмуляторы, компиляторы для этой системы команд, операционная система. Далее создаются образцы компьютеров с этим процессором, на новую АПП переносятся (портируются) приложения для формирования ПАК, и дальше можно проводить отладку, поставки, обслуживание, модернизацию этого ПАК.
Если говорить о полной локализации жизненного цикла ПАК и потенциальном соответствии ПАК всем вышеуказанным требованиям, то идеальный базовый ПАК для КИИ выглядит, как минимум, так: в основе ПАК стоит микропроцессор с российскими ядрами и с российской системой команд (Instruction Set Architecture, ISA), с российскими IP блоками, общий дизайн которого разработан в России, произведённый на российской фабрике, при его разработке использованы российские САПР. В составе ПАК установлены российская операционная система и российские прикладные программы (из российского репозитория), собранные российским компилятором в России. В этой картине одним из спорных вопросов является тезис о необходимости российской разработки ISA. Опыт АО «МЦСТ» позволяет понять, с чем связана эта необходимость. Когда проводится разработка процессорного ядра в соответствии с определённой спецификацией ISA, в логику аппаратуры неизбежно попадают ошибки реализации, которые выявляются только после выпуска процессора «в кремнии». После этого есть 2 пути: или проводить исправление ошибок «в кремнии» и делать перевыпуск микропроцессора (с отзывом уже поставленных чипов), или вводить программные обходы этих ошибок, если такое возможно. Программные обходы ошибок делаются на уровне операционной системы, BIOS, в компиляторах в подсистеме кодогенерации. После внедрения обхода в компилятор требуется провести пересборку всего стека системного и прикладного ПО, чтобы наличие обхода было гарантировано для любого ПО, исполняемого на данном выпуске процессора. Конечно, 2-й путь экономичнее (не нужно тратить время и средства на перевыпуск процессора, отзывать предыдущую партию процессоров с ошибкой и т.п.)), и в практике АО МЦСТ он доказал свою эффективность. Но если процессор разрабатывается с уже заданной на уровне мирового стандарта ISA (например, x86, ARM, RISC-V) и с целью быть двоично-совместимым с накопленным багажом ПО, то неисправленная ошибка вызовет несовместимость данного выпуска процессора с этим уже имеющимся объёмом ПО, собранным в двоичных кодах для других процессоров других производителей, не имеющих этой ошибки. Такой процессор, даже при возможности реализации программного обхода всех ошибок, выпадает из уже существующей мировой экосистемы ПО для данной ISA и требует отдельного процесса сборки ПО с учётом особенностей данного процессора – фактически, потребуется построение собственной экосистемы ПО. Чем более производительное ядро российская команда будет пытаться реализовать – тем выше вероятность внедрения подобных ошибок, тем сложнее их находить (и тем позже они будут выявляться), тем меньше шансов обеспечить полную совместимость с уже известной спецификацией ISA, и пользоваться «бесплатно» экосистемой ПО, созданной за рубежом. Поэтому требование российского происхождения ISA – не только производное от требования полноты локализации жизненного цикла (которое, в свою очередь, вытекает из требования возможности формировать собственные стандарты (ISA – разновидность стандарта) и вести согласно ним собственные разработки), но и требование экономической, практической реализуемости проведения полноценной разработки высокопроизводительных процессоров силами российских дизайн-центров и их внедрения в широком масштабе. Другой аспект – это возможность введения собственных расширений в ISA для её развития темпом, опережающим мировой уровень. Это, в частности, требуется в сфере информационной безопасности. Нет возможности ждать, пока «мировое сообщество» внедрит в ISA аппаратные инструкции для усиления безопасности – ведь в тот момент атакующая сторона уже успеет приспособить свои методы атаки к этому мировому уровню. Многие серьёзные возможности по наращиванию производительности (например, в криптоалгоритмах) также идут через введение новых расширений ISA. В итоге, и конкурентоспособность процессора зависит от развития ISA – и от того, кто и где принимает такие решения – в России или за рубежом. Конечно, проведение собственной разработки архитектуры процессоров и перевод российской экосистемы программных продуктов, совместимых с зарубежными ISA, на свою доверенную платформу — затратное занятие. Одна из задач – найти оптимальный путь к развитию собственных архитектур процессоров, оснащению их совместимым ПО и их внедрением в составе ПАК, так, чтобы он был реализуем и экономически оправдан в масштабах КИИ России. У России уже есть хорошая база – архитектура Эльбрус и его экосистема ПО. Этот опыт позволяет достоверно оценивать технические и экономические сложности на пути построения суверенитета. О текущем положении в КИИ Российской Федерации В настоящее время фактическая основа ИТ инфраструктуры в КИИ России – вычислительная техника с зарубежными процессорами, в основном с ISA х86. Значительная доля ОС – Windows разных поколений. Эта ситуация во многом повторяет общемировую. В мире сложилась олигополия аппаратно-программных платформ х86 и ARM. Вокруг них выстроены мировые экосистемы – конгломерат совместимых программных и аппаратных продуктов, каналов поставки, компетенций, который «привязан» к данной платформе и который сложно перевести на любую другую платформу. Коммерческие программные продукты дополнительно «сгруппированы» по аппаратно-программным платформам, включающим операционную систему – Windows+ARM, macOS+x86/ARM, iOS+ARM, Android+ARM, тогда как для Linux объём коммерческого ПО сравнительно мал (но уже заметен в сегменте серверного ПО, в частности в СУБД). Часть этих экосистем не подконтрольны России ни сегодня, ни в будущем – на базе ОС Windows, iOS, macOS. Отметим, что сегодня разработчики ПО, аппаратуры, логистика и сервис в общей своей массе ориентированы на зарубежные процессоры с ISA x86 или ARM и зарубежные ОС. В частности, в Едином реестре российского ПО и баз данных подавляющая часть номенклатуры ПО совместима только с архитектурой х86, реже – с ARM, и исчезающе мало – с российскими архитектурами. Аналогичная ситуация и в Реестре российской радиоэлектронной продукции. Понятие «Доверенного ПАК» введено Постановлением Правительства №1912 от 14.11.2023 г., основано на действующих нормативных актах и фактически «легализует» status quo как норму. А именно: – Требования к информационной безопасности решаются наложенными средствами и программными СЗИ (сертифицированными по требованиям ФСТЭК или ФСБ), которые опираются на аппаратные свойства недоверенных процессоров. – Требования к технологической безопасности (иначе говоря, критерии «российскости») задаются Постановлением Правительства №719 от 17 июля 2015 г. (для аппаратной основы) и Постановлением Правительства №1236 от 16 ноября 2015 г. (для ПО), и в настоящее время они позволяют использовать любые недоверенные аппаратные компоненты и ПО, не имеющее локализации жизненного цикла в России. – Требования к функциональной безопасности, общие для всей КИИ, отсутствуют, хотя есть ведомственные требования (например, в РЖД или Росатоме). Такой формальный подход к определению «доверенных ПАК» не имеет ничего общего с фундаментальным понятием доверенности. В рамках Технического комитета ТК167 ведётся обсуждение требований к «правильным» доверенным ПАК, но этот процесс ещё далёк от завершения. О возможных путях построения доверенных ПАК для КИИ. В 2015 г. Президент России впервые поставил задачу по развитию российской гражданской микроэлектроники (поручения Пр-2135 от 13 октября 2015 г.), далее за счёт государственной поддержки и регулирования рынка появились несколько моделей микропроцессоров, частично или полностью разработанных российскими дизайн-центрами и соответствующих потребностям российских гражданских информационных систем (Эльбрус-4С, Эльбрус-8С, Эльбрус-8СВ, Эльбрус-16С, Эльбрус-2С3, Байкал-Т, Байкал-М, Байкал-S и ряд других моделей от АО МЦСТ, Байкал Электроникс, АО НПЦ Элвис, НТЦ Модуль, ПКК Миландр, НИИСИ РАН и др.). После начала СВО в 2022 г. из-за санкций производство большинства этих процессоров остановлено, т.к. их дизайны и производство были организованы под зарубежные полупроводниковые фабрики, а государственное регулирование рынка радикально ослаблено (допускает применение зарубежных процессоров в российской продукции). Полупроводниковые фабрики на территории России по своему технологическому уровню сегодня могут производить процессоры для программируемых логических контроллеров (ПЛК), но не для персональных компьютеров и серверов. Тем не менее, и ПЛК может считаться ПАКом для КИИ, вопрос о его доверенности ставить можно и нужно. Минпромторгом были озвучены планы по развёртыванию фабрик с современными технологическими нормами (до уровня 28 нм), что позволит в будущем создавать полноценный жизненный цикл ПАКов, не привязанный к зарубежным производствам. Таким образом, нужно рассматривать пути построения ПАК для КИИ со всей возможной строгостью требований к их доверенности и функционалу, без скидок на текущую нормативную и санкционную действительность. Строго говоря, использовать «готовые покупные» зарубежные процессоры для доверенных ПАК недопустимо. Как альтернатива, кажется привлекательным (быстро, дёшево, готовая экосистема ПО) и возможным выходом использование для создания доверенных ПАК для КИИ процессоров, разработанных российскими дизайн-центрами на основе лицензированных ключевых блоков (процессорных ядер) с проприетарными зарубежными ISA (ARM прежде всего). Но фундаментальным решением для создания доверенной АПП оно не станет и не может стать. Процессоры с такими системами команд практически не могут быть реализованы с полным жизненным циклом силами российских коллективов (ввиду правовой защиты ISA, сложности создания логики процессоров из-за запатентованных за рубежом решений и т.п.). Нет возможности проведения верификации и доказательства правильности поведения базовых механизмов работы процессора (например, подсистемы разграничения адресных пространств процессов или виртуальных машин). На внедрение таких процессоров и на адаптацию ПО к ним будут потрачены значительные средства, но на примере действий ARM после начала СВО (прекращение взаимодействия со всеми дизайн-центрами России) видно, как легко вендор ядра и архитектуры – ключевой части процессоров – может прекратить поддерживать своих российских партнёров, несмотря ни на какие хорошие отношения и безупречную (с точки зрения отсутствия отношений с «оборонкой») репутацию, и тем самым обрушить их бизнес и все усилия по переносу ПО и созданию аппаратных решений на этих платформах. То есть перспектив законной самостоятельной российской разработки доверенных процессоров с этими системами команд нет и не будет. Особняком стоит ISA RISC-V как возможная платформа для унификации усилий всего мира по разработке процессоров, альтернативных платформам x86 и ARM. Не анализируя технически саму ISA RISC-V, отметим следующие потенциальные «подводные камни» при принятии решения о массовом использовании процессоров с данной ISA в КИИ России (и, тем более, принятия её как приоритетного стандарта в России). Стандарт ISA продвигается консорциумом RISC-V International, зарегистрированным в Швейцарии. Описание ISA распространяется (как документ) под лицензией «Сreative Сommons Attribution 4.0 International License» за авторством четырёх граждан США. Такой вид лицензии даёт право на воспроизведение самого описания ISA, но ничего не говорит про право использования на спецификации ISA при создании микроэлектроники. Право на использование стандарта декларируется на официальном сайте riscv.org в разделе «Часто задаваемые вопросы» (https://riscv.org/about/faq/) и звучит так: «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 для любых желающих» на сайте консорциума RISC-V International нет (в отличие от 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» (https://riscv.org/wp-content/uploads/2022/03/RISC-V-Amended-Internal-Regulations-APPROVED-2022-Feb-17.pdf), который относится к членам ассоциации 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. В членство можно не допускать или его лишать по политическим причинам, рычаги для этого имеются: Швейцария уже показала себя как не нейтральная страна, среди топ-менеджмента RISC-V Foundation большинство – американцы и европейцы, CEO – выходец из IBM. Принятие новых технических решений в ISA RISC-V идёт через технические комитеты, где инициатива со стороны российских членов не обязана быть принята в общий стандарт. Если какое-то расширение ISA RISC-V будет реализовано со стороны России без внесения в стандарт, то все изменения для его поддержки в компиляторы, библиотеки и операционную систему придётся делать самостоятельно, и соответственно самостоятельно собирать весь стек ПО. А в случае принятия в стандарт ISA консорциоумом RISC-V Foundation других операций с теми же опкодами, то возникнет коллизия, и в мировом масштабе она будет решаться не в пользу российских членов дизайн-центров. В условиях конкуренции со стороны всех прочих мировых игроков, участвующих в разработке чипов по стандарту ISA RISC-V, шансы на лидерство именно у российских дизайн-центров сложно оценить как высокие, потому что (а) в России объективно мало опытных разработчиков процессоров, (б) разработку сложно вести из-за санкций, и (в) на поле защиты технических решений (патентования) зарубежные компании намного сильнее, чем российские. Не исключено появление расширений ISA RISC-V, которые будут проприетарными де-юре или де-факто, и если такие расширения введёт лидер (или олигополия лидеров) и «продавит» их повсеместное использование – то и вся экосистема RISC-V постепенно станет зависимой от этой олигополии, а не от российских разработчиков. Бизнес может решить, что ему выгодно лицензировать хорошее ядро RISC-V из-за рубежа (а не полноценно вести разработку ядра в России), но заявить при этом, что разработка была проведена самостоятельно. Такой подлог будет крайне сложно обнаружить и доказать, а по сути, он позволит такому бизнесу резко выйти в лидеры по выручке, захватить российский рынок и разорить конкурентов, при этом поставив КИИ под угрозу кибератак, нацеленных на уязвимости именно данной модели ядра процессора, известных зарубежной компании-вендору и неизвестных российской стороне. На прочих стадиях жизненного цикла (включая создание компиляторов, операционных систем, стека прикладного ПО) разработчики процессоров RISC-V будут решать менее сложную задачу, чем разработчики процессоров с российской системой команд, и за счёт этого получат над ними преимущество в time-to-market /cost redution, не создавая при этом в России полноценный жизненный цикл АПП (включая весь набор компетенций), но при этом будут подвержены более высоким рискам технологической зависимости. Если они реализуются – то снова потребуется возвращаться к основам – созданию полноценного жизненного цикла, но в худших условиях. Указанные риски и вопросы не означают, что плодами экосистемы RISC-V нельзя пользоваться для построения ПАК для КИИ, но эти риски нужно хорошо понимать и стремиться воспроизводить жизненный цикл платформы на территории России во всей возможной полноте. Проектам на базе RISC-V необходим особый контроль за отсутствием фальсификаций, а господдержку в целом для достижения целей Указа №166 необходимо направить в первую очередь на путь, не зависящий от зарубежных ISA, а проектам на базе ISA RISC-V необходим особый контроль за отсутствием фальсификаций. Единственный ясный и надёжный способ строить доверенные ПАК для КИИ – это разрабатывать для них собственные аппаратно-программные платформы (АПП), которые включают в себя архитектуры ISA, микропроцессоры, инструменты разработки ПО (компиляторы) и операционные системы с программными СЗИ, с российским жизненным циклом. При этом архитектура процессоров должна учитывать текущие и перспективные требования по безопасности. На основе такой АПП можно будет строить ПАКи, задействуя все полезные свойства архитектуры, и иметь обоснованно более высокие показатели доверенности. Об опыте построения аппаратно-программной платформы Эльбрус Опыт создания АПП Эльбрус может подсказать путь наиболее экономичного и реалистичного достижения цели – построения ИКТ в виде ПАК для КИИ на технологически независимой, информационно защищённой и функционально надёжной основе – без указанных выше рисков и компромиссов, с плавной «отстройкой» при внедрении от зарубежных платформ. При этом на примере АПП Эльбрус можно оценить сложности и затраты на построение как самой платформы, так и экосистемы совместимого ПО. Жизненный цикл АПП Эльбрус состоит из следующих этапов:
Цикл разработки аппаратуры процессора включает в себя: разработку и производство прототипа на ПЛИСах, создание высокоуровневого описания, его всестороннюю верификацию, проведение физического проектирования, выпуск (тейп-аут), запуск инженерных образцов процессора на стендах и пост-кремниевый анализ/верификацию. Работа САПР верифицируется через кросс-проверки работы тулов от разных производителей.
Одновременно разрабатываются программная часть: эмулятор и компиляторы, автоматические тесты для них, технологическая операционная система с дистрибутивом, которые потом проверяют работу логической схемы процессора на прототипе и, в конце, помогают тестировать инженерные образцы микросхем. Цепочка разработки ПО в МЦСТ построена на кроссовой компиляции, то есть проводится на серверах с процессорами х86 с генерацией двоичных кодов для процессоров Эльбрус любых поколений. Опыт показал, что в общей задаче подготовки новой платформы к внедрению (например, нового поколения архитектуры Эльбрус) очень большое время уходит на подготовку программной части, особенно компиляторов, на перенос прикладного ПО, отладку ошибок и шлифовку производительности. Правильно выстраивая порядок действий, АО «МЦСТ» проводит значительную часть работ, ещё не имея работающих кристаллов и даже до конца проработанного логического описания процессора. Особенности аппаратно-программной платформы Эльбрус для КИИ ISA Эльбрус изначально построена на принципе VLIW (если учитывать все механизмы, внедрённые в аппаратуру для повышения производительности – то она близка к EPIC). Подход был выбран исходя из условий работы коллектива МЦСТ в России (сильная команда разработки компилятора, опыт создания высокопроизводительных машин в советское время и проработка подхода VLIW на МВК Эльбрус-3, при невозможности иметь коллектив разработчиков аппаратуры в объёме, как у зарубежных лидеров) и оправдал себя. Результат – линейка высокопроизводительных процессоров Эльбрус 6-ти поколений, работоспособных и проверенных в ряде крупных проектов. 
Сегодня процессоры последней (6-й) версии архитектуры Эльбрус имеет все необходимые общепринятые технологии, востребованные на широком рынке: многоядерная и многопроцессорная компоновка (до 64 ядер на общей памяти), интеграция современных интерфейсов на кристалле (DDR4, PCIe 3), технологии виртуализации, энергосбережения, обеспечения надёжности RAS (уровня серверных процессоров) и т.п. Особые черты платформы Эльбрус следующие:
Производительность: – Возможность запланировать до 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 |
Безопасность информационных технологий
Bezopasnost` Informatsionnykh Tekhnologiy ISSN: 2074-7128 (Print); ISSN: 2074-7136 (On-Line)
Пользователь
Язык
Информация
Ключевые слова
атаки на мобильные телефоны
аутентификация
безопасность
безопасность мобильных технологий
биометрия
внутренний нарушитель
защита информации
идентификация
имитационное моделирование
информационная безопасность
информационная система
криптография
модель
модель угроз
облачные вычисления
персональные данные
политика информационной безопасности
распределенные вычисления
угрозы информационной безопасности
цифровая подпись
электронная подпись
Размер шрифта
