Файл с UEFI Shell нужно положить либо на EFI System Partition, либо на внешний носитель с ФС FAT32 и назвать либо shell.efi, либо shell64.efi, либо чаще всего shellx64.efi, после чего подключить носитель и выбрать эту опцию. На всех платах, которые у меня есть — работает, но не все версии UEFI Shell запускаются, приходится скачивать и пробовать разные.
Во второй части я расскажу о процессе загрузки UEFI. Сейчас RAM инициализируется в конце второй фазы загрузки, а вся работа до этого происходит в кэше процеессора. А вообще, процесс начальной загрузки изменился не сильно, но переход в защищенный режим происходит теперь гораздо раньше.
Не думаю, что хаб UEFI будет чисто академическим, с учетом идущих вокруг SecureBoot холиваров.
На самом деле, эта статья — не чистое знание, а чистое «чуть чуть прошелся по верхам, и оборвал на самом интересном месте».
Тема UEFI очень обширная, тут и процесс загрузки, и разнообразие форматов исполняемых файлов, и схожесть структур данных в UEFI и Windows, и EDK, и UEFI Shell, и сборка своих исполняемых файлов для UEFI, и написание DXE-драйверов, и NVRAM, и SMM, и безопасность, и виды защит от прошивки, и это половина процента всего, что можно написать про UEFI, и что не будет выглядеть так скучно, как эта статья.
Если интересно — можно продолжать, если не сильно — можно написать пост со списком того, что стоило бы почитать на эту тему и остановиться на этом.
SecureBoot нужен только потому, что без него там вообще никакой безопасности нет. UEFI — это самая настоящая OS, работающая в ring 0, а частями и ниже, и имеющая собственные драйверы, собственный сетевой стек и доступ до всей памяти и всех устройств в обход основной ОС.
Без какой-либо защиты, в том виде, в котором оно реализовано на платах на P67/Z68 — это кошмар любого безопасника.
Любой получивший один раз рута код может сделать с БИОСом что угодно.
И не просто стереть его, а записать своих модулей, которые, при грамотном программировании, даже обновление БИОСа стандартными средствами будут переживать.
И все это вот нам подается под соусом «ускоряем загрузку на 10 секунд, пишем БИОС на С, в настройках высокое разрешение и мышь!» Поэтому SecureBoot — все-таки хоть какой-то, но выход из сложившейся ситуации.
ИМХО, лучшая реализация «двойного» БИОСа сейчас у EVGA на новых платах.
Там три разных микросхемы, одна из которых не припаяна, а посажена в ZIF-кроватку.
Никаких хитрых механизмов нет и не нужно, сломалось — щелкнул тумблером, загрузился, щелкнул обратно, прошил новую версию.
И всякие проприентарные прошивальщики они не используют, доверяя прошивку надежному и простому Intel FPT.
И Phoenix, и InsydeH2O, которые как раз и используюся Dell, HP и Lenovo — нисколько не менее глючные. Про новые Dell с UEFI 2.3.1C и SecureBoot сказать ничего пока не могу — не сталкивался, а вот на старых багов не меньше, если не больше, чем на десктопных AMI, и чинят их также крайне неохотно. Но хотя бы белых списков оборудования Dell не вводит и файлы BIOS Update не шифрует, как это делают HP и Lenovo.
Только за одни белые списки, из за которых каждую новую версию БИОСа приходится модифицировать и шить нестандартными способами, я больше никогда решения ни HP ни Lenovo не куплю, пусть там UEFI хоть каким отличным будет. Оборудование и так делают все более закрытым, а чтобы какой-то кореец решал, какие 3G-модем и WiFi-карту я могу поставить в свой ноутбук, а какие нет — увольте.
С учетом включенных на этом ноутбуке по умолчанию Intel AT и защиты от записи сторонними утилитами прошить такой модифицированный БИОС может быть очень непросто.
Поэтому нужно писать в техническую поддержку и требовать возврата опции в список доступных для редактирования. Если быть достаточно настойчивым — вернут.
Посмотрел в доступные настройки BIOS'а N76VZAS.213 на предмет отключения SecureBoot с помощью AMIBCP.
Возможность эта в прошивке есть и должна быть на вкладке Security.
Отображается эта настройка или нет — другой вопрос, конечно.
Не знаю, откуда в русской версии презентации эти слова про диск, в английской их нет. Да и микросхем там все же две, а восстановление работает без жестких дисков, так что вопросы тут к переводчику, скорее.
Нет, это про другое. На платах Gigabyte установлено 2 микросхемы SPI flash и при невозможности старта с основной происходит старт с дополнительной, копирование содержимого дополнительной в основную и старт с основной. Таким образом, пользователю после сбоя достаточно подождать 2 минуты, пока выполняется копирование, и потом выставить свои настройки заново.
Вообще, идея установки на плату нескольких микросхем SPI flash — очень хорошая, жаль, что не все производители это понимают.
Тоже вариант, и намного лучше, чем UBF.
Под «только у ASUS» я имел в виду не отсутствие средств восстановления у других производителей, а отсутствие у них именно описанного в посте Lincoln6Echo метода с USB-носителем и кнопкой на задней панели. Неудачно выразился, прошу меня простить.
Отличительной особенностью технологии USB BIOS Flashback является возможность прошивки BIOS'а без процессора и оперативной памяти. Нужны только дежурное питание, FAT32 USB-носитель с правильно названным файлом BIOS'а и поддержка этой технологии со стороны платы.
Жаль только, что их выпуск преостановлен.
О возможности восстановления из состояния пустой микросхемы или разрушенного дескриптора на этих платах узнал от вас.
Если это действительно так — отлично.
Вопрос только в том, где эта локальная база хранится и насколько хорошо она зашифрована.
Не скажу наверняка, у меня нет платы с поддержкой SecureBoot в данный момент, но скорее всего хранится эта база в регионе BIOS в той же самой микросхеме, а зашифрована либо никак либо практически никак.
Буду рад ошибаться, но по опыту работы с UEFI мнение складывается именно такое.
Скажем так, в данный момент все реализации UEFI, доступные конечному пользователю, хромают на обе ноги, и не только в плане безопасности.
Что у Phoenix, что у AMI баги висят месяцами и переживают по 3-6 обновлений, пока их удается локализовать и исправить. А в новых версиях стабильно вылезают новые. Когда ситуацию станет лучше — непонятно, но пока — вот так.
Лучшая реализация безопасности UEFI на десктопных платах была у Intel, но они перестали их выпускать.
Называется эта технология USB BIOS Flashback и есть она только у ASUS, только на топовых платах X79, Z77 и Z87 (и на Maximus IV Extreme на Z68), и работает только с регионом BIOS. От повреждения (намеренного или случайного, не важно) других регионов она не защищает и после разрушения дескриптора восстановить ей БИОС не получится, проверено не одни раз.
У возможности добавления своих устройств в список загрузочных есть обратная сторона.
Эти добавочные строки хранятся в NVRAM и могут быть прочитаны и записаны любым userspace-кодом с правами root, если ОС предоставляет доступ к EFI Variables. Загруженный в UEFI-режиме Linux — предоставляет, даже утилита efibootmgr для управления загрузкой имеется. А так как раздел ESP можно просто смонтировать и писать на него что угодно, появляется возможность подмены загрузчика или загрузки вместо ОС вредоносного кода.
Более того, с учетом открытости формата EFI Capsule и открытости региона BIOS на запись на большинстве современных плат (закрыт он только на некоторых Z77 и X79, получивших последние обновления BIOS и на некоторых Z87, но далеко не на всех), атака через исполняемых модулей и драйверов UEFI достаточно легко осуществима.
Дамп и прошивка БИОСа могут быть сделаны при помощи flashrom в Linux и Intel Flash Programming Tool в Windows, неразрушающая модификация дампа также не составляет проблемы.
Если же на плате по каким-то причинам открыт регион Descriptor, то вредоносный код может вызвать отказ в обслуживании путем записи в этот регион случайных данных, в результате чего система вообще не сможет загрузиться или перейти в Recovery-режим, что на ноутбуках автоматически означает поход в сервисный центр, а на десктопах и серверах — потерю кучи времени.
На платах с закрытым дескриптором портить можно содержимое региона BIOS, если запись в него возможна, что тоже приводит к невозможности загрузки, но восстановление из такого состояния намного проще.
Также можно портить содержимое NVRAM, что на некоторых старых или неудачных реализациях тоже может привести к невозможности загрузки ни с одного носителя. К примеру, на некоторых Phoenix UEFI (к примеру, на Lenovo x121e AMD) при удалении строк из NVRAM можно удалить строку «BIOS Setup» и потерять возможность попасть в настройки. А при удалении всех строк — вообще потерять возможность сделать что либо без вынимания батареи CMOS на долгий срок или перешивки BIOS на программаторе, в зависимости от того, где хранится NVRAM. К счастью, такое встречается все реже.
Безопасность UEFI даже с учетом SecureBoot (который выключен у 95% пользователей как минимум) оставляет желать много лучшего. А с учетом того, как эту безопасность понимают производители материнских плат — можно считать, что ее там нет совсем. Я не верю, что это сделано специально или со злым умыслом, но я не вижу вообще никаких препятствий к заражению UEFI вредоносным кодом в данный момент.
Надо и про это тоже писать отдельную статью, наверное.
Не верю. Либо загрузчик запускается в тихом режиме и вы его не видите, либо он модифицирован.
А насчет лички — без проблем, но помните, я не настоящий сварщик и каску нашел на стройке. :)
Для меня OS X — не основная, и даже не второстепенная ОС, поэтому и разбираюсь я в ней соответственно.
Благо в сообществе есть более опытные участники, которые помогут, если правильно попросить.
На самом деле, эта статья — не чистое знание, а чистое «чуть чуть прошелся по верхам, и оборвал на самом интересном месте».
Тема UEFI очень обширная, тут и процесс загрузки, и разнообразие форматов исполняемых файлов, и схожесть структур данных в UEFI и Windows, и EDK, и UEFI Shell, и сборка своих исполняемых файлов для UEFI, и написание DXE-драйверов, и NVRAM, и SMM, и безопасность, и виды защит от прошивки, и это половина процента всего, что можно написать про UEFI, и что не будет выглядеть так скучно, как эта статья.
Если интересно — можно продолжать, если не сильно — можно написать пост со списком того, что стоило бы почитать на эту тему и остановиться на этом.
Вторую напишу в ближайшее время.
Без какой-либо защиты, в том виде, в котором оно реализовано на платах на P67/Z68 — это кошмар любого безопасника.
Любой получивший один раз рута код может сделать с БИОСом что угодно.
И не просто стереть его, а записать своих модулей, которые, при грамотном программировании, даже обновление БИОСа стандартными средствами будут переживать.
И все это вот нам подается под соусом «ускоряем загрузку на 10 секунд, пишем БИОС на С, в настройках высокое разрешение и мышь!» Поэтому SecureBoot — все-таки хоть какой-то, но выход из сложившейся ситуации.
Там три разных микросхемы, одна из которых не припаяна, а посажена в ZIF-кроватку.
Никаких хитрых механизмов нет и не нужно, сломалось — щелкнул тумблером, загрузился, щелкнул обратно, прошил новую версию.
И всякие проприентарные прошивальщики они не используют, доверяя прошивку надежному и простому Intel FPT.
Только за одни белые списки, из за которых каждую новую версию БИОСа приходится модифицировать и шить нестандартными способами, я больше никогда решения ни HP ни Lenovo не куплю, пусть там UEFI хоть каким отличным будет. Оборудование и так делают все более закрытым, а чтобы какой-то кореец решал, какие 3G-модем и WiFi-карту я могу поставить в свой ноутбук, а какие нет — увольте.
Поэтому нужно писать в техническую поддержку и требовать возврата опции в список доступных для редактирования. Если быть достаточно настойчивым — вернут.
Возможность эта в прошивке есть и должна быть на вкладке Security.
Отображается эта настройка или нет — другой вопрос, конечно.
Вообще, идея установки на плату нескольких микросхем SPI flash — очень хорошая, жаль, что не все производители это понимают.
Под «только у ASUS» я имел в виду не отсутствие средств восстановления у других производителей, а отсутствие у них именно описанного в посте Lincoln6Echo метода с USB-носителем и кнопкой на задней панели. Неудачно выразился, прошу меня простить.
Отличительной особенностью технологии USB BIOS Flashback является возможность прошивки BIOS'а без процессора и оперативной памяти. Нужны только дежурное питание, FAT32 USB-носитель с правильно названным файлом BIOS'а и поддержка этой технологии со стороны платы.
О возможности восстановления из состояния пустой микросхемы или разрушенного дескриптора на этих платах узнал от вас.
Если это действительно так — отлично.
Не скажу наверняка, у меня нет платы с поддержкой SecureBoot в данный момент, но скорее всего хранится эта база в регионе BIOS в той же самой микросхеме, а зашифрована либо никак либо практически никак.
Буду рад ошибаться, но по опыту работы с UEFI мнение складывается именно такое.
Что у Phoenix, что у AMI баги висят месяцами и переживают по 3-6 обновлений, пока их удается локализовать и исправить. А в новых версиях стабильно вылезают новые. Когда ситуацию станет лучше — непонятно, но пока — вот так.
Лучшая реализация безопасности UEFI на десктопных платах была у Intel, но они перестали их выпускать.
Эти добавочные строки хранятся в NVRAM и могут быть прочитаны и записаны любым userspace-кодом с правами root, если ОС предоставляет доступ к EFI Variables. Загруженный в UEFI-режиме Linux — предоставляет, даже утилита efibootmgr для управления загрузкой имеется. А так как раздел ESP можно просто смонтировать и писать на него что угодно, появляется возможность подмены загрузчика или загрузки вместо ОС вредоносного кода.
Более того, с учетом открытости формата EFI Capsule и открытости региона BIOS на запись на большинстве современных плат (закрыт он только на некоторых Z77 и X79, получивших последние обновления BIOS и на некоторых Z87, но далеко не на всех), атака через исполняемых модулей и драйверов UEFI достаточно легко осуществима.
Дамп и прошивка БИОСа могут быть сделаны при помощи flashrom в Linux и Intel Flash Programming Tool в Windows, неразрушающая модификация дампа также не составляет проблемы.
Если же на плате по каким-то причинам открыт регион Descriptor, то вредоносный код может вызвать отказ в обслуживании путем записи в этот регион случайных данных, в результате чего система вообще не сможет загрузиться или перейти в Recovery-режим, что на ноутбуках автоматически означает поход в сервисный центр, а на десктопах и серверах — потерю кучи времени.
На платах с закрытым дескриптором портить можно содержимое региона BIOS, если запись в него возможна, что тоже приводит к невозможности загрузки, но восстановление из такого состояния намного проще.
Также можно портить содержимое NVRAM, что на некоторых старых или неудачных реализациях тоже может привести к невозможности загрузки ни с одного носителя. К примеру, на некоторых Phoenix UEFI (к примеру, на Lenovo x121e AMD) при удалении строк из NVRAM можно удалить строку «BIOS Setup» и потерять возможность попасть в настройки. А при удалении всех строк — вообще потерять возможность сделать что либо без вынимания батареи CMOS на долгий срок или перешивки BIOS на программаторе, в зависимости от того, где хранится NVRAM. К счастью, такое встречается все реже.
Безопасность UEFI даже с учетом SecureBoot (который выключен у 95% пользователей как минимум) оставляет желать много лучшего. А с учетом того, как эту безопасность понимают производители материнских плат — можно считать, что ее там нет совсем. Я не верю, что это сделано специально или со злым умыслом, но я не вижу вообще никаких препятствий к заражению UEFI вредоносным кодом в данный момент.
Надо и про это тоже писать отдельную статью, наверное.
А насчет лички — без проблем, но помните, я не настоящий сварщик и каску нашел на стройке. :)
Для меня OS X — не основная, и даже не второстепенная ОС, поэтому и разбираюсь я в ней соответственно.
Благо в сообществе есть более опытные участники, которые помогут, если правильно попросить.