От чего горит предохранитель EFI?
Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Сейчас на странице 0 пользователей
Нет пользователей, просматривающих эту страницу.
- Уже зарегистрированы? Войти
- Регистрация
Форумы
Активность
Магазин
Важная информация
Чтобы сделать этот веб-сайт лучше, мы разместили cookies на вашем устройстве. Вы можете изменить свои настройки cookies, в противном случае мы будем считать, что вы согласны с этим.
Что такое Efi electronic fuel injection и как работает? Принцип работы и для чего нужен.
Efi electronic fuel injection это устройство, состоящее из топливных клапанов, которые управляются при помощи электронной системы. Момент открывания и закрывания клапанов определяется блоком управления двигателем. Блок электронного впрыска топлива состоит из следующих подсистем: топливная, регулятор забора воздуха, электронная система управления.
Автосервис и Технологии
Автор: Роман Беньковский
Автомобілі Mercedes-Benz навчили керувати розумним домом
Третє покоління “мультимедійки” обіцяють випустити тільки у 2025 році.
2023-09-22 13:59
В Избранное
Добавлено в Избранное Перейти
Автор: Роман Беньковский
Новий Ford Ranger отримав максимальний бал від Euro NCAP
Американський пікап отримав максимальні 5 зірок, але не обійшлось без зауважень.
2023-05-19 10:00
В Избранное
Добавлено в Избранное Перейти
Другие автотермины
- Eats electronic automatic transmission control
- Ebd electronic brake force distribution
- EBD
- ECCS
- ecm (electronic control module)
- ecm
- ecs
- ect
- ecu
- ecu (electronic control unit)
- Edc electronic diesel control
- Edc elektronische daempfer control
- edc (electronic damper control)
- edl (electronic differential lock)
- Eec electronic engine control
- Efi electronic fuel injection
- Efp electronic accelerator pedal
- EFS einzel funken spule
- Egr exhaust gas recirculation
- egr
- ehb (electro hydraulic brake)
- Ei electronic injection
- Ems engine management system
- engine block
- Eos exhaust oxygen sensor
- Esa electronic seat adjustment
- esp
- esp (electronic stability programm)
- ETACS
- etc (electronic throttle control)
- Ets electronic traction support
- Eui electronic unit injector
- euroncap
- Evb exhaust valve brake
- evp egr valve position sensor
- эбу
- экономайзер
- электронный кодовый ключ
- Электрический автомобиль
- Электродвигатель отопителя (вентилятор системы отопителя)
- Электромеханический поворотный амортизатор
- Электронное сцепление
- Электроусилитель руля
- Электромеханический парковочный тормоз (EPB)
AUTO.RIA
в вашем смартфоне Все для покупки и продажи авто в приложении AUTO.RIA
Присоединяйтесь к сообществу автолюбителей AUTO.RIA
- Безопасные сделки
- Соглашение о предоставлении услуг
- Помощь по сайту AUTO.RIA.com
- Политика приватности
- Вакансии AUTO.RIA
© 2014-2023 RIA.com
Режим «Частный доступ»
Внимание! Вы используете режим «Частный доступ» .
Отключите режим приватного доступа, чтоб воспользоваться поиском б/у авто.
Как отключить?
AUTO.RIA безопасен для вас
Мы используем cookie-файлы. Ознакомиться с Политикой использования файлов cookies
Понимаю и разрешаю Настроить
Настройки файлов cookies
Мы (ARS ONLINE OÜ) используем cookie-файлы (cookies), обязательные для работы нашего сайта и сервисов, на основании легитимного интереса. Также, мы хотели бы с вашего согласия установить на вашем устройстве опциональные аналитические cookies для запоминания данных о просмотрах и пользовании сервисами, а также маркетинговые cookies, которые помогут нам понять, какие сервисы и продукты наиболее интересуют пользователей.
Включая эти cookies, вы способствуете улучшению наших сервисов и продуктов. Детальнее о cookies читайте в нашей «Политике использования файлов cookies». Обязательные cookies мы устанавливаем в любом случае. Ниже можно позволить или не позволить нам установку опциональных cookies».
UEFI: долгожданный наследник BIOS и заклятый друг Linux
На смену старой, как компьютерный мир, системе BIOS приходит нечто совершенно новое под названием UEFI. К сожалению, помимо массы полезных новшеств, UEFI принесет с собой немало проблем. Так, не исключено, что уже в следующем году установка некоторых дистрибутивов Linux на новые компьютеры станет попросту невозможной…
⇣ Содержание
- Мягкое выдавливание конкурентов
- Другая сторона медали
Разработанная свыше тридцати лет назад для персональных компьютеров IBM PC, система BIOS (или «базовая система ввода-вывода») уже лет пятнадцать как считается реликтом древней эпохи. Жизнь, однако, распорядилась так, что подходящих альтернатив не находилось очень долго. Лишь теперь сложились подходящие обстоятельства и, соответственно, пошли разговоры, что BIOS наконец-то начинает сдавать свои доминирующие позиции.
На ее место приходит система UEFI, комплекс спецификаций, появившийся как «загрузочная инициатива Интел» (Intel Boot Initiative) в далеком уже 1998 году. Причиной рождения инициативы послужило то, что ограничения, обусловленные BIOS, стали ощутимо тормозить прогресс вычислительных систем на основе новейших в ту пору интеловских процессоров Itanium. Несколько позже эта же инициатива стала называться EFI, а в 2005 году корпорация подарила свою разработку специально созданному под нее консорциуму UEFI Forum, главными членами которого стали — помимо Intel — такие зубры IT-индустрии, как AMD, Apple, IBM, Microsoft и ряд других.
Логотип UEFI уже сейчас можно встретить на упаковке материнских плат
Не самая благозвучная аббревиатура UEFI расшифровывается как Unified Extensible Firmware Interface и представляет собой весьма радикальное преобразование традиционной для компьютеров процедуры загрузки. Точнее, перемены настолько глубоки, что UEFI не имеет с системой PC BIOS практически ничего общего.
В то время как BIOS по сути своей является весьма жестким и фактически неизменным по содержанию кодом прошивки специального BIOS-чипа, система UEFI — скорее гибко программируемый интерфейс. А расположен этот интерфейс поверх всех аппаратных компонентов компьютера с их собственными прошивками-микрокодами. В отличие от загрузочного кода BIOS, который всегда жестко прошит в соответствующем чипе на системной плате, куда более обширные по размеру коды UEFI находятся в специальной директории /EFI/, место физического расположения которой может быть самым разнообразным — от микросхемы памяти на плате или раздела на жестком диске компьютера и до внешнего сетевого хранилища.
В результате столь гибкого подхода система UEFI становится чем-то вроде сильно облегченной, но вполне самостоятельной операционной системы. То есть, по сути дела, в компьютере сначала загружается система UEFI, под ее управлением выполняется произвольный набор нужных действий, а затем уже запускается загрузка собственно операционной системы (из этого, кстати, совершенно не следует, что процесс загрузки становится более длительным. Скорее даже наоборот, заранее гибко настроенная конфигурация системы способна грузиться ощутимо быстрее).
UEFI, что и говорить, по сравнению с классическими BIOS выглядит гораздо красивее и понятнее для нормальных людей
Еще более усиливая сходство с ОС, спецификации UEFI включают в себя не только загрузочные, тестовые и рабочие сервисы, но также протоколы коммуникаций, драйверы устройств (UEFI изначально разрабатывалась для работы вне зависимости от операционных систем), функциональные расширения и даже собственную EFI-оболочку, из-под которой можно запускать собственные EFI-приложения. А уже поверх всего этого хозяйства расположен собственно загрузчик, отвечающий за запуск на компьютере основной операционной системы (или нескольких систем).
Хотя UEFI иногда называют псевдо-ОС, она, тем не менее, способна сама получать доступ ко всему аппаратному обеспечению компьютера. То есть уже на уровне UEFI вполне возможно, к примеру, выходить в Интернет или организовывать резервное копирование жестких дисков, причем делать это все в условиях полноценного графического интерфейса под привычным мышиным управлением.
Тот факт, что все эти расширенные загрузочные данные хранятся во вместительной флеш-памяти или на жестком диске, попутно означает, что там же имеется намного больше пространства для таких вещей, как языковая локализация системы, развитая система диагностики на этапе загрузки, полезные утилиты (типа архивации, восстановления после сбоя, сканирования на вирусное заражение) и так далее.
Полностью построенная на основе программного кода, UEFI действительно стала объединенной кросс-платформенной системой. Уже сегодня спецификации UEFI предусмотрены в работе почти любой комбинации чипов с 32- и 64-битной архитектурой, выпускаемых AMD, Intel и многочисленными лицензиатами ARM. Единственное, что требуется для обеспечения этой универсальности, это скомпилировать исходный код под требования каждой конкретной платформы.
UEFI уже сейчас вовсю используется в топовых материнских платах крупных производителей, а к концу следующего года найти свежую модель с «просто BIOS» станет практически невозможно
Помимо внушительного множества расширяемых возможностей, реализуемых благодаря гибкому и продвинутому интерфейсу, система UEFI также определяет несколько стандартных особенностей, которые должны быть реализованы в работающем под ней компьютере. В частности, среди таких стандартно обеспечиваемых возможностей упоминаются «безопасная загрузка» (secure boot, о чем в подробностях далее), низкоуровневая криптография, сетевая аутентификация, универсальные графические драйверы и еще немало чего другого.
В принципе, в каждой из основных на сегодня операционных систем (Windows, OS X, Linux) уже имеется поддержка загрузки через UEFI. Но следует также отметить, что пока UEFI все еще является очень молодой системой и реально очень немногие ОС пользуются всеми ее преимуществами, перечисленными выше.
Linux определенно поддерживает UEFI, однако это скорее поверхностное знакомство, чем эффективное партнерство. Система Mac OS X продвинулась несколько дальше и отчасти использует UEFI со своим загрузочным менеджером Bootcamp. В линейке Microsoft реальная поддержка UEFI появится в Windows 8, и когда она будет запущена в 2012 году, эта операционная система, вероятно, станет первой из «главных» ОС, где будут весьма интенсивно задействованы преимущества UEFI, включая функции восстановления, обновления, безопасной загрузки и, вполне возможно, что-то еще.
Случилось так, что именно этот первый, действительно крупномасштабный проект Microsoft на основе UEFI породил и первую заметную проблему вокруг новой системы.
⇡#Мягкое выдавливание конкурентов
В сентябре компьютерное сообщество взбудоражила новость о том, что корпорация Microsoft станет требовать поддержки безопасной загрузки UEFI от систем, официально сертифицированных под Windows 8. Вроде бы ничего страшного, но такой подход может с очень большой вероятностью привести к полному блокированию загрузки ОС Linux на Windows-сертифицированных системах.
Кое-где угроза была воспринята настолько серьезно, что, например, в Австралии Linux-сообщество тут же запустило процедуру подачи официальной жалобы в ACCC, Австралийскую комиссию по честной конкуренции и правам потребителей.
Однако, как говорят сведущие в технических и юридических тонкостях специалисты, именно из этого разбирательства Microsoft практически наверняка сумеет выбраться без всяких проблем. Просто потому, что в описании процесса безопасной загрузки UEFI или, точнее, в словах о необходимости такого процесса корпорацией не упоминаются иные операционные системы. Суть проблемы, с которой сражается Microsoft (очень тщательно и аккуратно подбирая выражения), — это борьба с вредоносными кодами, а безопасная загрузка тем и хороша для работы Windows, что такой процесс перекрывает еще один опасный канал для проникновения вредоносных программ.
Есть ощущение, что с выходом Windows 8 увидеть на экране какой-то другой интерфейс станет посложнее. По крайней мере, для людей, не умеющих собирать компьютеры самостоятельно
Иначе говоря, в процессе обсуждения столь сложной и разветвленной системы, как UEFI, среди спорящих неизбежно возникает путаница относительно того, почему переход на более современную и, кажется, полезную технологию вызывает столь неоднозначную реакцию. Что же, давайте разберемся.
Начиналось все так. В конце сентября один из ведущих разработчиков дистрибутива Red Hat Мэтью Гаррет (Matthew Garrett) в своем блоге отметил, что, согласно новым правилам относительно присвоения машинам логотипа «Windows 8», все компьютеры, совместимые с этой ОС, должны будут иметь для загрузки уровень UEFI вместо устаревшего уровня BIOS.
Причем речь шла не просто о любом уровне спецификаций UEFI (реализованных в разных версиях достаточно давно), а конкретно о безопасном UEFI. Что означает более жесткий контроль за процессом загрузки системы. Конкретнее, это ужесточение означает то, что «все микрокоды прошивки и программное обеспечение, участвующее в процессе загрузки, должны быть криптографически подписаны доверяемым органом сертификации (CA)» — согласно слайдам презентации о загрузочном процессе UEFI в одном из официальных докладов Ари ван дер Ховена (Arie van der Hoeven), главного менеджера программ Microsoft (здесь, наверное, стоит привести и английскую версию названия этой почти непереводимой должности, Principal Program Manager Lead. — прим. редакции).
Именно этот момент — безопасная загрузка — ставит Linux в довольно непростую ситуацию. Потому что он означает, что теперь для «загружаемости» на одной из всех таких «Windows 8»-одобренных машин соответствующий дистрибутив Linux должен иметь сертифицированные криптоключи от конкретного изготовителя компьютера. С чисто технической точки зрения, как пояснил Гаррет в одном из следующих блог-постов, это означает, что на получение такого рода ключей разработчикам любого Linux-дистрибутива потребуется убить порядка недели на переговоры-соглашения с каждым из производителей железа индивидуально.
Судя по всему, коварство Microsoft всерьез потрясло Мэтью Гаррета, так что на всех новых фотографиях он выглядит одинаково удивленным
Ну, к словесным баталиям деятелям мира Linux не привыкать. Однако процедура оказывается чрезвычайно запутанной и трудозатратной — даже для линуксоида со стажем — сразу в двух аспектах: юридическом и практическом.
Во-первых, юридическая сторона. По свидетельству Гаррета, самый распространенный линуксовский загрузчик GRUB 2 лицензирован на условиях лицензии GPLv3. Это вроде бы может означать, что ключи должны быть предоставлены поставщиком вместе с исходным кодом программы. Однако в действительности это весьма мутный момент. Лицензия GPLv3 требует, чтобы ключи цифровой подписи выпускались, когда аппаратное обеспечение продается вместе с ПО, созданным под GPLv3 (и криптографически подписанным). Но если это же подписанное ПО просто используется на чьем-то еще аппаратном обеспечении, тогда ключи не требуются. И хотя уже это выглядит запутанно, ситуация еще более сложна, когда речь идет о GPLv2, лицензии для первоначального загрузчика GRUB (существенно отличающейся в своих требованиях от GPLv3). Для того чтобы полностью избавиться от всех этих юридических неясностей, Гаррет рекомендует просто использовать иной загрузчик, не связанный условиями лицензии GPL.
Вот только гарретовский рецепт, как бы сомнительно он ни выглядел, в реальности может оказаться еще опаснее. Процедура загрузки ОС — это один из сервисов, которые уже встроены в ядро Linux. А ядро этой ОС является кодом, работа с которым определяется лицензией GPLv2, причем ситуацию эту даже не собираются менять — из неких принципиальных соображений и несогласия с GPLv3.
Благодаря заботе Microsoft, многие дистрибутивы Linux могут окончательно утратить имидж user-friendly
И наконец, есть еще один — практический — аспект, о котором упоминает Гаррет. Кто именно будет заниматься тем, чтобы отслеживать и убеждать всех OEM-изготовителей компьютеров, чтобы они предоставляли соответствующие криптоключи, необходимые для безопасной загрузки Linux? Конечно же, многие компании предоставят такие ключи для Windows 8 — коль скоро они хотят иметь возможность продавать свои машины на новой операционной системе Microsoft. Однако в природе не существует никаких правил, которые диктовали бы им, что они обязаны предоставлять такие же ключи кому-то еще. И, учитывая долю рынка Linux, убедить их может оказаться делом непростым…
Между тем ни о какой нечестной конкуренции речи-то не идет. Официальные лица Microsoft уже вполне резонно парировали нападки линуксоидов тем, что с их стороны речь идет исключительно об укреплении безопасности в работе ОС Windows. И они никоим образом не пытаются влиять на то, как именно изготовители аппаратного обеспечения распоряжаются своими криптоключами. Microsoft никак не препятствует выдачам таких же ключей другим операционным системам. А если у индейцев возникают проблемы с третьей стороной, причем тут шериф?
Если пытаться судить объективно, позицию Microsoft здесь никак нельзя называть неправой. Просто реальная ситуация на рынке такова, что небольшого смещения акцентов под здравые, в общем, требования Microsoft оказалось достаточно, чтобы вся ответственность перенеслась на действия (точнее, вероятное бездействие) OEM-изготовителей.
Linux уверенно побеждает Windows только в творчестве фанатов. Если бы кому-то пришло в голову нарисовать истинное положение дел, картинка выглядела бы слишком шокирующе даже для нашего либерального портала
В финальных комментариях на данный счет Мэтью Гаррет говорит следующее: «Microsoft имеет возможности потребовать от поставщиков железа предоставления своих ключей. Их конкуренты таких возможностей не имеют. Всякая система, которая продается с ключами подписи только для Microsoft и никого другого, будет не способна выполнять безопасную загрузку любой операционной системы, отличающейся от Windows. Ни один другой поставщик ПО или аппаратного обеспечения не имеет такой же позиции власти над поставщиками железа. У Red Hat нет возможностей гарантировать, что каждый OEM обеспечит для этой ОС ключи подписи. Нет такой возможности у Canonical (ОС Ubuntu). Нет у Nvidia, или у AMD, или любого другого изготовителя компьютерных компонентов. В этой области влиятельность Microsoft даже больше, чем у корпорации Intel».
На рынке серверов ситуация с Linux будет совершенно не такой, как в продажах настольных систем. В серверном пространстве такие поставщики, как IBM, HP, и Dell, уже инвестировали слишком много и в Linux-системы вообще, и в облачные или виртуальные системы в частности, чтобы у Linux не появлялось никаких проблем с установкой на новых машинах.
Однако в мире настольных систем, где ныне почти никто из OEM не продает компьютеры с предустановленной Linux, совершенно неясно, какие стимулы могут быть у изготовителей железа для раздачи своих криптоключей всем этим разнообразным дистрибутивам Linux. Единственное, что можно прогнозировать наверняка, — Microsoft «разруливанием» данной проблемы заниматься не будет точно.
⇡#Другая сторона медали
Среди проблем, уже обозначившихся вокруг UEFI, есть одна особенная, очень важная для всех операционных платформ без исключения. Касается она защиты информации, а потому речь об этом удобно начать с мнения спецслужб и работающих на них специалистов.
В конце сентября в американском городе Орландо, штат Флорида, проходила специализированная выставка-конференция под названием NSA Trusted Computing, организованная Агентством национальной безопасности США.
Главный комплекс зданий Агентства национальной безопасности США. По всем признакам, людей там хватает
На этом мероприятии доклад об угрозах компьютерам со стороны BIOS и о путях укрепления защиты на этом направлении сделал Эндрю Регеншайд (Andrew Regenscheid), сотрудник подразделения компьютерной безопасности в составе NIST, американского Национального института стандартов и технологий. Именно это ведомство в тесном сотрудничестве с АНБ занимается подготовкой и изданием технических федеральных стандартов на защиту информации.
В апреле текущего года НИСТ выпустил специальный документ SP 800-47 с рекомендациями о том, каким образом производители компьютеров и использующие их структуры должны работать с BIOS для максимального предотвращения заражений и атак. Одним из главных соавторов данного документа и был Эндрю Регеншайд.
По свидетельству этого эксперта, несмотря на весьма ограниченную роль BIOS в современных компьютерах (где, как принято полагать, функции устаревшей системы сводятся лишь к загрузке ОС), реально BIOS на сегодняшний день представляет собой «нарастающий вектор угроз» для компьютеров и их пользователей. Ощутимый прогресс в защите операционных систем заставил злоумышленников изобретательно искать в компьютерах новые уязвимости. При этом специалисты, занимающиеся безопасностью, о BIOS долгое время забывали. А в совокупности все это стало означать, что креативные злодеи с заметным успехом ныне могут эксплуатировать уязвимости и в кодах прошивки микросхем.
Случаи атак через BIOS уже есть. Так, в начале сентября китайская антивирусная фирма обнаружила в компьютерах весьма опасный руткит, получивший название Mebromi, который успешно заражает своим шпионским компонентом память BIOS-чипов AWARD. Проникнув в BIOS и попутно подменяя MBR, главную загрузочную запись жесткого диска, эта вредоносная программа прописывается в машине так основательно, что удалить ее стандартными средствами не представляется возможным. Просто потому что антивирусные программы не занимаются лечением BIOS.
Как сказал об этом Регеншайд, «если злоумышленник способен проникать в BIOS и модифицировать его код, он получает возможности не только «убить» систему, не допуская ее загрузки, но и внедрить свое шпионское ПО на чрезвычайно высоких по привилегиям уровнях работы системы».
И вот теперь, существенно усложняя общий «ландшафт угроз» для компьютерной безопасности в аспектах BIOS, на сцене появляется UEFI BIOS. То есть следующее поколение системы, в своих спецификациях добавляющее множество новых возможностей как для администраторов и конечных пользователей, так и для злоумышленников.
Совершенно очевидно, что, в отличие от традиционных BIOS, система UEFI способна на много, много большее, чем просто процесс загрузки. Эндрю Регеншайд, в частности, в своем докладе особо подчеркнул набор рабочих сервисов, которые можно вызывать даже в таких условиях, когда основная ОС уже давно загружена и, как принято обычно считать, полностью управляет компьютером. Эта специфическая особенность, а также другие свойства UEFI BIOS, по свидетельству Регеншайда, очень ощутимо расширяют пространство возможных атак на систему.
В дополнение к этому, сказал докладчик, стандарт UEFI BIOS намного более подробно документирован, нежели предыдущие спецификации BIOS. Это, да в сочетании с тем, что систему UEFI понадобится обновлять через сеть куда более часто, чем BIOS, открывает широкий простор для создания и внедрения самых разнообразных вредительских и шпионских закладок.
Странная история получается, правда? С одной стороны, во имя безопасности происходит изменение правил игры, существенно осложняющее жизнь «маленьким» участникам. А с другой — уже сейчас, на старте, есть существенные сомнения в том, что этой самой безопасности всерьез прибавится.
Зато никому долго не будет скучно.
Слегка ржавое EFI-приложение
После двух твитов, оставленных на прошлой неделе, про мои игры с UEFI и Rust, несколько человек попросили опубликовать заметку, объясняющую как создать UEFI-приложение, полностью написанное на Расте и продемонстрировать тестовое окружение.
Так что сегодняшняя цель — это создание UEFI-приложения на Расте, которое распечатывает карту памяти, отфильтрованную по доступности для использования (такая память называется традиционной памятью в описании UEFI-спецификаций):
Однако прежде, чем приступить к работе, освежим некоторые понятия.
▍ Скомканное вступление
При включении компьютера аппаратная часть находится в неопределённом состоянии и необходимо выполнить некоторую инициализацию для того, чтобы подготовить систему к предстоящей работе. BIOS, акроним для Basic Input/Output System, появившийся в районе 1975 года и использовавшийся с тех пор, был способом проведения аппаратной инициализации во время процесса загрузки и предоставления сервисов времени выполнения для ОС и программ. Однако BIOS имеет некоторые ограничения и после 40 лет применения заменён на Unified Extensible Firmware Interface (или UEFI для краткости). UEFI нацелен на устранение технических недостатков BIOS.
UEFI — это спецификация, которая определяет программный интерфейс между ОС\UEFI-приложением и прошивкой платформы. Intel разработала изначальную Extensible Firmware Interface (EFI), работы над которой были закончены в июле 2005 года. В начале 2006 года Apple одной из первых внедрила технологию на своих Intel Macintosh. В том же самом 2005 году выход UEFI сделал устаревшим EFI 1.10 — последний выпуск EFI. UEFI форум — это индустриальный орган, который управляет UEFI-спецификациями. Интерфейс, определяемый этими спецификациями, включает таблицы данных, которые содержат информацию о платформе, сервисы времени загрузки и выполнения, которые доступны приложению\загрузчику ОС. Такая прошивка имеет ряд преимуществ перед традиционным BIOS:
- возможность использования более вместительных накопителей при помощи GUID Partition table (GPT)
- независимая от CPU архитектура
- независимые от CPU драйверы
- гибкое пре-ОС окружение, включая сетевые возможности
- модульная архитектура
- совместимость назад и вперёд
▍ Окисление — это хорошо
Как говорилось в начале, Раст будет использован для написания UEFI-приложения. Для тех, кто не знает, что это такое: Раст — системный язык программирования, разработку которого спонсирует Mozilla. Она описывает его как «безопасный, конкурентный, практичный язык», поддерживающий функциональную и императивно-процедурную парадигмы. Язык очень похож на Си++ в плане синтаксиса, но создатели Раста намереваются обеспечить в нём лучшую безопасность по памяти при сохранении производительности.
ЯП явился результатом персонального проекта сотрудника Mozilla Грейдона Хоара. Организация стала поддерживать проект в 2009 году, после осознания его потенциала. В 2010 году было публично объявлено о проекте; в том же самом году компилятор, изначально разработанный на OCaml, начали переписывать на Расте с использованием LLVM-backend.
Первая пре-альфа версия компилятора появилась в январе 2012 года, но уже через 3 года, 15 мая 2015 была выпущена первая стабильная версия (теперь известная как редакция 2015). Раст является проектом с открытым сообществом. Такая модель означает, что любой может вкладываться в разработку и в уточнение языка, и этот вклад может быть разным, например, улучшение документации, отправка баг-репортов, предложения RFC на добавление функциональности или изменения программного кода. Язык получил огромную обратную связь по опыту разработки Серво — современного движка для обозревателей с превосходной производительностью и возможностью встроенного применения. В наши дни Раст начинает присутствовать во всех сферах ПО, к примеру, в ПО для управления спутниками, программировании микроконтроллеров, веб-серверов, в обозревателе Firefox и т.д. Раст выигрывал первое место в номинации «наиболее любимый язык программирования» в опросе Stack Overflow Developer в 2016, 2017 и 2018 годах (прим. переводчика — и в 2021).
▍ Ещё два или три момента перед началом
Для того чтобы написать загрузчик, гипервизор или низкоуровневое приложение требуется использовать системный язык программирования. Есть отличная статья с подробным обсуждением этого понятия. Проще говоря, системный ЯП — это язык, позволяющий тонкий контроль над исполнением кода в машине и возможностью изменения любых отдельных байтов в памяти компьютера. И с Растом это возможно.
Во избежание необходимости описывать все UEFI-таблицы будет использован крейт uefi-rs . Этот крейт облегчает создание UEFI-приложений на Расте. Миссия uefi-rs в том, чтобы предоставить безопасные и производительные обёртки вокруг UEFI-интерфейсов и позволить разработчикам писать идиоматичный Раст-код.
Наконец, для тестового окружения будут использованы Питон и QEMU вкупе с OVMF. QEMU — это хорошо известный полносистемный эмулятор, позволяющий запускать код для любой машины на любой поддерживаемой архитектуре. OVMF — это основанный на EDK II проект, предоставляющий поддержку UEFI для виртуальных машин (QEMU и KVM). QEMU не содержит в поставке OVMF, так что придётся установить его отдельно на вашу машину, либо взять предсобранные образы из Сети.
Например, такие доступны для загрузки в моём тестовом хранилище.
▍ Начинаем
Без дальнейших промедлений приступаем к работе! Первым делом создадим папку и инициализируем Раст проект в ней:
> mkdir uefi-app && cd uefi-app > cargo initТеперь добавим uefi-rs в качестве зависимости. Чтобы сделать это, просто добавьте следующие строки в ваш Cargo.toml:
uefi = "0.12.0" uefi-services = "0.9.0"Если сейчас запустить cargo run , то Карго соберёт uefi-rs вместе с нашим приложением.
▍ Рабочий процесс сборки\запуска
Следующий шаг состоит в создании файла целевых параметров и сценария на Питоне для облегчения сборки и запуска UEFI-приложения. В основном, параметры цели описывают выходной двоичный файл, порядок байтов («endianess»), архитектуру, двоичную структуру и функциональности, которые можно использовать при компиляции. Этот файл будет использован build-std , функциональность Карго для производства крейта core (это основная часть стандартной библиотеки Раста, но без зависимостей, даже от системных библиотек и libc), собранного для другой платформы.
Таким образом, сперва нам необходимо «сказать» карго, чтобы он включил build-std , через создание файла .cargo/config:
[unstable] build-std = ["core", "compiler_builtins", "alloc"]Замечание: чтобы это работало нужно установить ночную сборку Раста так же как и компонент rust-src . Это можно сделать при помощи rustup: rustup component add rust-src —toolchain nightly .
Функциональность mem из compiler-builtins не включается автоматически во время сборки с использованием Cargo-функциональности build-std . Таким образом, мы должны вручную добавить поддержку функций по работе с памятью прописав следующее в файл Cargo.toml:
rlibc = "1.0.0"И затем добавим крейт в качестве зависимости, чтобы mem* функции были связаны:
extern crate rlibc;Далее создадим файл x86_64-none-efi.json со следующим содержимым:
< "llvm-target": "x86_64-pc-windows-gnu", "env": "gnu", "target-family": "windows", "target-endian": "little", "target-pointer-width": "64", "target-c-int-width": "32", "os": "uefi", "arch": "x86_64", "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", "linker": "rust-lld", "linker-flavor": "lld-link", "pre-link-args": < "lld-link": [ "/Subsystem:EFI_Application", "/Entry:uefi_start" ] >, "panic-strategy": "abort", "default-hidden-visibility": true, "executables": true, "position-independent-executables": true, "exe-suffix": ".efi", "is-like-windows": true, "emit-debug-gdb-scripts": false >прим. переводчика
По правде говоря, на текущий момент уже нет необходимости в создании такого файла. Поддержку uefi влили — PR/56769.
Я решил всё же переводить статью в оригинальном виде.
Вообще, сейчас полезно сразу читать uefi-rs/BUILDING.md.
Также добавлю ещё одну хорошую, на мой взгляд, ссылку — blog.timhutt/std-embedded-rust. Благодаря ей сформировалась команда сборки — cargo +nightly build -Z build-std=std,panic_abort —target x86_64-unknown-uefi .
Исполняемый UEFI-файл не что иное, как двоичный формат PE, используемый Windows, но со специальной подсистемой и без таблицы символов; поэтому целевое семейство установлено как windows.
Сейчас нужно создать build.py, реализующий две команды:
- build : эта команда собирает UEFI-приложение
- run : запускает собранное приложение в QEMU.
#!/usr/bin/env python3 import argparse import os import shutil import sys import subprocess as sp from pathlib import Path ARCH = "x86_64" TARGET = ARCH + "-none-efi" CONFIG = "debug" QEMU = "qemu-system-" + ARCH WORKSPACE_DIR = Path(__file__).resolve().parents[0] BUILD_DIR = WORKSPACE_DIR / "build" CARGO_BUILD_DIR = WORKSPACE_DIR / "target" / TARGET / CONFIG OVMF_FW = WORKSPACE_DIR / "OVMF_CODE.fd" OVMF_VARS = WORKSPACE_DIR / "OVMF_VARS-1024x768.fd" def run_build(*flags): "Run Cargo- with the given arguments" cmd = ["cargo", "build", "--target", TARGET, *flags] sp.run(cmd).check_returncode() def build_command(): "Builds UEFI application" run_build("--package", "uefi-app") # Create build folder boot_dir = BUILD_DIR / "EFI" / "BOOT" boot_dir.mkdir(parents=True, exist_ok=True) # Copy the build EFI application to the build directory built_file = CARGO_BUILD_DIR / "uefi-app.efi" output_file = boot_dir / "BootX64.efi" shutil.copy2(built_file, output_file) # Write a startup script to make UEFI Shell load into # the application automatically startup_file = open(BUILD_DIR / "startup.nsh", "w") startup_file.write("\EFI\BOOT\BOOTX64.EFI") startup_file.close() def run_command(): "Run the application in QEMU" qemu_flags = [ # Disable default devices # QEMU by default enables a ton of devices which slow down boot. "-nodefaults", # Use a standard VGA for graphics "-vga", "std", # Use a modern machine, with acceleration if possible. "-machine", "q35,accel=kvm:tcg", # Allocate some memory "-m", "128M", # Set up OVMF "-drive", f"if=pflash,format=raw,readonly,file=", "-drive", f"if=pflash,format=raw,file=", # Mount a local directory as a FAT partition "-drive", f"format=raw,file=fat:rw:", # Enable serial # # Connect the serial port to the host. OVMF is kind enough to connect # the UEFI stdout and stdin to that port too. "-serial", "stdio", # Setup monitor "-monitor", "vc:1024x768", ] sp.run([QEMU] + qemu_flags).check_returncode() def main(args): "Runs the user-requested actions" # Clear any Rust flags which might affect the build. os.environ["RUSTFLAGS"] = "" os.environ["RUST_TARGET_PATH"] = str(WORKSPACE_DIR) usage = "%(prog)s verb [options]" desc = "Build script for the UEFI App" parser = argparse.ArgumentParser(usage=usage, description=desc) subparsers = parser.add_subparsers(dest="verb") build_parser = subparsers.add_parser("build") run_parser = subparsers.add_parser("run") opts = parser.parse_args() if opts.verb == "build": build_command() elif opts.verb == "run": run_command() else: print(f"Unknown verb ''") if __name__ == '__main__': sys.exit(main(sys.argv))Заметка: я не нашёл, по какой причине исполняемый файл не загружается автоматически с этой версией OVMF, поэтому используется сценарий startup.nsh для облегчения загрузки.
▍ Само приложение
Первым шагом нужно заставить грузиться приложение и войти в бесконечный цикл, предупреждая выход в прошивку.
В Расте ошибки могут быть доведены до паники или аварийного прекращения. Паника случается, когда что-то идёт не так, но в целом можно продолжить работу (такое обычно случается с потоками); аварийное завершение происходит, когда программа переходит в состояние, из которого невозможно восстановление. Наличие обработчика паники обязательно, он реализуется в стандартной библиотеке; но поскольку приложение не зависит от ОС, то и стд не может быть использована. Вместо этого мы используем core часть библиотеки, в которой обработчик отсутствует, так что мы вынуждены реализовывать его самостоятельно. К счастью, uefi-rs предоставляет одну реализацию оного.
Если вы подметили, то в файле целевых параметров указана передача пары аргументов lld (компоновщик LLVM), указывающие точку входа ( uefi_start ) и подсистему. Так, нам нужно отредактировать main.rs, чтобы импортировать uefi-rs крейт и определить функцию с именем uefi_start , содержащую бесконечный цикл:
#![no_std] #![no_main] #![feature(asm)] #![feature(abi_efiapi)] extern crate uefi; extern crate uefi_services; use uefi::prelude::*; #[entry] fn efi_main(_image_handler: uefi::Handle, system_table: SystemTable) -> Status < loop <>Status::SUCCESS >Первые две строки обозначают, что наш крейт не имеет функции main и не зависит от стд. Также точка входа помечена аттрибутом entry.
Наконец, после сборки и запуска приложения, QEMU отобразит что-то похожее на картину ниже:
QEMU исполняет UEFI-приложение
Ничего интересного, но т.к. QEMU не перешла в цикл загрузки или выскочила в EFI-оболочку, убеждаемся, что наше приложение вызвано. Следующий шаг заключается в том, чтобы напечатать версию UEFI на экран. Опять же, в rust-rs уже реализованы вспомогательные функции для этого, поэтому достаточно проинициализировать систему логгирования и использовать макрос info! для распечатки текста на экране или даже на последовательном порту.
Для доступа к макросу info! нужно добавить новую зависимость в Cargo.toml:
Затем необходимо просто добавить следующий код в главную функцию, перед входом в бесконечный цикл:
uefi_services::init(&system_table).expect_success("Failed to initialize utils"); // reset console before doing anything else system_table .stdout() .reset(false) .expect_success("Failed to reset output buffer"); // Print out UEFI revision number < let rev = system_table.uefi_revision(); let (major, minor) = (rev.major(), rev.minor()); info!("UEFI <>.<>", major, minor); >После сборки и запуска приложение выведет что-то вроде INFO: UEFI 2.70. Эта информация зависит от версии прошивки, которую вы используете.
прим. переводчика
Вот так запуск выглядит на моём стареньком Самсунг NP535U4C:
В завершение давайте напишем функцию, которая принимает ссылку на таблицу Boot Services и распечатывает регионы свободной для использования памяти. Сперва нам потребуется включить крейт alloc, чтобы получить доступ к структуре Vec; для этого нужно добавить следующие три строки в начало файла:
#![feature(alloc)] // (. ) extern crate alloc; // (. ) use crate::alloc::vec::Vec;После этого определим константу с размером EFI-страницы, который равен 4KiB независимо от системы.
const EFI_PAGE_SIZE: u64 = 0x1000;И, собственно, реализуем непосредственно функцию по обходу карты в поисках традиционной памяти и распечатке свободных диапазонов на экран:
fn memory_map(bt: &BootServices) < // Get the estimated map size let map_size = bt.memory_map_size(); // Build a buffer bigger enough to handle the memory map let mut buffer = Vec::with_capacity(map_size); unsafe < buffer.set_len(map_size); >let (_k, desc_iter) = bt .memory_map(&mut buffer) .expect_success("Failed to retrieve UEFI memory map"); let descriptors = desc_iter.copied().collect::>(); assert!(!descriptors.is_empty(), "Memory map is empty"); // Print out a list of all the usable memory we see in the memory map. // Don't print out everything, the memory map is probably pretty big // (e.g. OVMF under QEMU returns a map with nearly 50 entries here). info!("efi: usable memory ranges (<> total)", descriptors.len()); descriptors .iter() .for_each(|descriptor| match descriptor.ty < MemoryType::CONVENTIONAL => < let size = descriptor.page_count * EFI_PAGE_SIZE; let end_address = descriptor.phys_start + size; info!( "> - (<> KiB)", descriptor.phys_start, end_address, size ); > _ => <> >) > // (. ) // Call this function inside main memory_map(&system_table.boot_services());Конечный результат должен совпадать с выводом, изображённым на КДПВ.
И готово! было несложно, правда? Теперь вы можете продолжить реализовывать новые возможности в приложении, вероятно решившись разрабатывать загрузчик или более сложное UEFI приложение.
И ещё одна важная ремарка для отважных духом. Если вы пустились в разработку своей собственной ОС или углубились в изучение технологии, то вы должны отложить в сторону все API, предоставляемые UEFI для взаимодействия с файловой системой, сетью, доступом к PCI-устройствам и т.д., и разработать свои собственные драйвера.
Не ленитесь от использования всех этих предоставленных абстракций!
- Блог компании RUVDS.com
- Системное программирование
- Rust
- UEFI