Comments 64
Мне кажется, это уже было в Симпсонах. :)
Напишите про другие интересные вещи, пожалуйста.
Про EBC, про недавний вынос всего, чего можно, в SMM, про защиты от прошивки модифицированного БИОСа и методы их обхода, про CryptoPkg и сетевой стек UEFI — да про что угодно, там тема необъятная.
Напишите про другие интересные вещи, пожалуйста.
Про EBC, про недавний вынос всего, чего можно, в SMM, про защиты от прошивки модифицированного БИОСа и методы их обхода, про CryptoPkg и сетевой стек UEFI — да про что угодно, там тема необъятная.
Видите ли, это была вступительная статья, для общего ознакомления. Последующие две статьи будут посвящены более детальному описанию механизмов и начинки. Перечисленные же Вами вещи — безусловно интересны, но прежде чем о них писать хотелось бы дать общую вводную.
Однако, совет принят на заметку :) Как только подготовленный материал закончится, приймусь за более детальные и интересные проработки некоторых пунктов.
Однако, совет принят на заметку :) Как только подготовленный материал закончится, приймусь за более детальные и интересные проработки некоторых пунктов.
Дело в том, что вводная на уже написана.
Если у вас есть, что добавить к той моей статье — отлично, я с удовольствием почитаю, но рассказывать второй раз про одно и то же (и используя в качестве источника ту же самую документацию по UEFI PI) было бы странно, на мой взгляд.
Я вас поддерживаю в любом случае, и напоминаю НЛО об остуствии хаба UEFI, в который как нельзя лучше попали бы эта и похожие статьи. Уважаемая хабракоманда, сделайте с этим что-нибудь, пожалуйста. А уж за наполнением дело не станет.
Если у вас есть, что добавить к той моей статье — отлично, я с удовольствием почитаю, но рассказывать второй раз про одно и то же (и используя в качестве источника ту же самую документацию по UEFI PI) было бы странно, на мой взгляд.
Я вас поддерживаю в любом случае, и напоминаю НЛО об остуствии хаба UEFI, в который как нельзя лучше попали бы эта и похожие статьи. Уважаемая хабракоманда, сделайте с этим что-нибудь, пожалуйста. А уж за наполнением дело не станет.
Причём там даже картинка цветнее!
про недавний вынос всего, чего можно, в SMM
А можно немного поподробнее? Или где про это можно почитать?
Кстати, а не на UEFI ли возможно делать quick-boot-os, когда включил машину и через секунду у тебя уже есть какой-нить скайп, броузер и фоткосмотрелка для фоток с флешки?
Хм, вы наверное имеете в виду возможность написание своих дров и программ непосредственно для UEFI и последующего использывания оных? Тогда да — у разработчика есть возможность писать самому под UEFI и запускать свое творение в этой среде.
Есть возможность не проводить инициализацию устройств, а оставить это дело на совести ОС, но Windows так умеет с Win8. Правда, не знаю, что и как, ибо у меня это называется «MSI Fast Boot», что намекает на платформозависимость.
Скорее это может быть фича вендора материнской платы/чипмейкера, потому как аналогичные опции я видел на базирующихся на интел чипах материнках других именитых вендоров
Напомнило coreboot. В нем основной принцип — проинициализировать только самое основное, а все остальное свалить на linux.
Windows 7 тоже умеет, только образ надо сконвертировать и винт размечать в GPT (для 8 тоже нужно GPT), а «фастбут» на любой мамке работает, главное знать, где включается, и как производитель мог переименовать эту фигню.
Дык было уже у всяких ASUS с их забыл-как-называется-фигнёй (внутри суперкастрированный линукс и капелька софта типа того же скайпа и браузера). Меня куда больше радует холодный старт Windows 8.1 за 5-7 секунд с UEFI.
Как-то слишком коротко.
Как UEFI влияет на количество доступной памяти? Какие-то достаточно бредовые аргументы.
И вообще, на мой взгляд, UEFI не более чем модный тренд, продвигаемый майкрософтом (дабы максимально затруднить пользователям спрыгивание на другие ОС).
Никаких реальных преимуществ перед обычным биосом в статье не приведено (ну окромя странных заявлений про объемы памяти и винчестера).
И вообще, на мой взгляд, UEFI не более чем модный тренд, продвигаемый майкрософтом (дабы максимально затруднить пользователям спрыгивание на другие ОС).
Никаких реальных преимуществ перед обычным биосом в статье не приведено (ну окромя странных заявлений про объемы памяти и винчестера).
Из-за ограничений MBR, OS можно изначально поставить на 2TiB (или 3-х, точно не помню) раздел. Сама OS может видеть и более 2TiB, но грузиться не сможет.
Так-же ограничение на 4-ре раздела. Как обход данного ограничения, появились логические разделы.
Данные проблемы решает GPT, с которым UEFI и работает.
Про оперативную память очевидно, ибо BIOS работает в 16-битном режиме (кроме какого-нибудь OpenBIOS, но опять-же это замена классическому BIOS), а UEFI как минимум в 32-битном.
Плюс было упомянуто о таких преимуществах, как возможность предварительной загрузки драйверов.
Автор статьи сказал об этом, не вдаваясь в подробности, как и подобает вводной статьи из цикла статей. И как уже было упомянуто выше, существуют другие статьи.
Так-же ограничение на 4-ре раздела. Как обход данного ограничения, появились логические разделы.
Данные проблемы решает GPT, с которым UEFI и работает.
Про оперативную память очевидно, ибо BIOS работает в 16-битном режиме (кроме какого-нибудь OpenBIOS, но опять-же это замена классическому BIOS), а UEFI как минимум в 32-битном.
Плюс было упомянуто о таких преимуществах, как возможность предварительной загрузки драйверов.
Автор статьи сказал об этом, не вдаваясь в подробности, как и подобает вводной статьи из цикла статей. И как уже было упомянуто выше, существуют другие статьи.
Про MBR частично соглашусь, но вот по поводу памяти. А какая собственно разница в каком режиме памяти работает биос? ОС давно работают напрямую с памятью, и фактически только возможности ОС накладывают в данном аспекте ограничения. А всякие «финтифлюшки» в виде встроенных браузеров и т.п. считаю абсолютно ненужными игрушками (это ответ к следующему комментарию). Так что тут мимо.
Рискую быть окончательно заминусованным, но еще раз повторюсь — мое ИМХО, что задумано это как средство, в перспективе, для жесткой привязки железа к одному вендору оси (в данном случае к майкрософту). И ничего это кроме грусти не вызывает.
Рискую быть окончательно заминусованным, но еще раз повторюсь — мое ИМХО, что задумано это как средство, в перспективе, для жесткой привязки железа к одному вендору оси (в данном случае к майкрософту). И ничего это кроме грусти не вызывает.
ОС давно работают напрямую с памятью
OS на BIOS вообще плевать, ибо при переходе в Protected Mode и выше использовать функции BIOS не получится (да и не нужно).
Про MBR частично соглашусь, но вот по поводу памяти
Ну не знаю как вам, а по мне 8KiB как-то маловато, имея больше памяти можно будет что-нибудь реализовать, чего нельзя было ранее (таже предварительная загрузка драйверов и т.п.).
Да и потом, это просто следствие. Главное что UEFI сможет взаимодействовать с OS и обратно.
Вот вы и подтвердили мои слова про память. Но извините, в статье явно заявлено как основное преимущество UEFI это использование кучи памяти для ПК, только вот тихо умолчали (в статье), что по большому счету это никому не нужно, и ограничение по памяти накладывает только используемое ОС и платформа.
Теперь по поводу взаимодействия ОС с UEFI и обратно. Цель? Я пока не понимаю. Кроме предварительной загрузки драйверов (что сомнительно как будет работать с разными версиями ОС даже одного вендора), никаких аргументов не приведено.
Теперь по поводу взаимодействия ОС с UEFI и обратно. Цель? Я пока не понимаю. Кроме предварительной загрузки драйверов (что сомнительно как будет работать с разными версиями ОС даже одного вендора), никаких аргументов не приведено.
Преимущества и просто интересные факты о UEFI
Где вы увидели основные факты?
Хорошо, раз уж начали цепляться к словам давайте разберем цитаты из статьи
Каким образом это записано в заслуги UEFI?
Не подготовленный читатель воспримет это как аксиому, тем более в поддержанной сообществом статье, и потом будет на каждом углу кричать, что «без UEFI и память не память».
Игра со спичками. Мне, как и большинству (ИМХО естественно), не важно будет система загружаться 12 секунд, или 8. Мне важна стабильность, чтобы эту систему не нужно было перегружать как можно дольше. И вот здесь у майкрософта не все хорошо.
Однако, уже сейчас можно перечислить несколько очевидных преимуществ UEFI:
1) В связи с веянием последних трендов, все больше ПК имеют 64-х битную ОС, что позволяет увеличить производительность.
Каким образом это записано в заслуги UEFI?
2) Второй немаловажный пункт – это адресация памяти. Замечательная возможность использовать большее количество RAM-а
Не подготовленный читатель воспримет это как аксиому, тем более в поддержанной сообществом статье, и потом будет на каждом углу кричать, что «без UEFI и память не память».
3) Более быстрая загрузка система, достигаемая за счёт параллельной инициализации отдельных компонентов системы.
Игра со спичками. Мне, как и большинству (ИМХО естественно), не важно будет система загружаться 12 секунд, или 8. Мне важна стабильность, чтобы эту систему не нужно было перегружать как можно дольше. И вот здесь у майкрософта не все хорошо.
Каким образом это записано в заслуги UEFI?
Никаким, просто оболочка для начальной настройки будет быстрее работать, загрузчик будет быстрее работать/«грузить» и т.п.
Не подготовленный читатель воспримет это как аксиому, тем более в поддержанной сообществом статье, и потом будет на каждом углу кричать, что «без UEFI и память не память».
Давайте тогда тут в статье распишем абсолютно все! Ибо неподготовленный пользователь может неверно что-то истолковать!
Нет серьезно, статья вводная. Вводная! Это означает, что подробности будут расписаны в последующих статьях.
Игра со спичками. Мне, как и большинству (ИМХО естественно), не важно будет система загружаться 12 секунд, или 8. Мне важна стабильность, чтобы эту систему не нужно было перегружать как можно дольше. И вот здесь у майкрософта не все хорошо.
Во первых, при чем здесь Microsoft?
Во вторых, сколько технологий вы сможете перечислить которые с самого старта 100% были стабильными?
И да, речь идет не о 12 и 8 секундах, а о 12 и 2 секундах, что значительно, и, поверьте, большинству пользователей не все равно, когда им нужно быстренько почту проверить. Так-же с такой скоростью можно будет пересмотреть возможности «спящего режима» и гибернации.
что сомнительно как будет работать с разными версиями ОС даже одного вендора
Как-то сейчас вендорам не мешает писать драйвера под разные OS и железо.
Т.е. таким подходом Вы мне запрещаете держать сразу несколько версий ОС на одном ПК? Я правильно понимаю? Или в этом направлении есть какое-то решение?
Кто вам запрещает держать несколько версий драйверов? Или грузить OS, без предварительной загрузки оных? Или вообще, разработчики позаботится об этом за пользователя и процесс сделают полностью прозрачным и автоматическим.
Ох, и опять возвращаемся к зоопарку. Производители железок очень часто нативные драйвера для ОС годами не могут вылизать. А тут добавляется еще один вид дров, которые необходимо разрабатывать и поддерживать для каждой версии ОС. Знаете чем это закончится? Большинство забьют на дрова для UEFI. Зачем еще вкладывать деньги если и так все работает?
Банальный пример того где это можно использовать, это средства для людей с ограниченными возможностями. Заимствование таких устройств позволит диагностировать различные ошибки загрузки непосредственно самими людьми с ограниченными возможностями.
Так-же выше я упоминал о «продвинутой» версии терминального компьютера, где понадобятся драйвера сетевой карты (Ethernet, WiFi, LTE и т.д.).
Так-же выше я упоминал о «продвинутой» версии терминального компьютера, где понадобятся драйвера сетевой карты (Ethernet, WiFi, LTE и т.д.).
Я могу привести несколько преимуществ UEFI перед традиционным BIOS, ради которых я бы согласился на переход немедленно:
0. Переход с 16-битного реального режима в 64-битный защищенный и плоскую модель памяти.
1. Использование С вместо ассемблера для более 95% кода.
2. Модульность и возможность неразрушающего редактирования как отдельных модулей, так и всего образа БИОСа.
3. Наличие открытого исходного кода большей части модулей (проект TianoCore) и открытой документации (uefi.org).
4. Поддержка передачи отладочных сообщений по шине USB (на coreboot.org уже собрали устройство для их получения, копеечное).
5. Возможность написания собственных программ, исполняемых в среде UEFI: как PEI и DXE-драйверов, так и обычных приложений.
6. Кроссплатформенность части модулей благодаря интерпретатору байткода (EBC).
Можно найти еще плюсов, тут и UEFI GOP, или замена Option ROM на EFI-драйверы, т.д и т.п. Да и SecureBoot при правильном его применении — это скорее хорошо, чем плохо.
0. Переход с 16-битного реального режима в 64-битный защищенный и плоскую модель памяти.
1. Использование С вместо ассемблера для более 95% кода.
2. Модульность и возможность неразрушающего редактирования как отдельных модулей, так и всего образа БИОСа.
3. Наличие открытого исходного кода большей части модулей (проект TianoCore) и открытой документации (uefi.org).
4. Поддержка передачи отладочных сообщений по шине USB (на coreboot.org уже собрали устройство для их получения, копеечное).
5. Возможность написания собственных программ, исполняемых в среде UEFI: как PEI и DXE-драйверов, так и обычных приложений.
6. Кроссплатформенность части модулей благодаря интерпретатору байткода (EBC).
Можно найти еще плюсов, тут и UEFI GOP, или замена Option ROM на EFI-драйверы, т.д и т.п. Да и SecureBoot при правильном его применении — это скорее хорошо, чем плохо.
Насчет модульности, как по мне это минус, ибо может привести к несовместимости систем с UEFI.
Если оно станет стандартизировано и будет везде работать, то хоть по какой шине. А то те-же mini PCI-E POST-карты, на одних ноутбуках работают, на других нет, не говоря уже о том, что нужно держать несколько списков кодов для разных BIOS'ов.
Поддержка передачи отладочных сообщений по шине USB
Если оно станет стандартизировано и будет везде работать, то хоть по какой шине. А то те-же mini PCI-E POST-карты, на одних ноутбуках работают, на других нет, не говоря уже о том, что нужно держать несколько списков кодов для разных BIOS'ов.
Не понял про несовместимость.
От всего UEFI после фазы BDS и передачи управления ОС остается совсем малая часть: Runtime-сервисы и SMM-драйверы (через которые после внедрения SecureBoot реализуется запись в NVRAM и микросхему SPI). Если несовместимость и будет, то это будет желанием производителя платформы, а не разработчиков UEFI. Да и BIOS ничего не мешает сделать несовместимым ни с чем, при желании.
От всего UEFI после фазы BDS и передачи управления ОС остается совсем малая часть: Runtime-сервисы и SMM-драйверы (через которые после внедрения SecureBoot реализуется запись в NVRAM и микросхему SPI). Если несовместимость и будет, то это будет желанием производителя платформы, а не разработчиков UEFI. Да и BIOS ничего не мешает сделать несовместимым ни с чем, при желании.
Все это конечно красиво расписано. И я даже могу порадоваться за Вас, что это все Вам необходимо. Только вот опять ускользает основное — цель всего этого? Еще одна среда разработки?
В моем понимании загрузчик (будем так его называть) должен просто как-то начально проинициализоровать устройства (и то не факт что все) и передать управление ОС. Все.
В моем понимании загрузчик (будем так его называть) должен просто как-то начально проинициализоровать устройства (и то не факт что все) и передать управление ОС. Все.
Опыт показывает, что идея таких загрузчиков, которые «немного проинициализировали и отдали управление ОС» хорошая, но слишком трудно реализуемая. Со стороны ОС приходится делать слишком много действий, отчего появляются устройства, которые не работают нигде, кроме конкретной ОС (не будем показывать на нее пальцем). Поэтому с течением времени в BIOS начали переносить все больше и больше вещей, которыми «должна заниматься ОС», тот же ACPI можно сразу вспомнить (которым до сих пор никто, кроме Apple, толком и не научился пользоваться). Современным ОС для правильной и быстрой загрузки понадобился некий уровень абстракции от оборудования, который решал бы задачи начальной инициализации и отдавал ОС уже подготовленные к дальнейшей работе устройства (которым не нужно дополнительно загружать прошивку, к примеру), для чего и был создан UEFI.
Я согласен с тем, что это далеко не идеальное решение, где-то слишком перегруженное, где-то довольно плохо продуманное и тот же CoreBoot в деле загрузки Linux'а даст прикурить любому UEFI, но сравнивать возможности и скорости UEFI с возможностями и скоростью BIOS нельзя уже сейчас — слишком большой разрыв. Когда отладят кодовую базу и перестанут устраивать в коде революции каждые полгода — будет совсем хорошо.
Я согласен с тем, что это далеко не идеальное решение, где-то слишком перегруженное, где-то довольно плохо продуманное и тот же CoreBoot в деле загрузки Linux'а даст прикурить любому UEFI, но сравнивать возможности и скорости UEFI с возможностями и скоростью BIOS нельзя уже сейчас — слишком большой разрыв. Когда отладят кодовую базу и перестанут устраивать в коде революции каждые полгода — будет совсем хорошо.
Загрузчик ничего не должен инициализировать, он должен передать управление OS. UEFI дает возможность асинхронно инициализировать устройства и загружать драйвера, до полной передачи управления OS, что дает возможность значительно ускорить загрузку системы.
Загрузчик ничего не должен инициализировать
Ну как минимум включить или отключить те же встроенные устройства, в зависимости от настроек. Передать управление внешним устройствам для инициализации (например рейд массивы, сетевки и т.д.). Это все тоже называется «инициализация».
А уже только потом передать управление загрузчику ОС.
Так, что не соглашусь.
Ну как минимум включить или отключить те же встроенные устройства, в зависимости от настроек. Передать управление внешним устройствам для инициализации (например рейд массивы, сетевки и т.д.). Это все тоже называется «инициализация».
Этим занимается BIOS, в зависимости от настроек, которые хранятся в CMOS.
Кстати да, UEFI позволяет нормально работать с сетевой картой, а в купе с возможностью выполнять внешние модули, то можно устроить терминал, который может грузить что угодно от куда угодно (локальная сеть, домен, интернет в конце концов), а не как сейчас мучаться с PXE или предварительно загружать небольшую OS, которая загрузит все остальное.
>>5. Возможность написания собственных программ, исполняемых в среде UEFI: как PEI и DXE-драйверов, так и обычных приложений.>>
с этого места материализуются мои страхи платформонезависимых вирусов «привет чернобыль»
с этого места материализуются мои страхи платформонезависимых вирусов «привет чернобыль»
SecureBoot со своими ключами решает эту проблему, по идее.
Но по факту, на десктопах сейчас безопасность UEFI — никакая. Я могу за вечер написать вирус, аналогичный «чернобылю», который будет использовать только стандартный и подписанный сертификатами AMI Flash Utility, и при этом невосстановимо (без программатора) портить BIOS с потерей всего, что в нем было (серийных номеров, ключей для DTS UltraPC, Virtu, SLI и Windows 8). Спасает только одно — портить компьютеры нынешним злоумышленникам не выгодно.
Но по факту, на десктопах сейчас безопасность UEFI — никакая. Я могу за вечер написать вирус, аналогичный «чернобылю», который будет использовать только стандартный и подписанный сертификатами AMI Flash Utility, и при этом невосстановимо (без программатора) портить BIOS с потерей всего, что в нем было (серийных номеров, ключей для DTS UltraPC, Virtu, SLI и Windows 8). Спасает только одно — портить компьютеры нынешним злоумышленникам не выгодно.
>> Спасает только одно — портить компьютеры нынешним злоумышленникам не выгодно. >>
«Just for fun» — а разве не для этого поначалу писали вирусы. (это сейчас вирусы- орудие заработка школьников, запугивание домохозяек ради годового подсаживания на «маниотдавани» и многое другое деньгозависиоме занятие)
«Just for fun» — а разве не для этого поначалу писали вирусы. (это сейчас вирусы- орудие заработка школьников, запугивание домохозяек ради годового подсаживания на «маниотдавани» и многое другое деньгозависиоме занятие)
Достаточно перестать добавлять в свои утилиты недокументированные ключи для обхода своей же защиты от прошивки чего попало — и все будет хорошо. Но пока гром не грянет — ничего сделано не будет.
Статья кратко описывала UEFI и с чем его едят — согласен. Однако, говорить о «бредовых аргументах» я считаю в корне некорретно. Товарищи BratSinot и CodeRush дали хороший ответ опередив меня. По поводу же злых умыслов Майкрософта — с чего вы взяли, что это личная инициатива мелкомягких? Над разработкой UEFI трудится не один Microsoft, так что давайте без «Теории заговора».
На всех машинах Sun/Oracle производства последних 5 лет стоит EFI
Оно отвратительно сложно. Вместо того, чтобы починить таблицу разделов и оставить 64-битный режим, под шумок вырезав побольше легаси, соорудили невероятного сложного монстра. Зачем делать сложно то, что должно быть просто и маленько?
Задача загрузчика — загрузить ОС, а не изображать из себя приложение внутри другой ОС.
Задача загрузчика — загрузить ОС, а не изображать из себя приложение внутри другой ОС.
Сложность, по сравнению с BIOS'ами последних лет, только понизилась.
Я говорю как о сложности программирования и отладки, так и о сложности процесса загрузки.
Основная задача UEFI — загрузить и выполнить все доступные прошивки для всех подлюченных к системе устройств, и выполняет он эту задачу на «твердую четверку». Я бы тоже предпочел CoreBoot, если бы у меня был выбор, но между BIOS и UEFI я выбираю UEFI, несмотря на все его недостатки.
Я говорю как о сложности программирования и отладки, так и о сложности процесса загрузки.
Основная задача UEFI — загрузить и выполнить все доступные прошивки для всех подлюченных к системе устройств, и выполняет он эту задачу на «твердую четверку». Я бы тоже предпочел CoreBoot, если бы у меня был выбор, но между BIOS и UEFI я выбираю UEFI, несмотря на все его недостатки.
Я видел демки, которые интел показывала — фактически, целая ОС с таймерами, window manager'ом, звуком и кучей левой ерунды. Зачем всё это? Зачем вся эта фагготрия с ключами? То есть зачем — я понимаю. Теперь это «написано у нас» (в смысле, у них). Но в целом — из простого стандарта сделали что-то нереально сложное, что всё равно не будет использоваться как задумано, а будет использоваться по минимуму, а оставшееся будет местом для раздолья неотлаживаемых глюков (потому что всё равно никто это не знает целиком) и всякого рода нелепых уязвимостей.
Для серверов, думаю, будет актуально засунуть туда ssh и rdp/vnc.
Вся левая ерунда нужна маркетологам, чтобы было чем выделить свою плату среди сотни других таких же. «У нас звук при загрузке!», «Зато мы умеем с флешки БИОС восстанавливать после сбоя!», «А у нас управление настройками БИОСа возможно прямо из ОС», «А на нашу плату можно Mac OS X поставить без бубна» и так далее. Ясно, что нам, как потребителям, эта возня мышинная только вредит — слишком много времени тратится на вытребеньки, а не на отладку действительно важного кода.
Про ключи — это отдельная тема. Ребята решили устроить Chain of trust, которая начиналась бы поближе к аппаратуре (спят и видят ключи прямо в процессоре, я уверен), а заканчивалась поближе к кошельку пользователя.
Идея подписывания содержимого микросхемы SPI и выполняемого при загрузке кода — она не настолько плохая, как может показаться, с учетом того, что теперь obscurity нет вообще, и любая программа может делать с содержимым микросхемы SPI все, что угодно.
Никто, черт побери, не мешал решить эту проблему обыкновенным джампером или тумблером на задней панели и не городить огород. SecureBoot в его нынешнем виде продавлен Майкрософтом и сочувствующими, т.к. MS потеряла немало прибыли на пользователях, добавлявших себе в БИОС таблицу SLIC и активировавших свою систему как OEM'ную, и теперь им любые модификации БИОСа — как соль на рану.
Плюс UEFI в том, что некоторые глюки, которые меня бесят, я могу взять и отладить самостоятельно, пользуясь привычными и доступными средствами, дизассемблерами, эмуляторами и отладчиками, не разгребая при этом BLOB на 4 мегабайта.
Понятно, что сделано не очень, и линуксоиды справились бы лучше, скорее всего. Но вариантов нет, изучаем то, что есть.
Пользуйся UEFI или иди на ARM — тут позиция Intel и производителей десктопных плат вполне однозначная.
Про ключи — это отдельная тема. Ребята решили устроить Chain of trust, которая начиналась бы поближе к аппаратуре (спят и видят ключи прямо в процессоре, я уверен), а заканчивалась поближе к кошельку пользователя.
Идея подписывания содержимого микросхемы SPI и выполняемого при загрузке кода — она не настолько плохая, как может показаться, с учетом того, что теперь obscurity нет вообще, и любая программа может делать с содержимым микросхемы SPI все, что угодно.
Никто, черт побери, не мешал решить эту проблему обыкновенным джампером или тумблером на задней панели и не городить огород. SecureBoot в его нынешнем виде продавлен Майкрософтом и сочувствующими, т.к. MS потеряла немало прибыли на пользователях, добавлявших себе в БИОС таблицу SLIC и активировавших свою систему как OEM'ную, и теперь им любые модификации БИОСа — как соль на рану.
Плюс UEFI в том, что некоторые глюки, которые меня бесят, я могу взять и отладить самостоятельно, пользуясь привычными и доступными средствами, дизассемблерами, эмуляторами и отладчиками, не разгребая при этом BLOB на 4 мегабайта.
Понятно, что сделано не очень, и линуксоиды справились бы лучше, скорее всего. Но вариантов нет, изучаем то, что есть.
Пользуйся UEFI или иди на ARM — тут позиция Intel и производителей десктопных плат вполне однозначная.
Ну, мир десктопов — это отдельная песня, а с серверами всё просто. Мне, как админу, не всрался uefi на сервере. И моему работодателю — тоже. Так что будут делать платы с нормальными биосами и не выделываться практически неограниченное время. Потому чт если будут — то рядом окажется вендор, который не делает, и деньги (немалые) окажутся у него, а не у «вендоров с позицией».
На десктопах, я думаю, вменяемые вендоры тоже всё будут делать правильно. UEFI? Отключенная опция в биосе.
На десктопах, я думаю, вменяемые вендоры тоже всё будут делать правильно. UEFI? Отключенная опция в биосе.
Не знаком с рынком серверов, кроме мелочи на базе плат SuperMicro, но на десктопах, ноутбуках и этих мелких серверах уже с 2011 года нет никакого выбора, UEFI или не UEFI — Intel сделала его за всех нас. Ни одни десктопный вендор более плат без UEFI не делает. За все ноутбуки не скажу, но тоже давно БИОСов не видел. Хороший, плохой, в общем — пушка все равно у Intel.
Можно попробовать снять дамп БИОСа с любого достаточно современного сервера и посмотреть, что там. Практически уверен, что там UEFI.
Можно попробовать снять дамп БИОСа с любого достаточно современного сервера и посмотреть, что там. Практически уверен, что там UEFI.
Дело не в его наличии, а альтернативах для него. То бишь к том, могу я пользоваться олдскульными загрузчиками или нет. То есть само наличие технологии не делает ни холодно, ни жарко, пока есть опция по его выключению.
Пока никто Compatibility Support Module выбросить не додумался, это да, но это не совсем «опция по выключению». Весь стек UEFI (кроме драйверов на то оборудование, для которого есть старые Option ROM) продолжает работать, а Legacy BIOS запускается в режиме эмуляции. Возможно, на серверах это не так, не знаю. Олдскульные загрузчики с х86 не выкинут еще лет 10, наверное, слишком ценна обратная совместимость.
А поясните подробнее — при чём тут майкрософт?
Microsoft — одни из самых ранних и активных членов UEFI Forum, и они повлияли на его разработку очень сильно. Половина форматов файлов, используемых в UEFI мало чем отличается от разработанных MS для Windows: DXE-драйверы и UEFI-приложения хранятся в исполняемых файлах PE32+ (с неизменной еще с DOS сигнатурой MZ в начале файла), сертификаты хранятся в структурах WIN_CERTIFICATE, да и INTN EFIAPI EfiMain подозрительно напоминает WinMain.
SecureBoot же MS продавливает очень сильно, и Windows 8.1 даже пишет в правом нижнем углу рабочего стола «SecureBoot отключен», чтобы пользователь видел, что системе это не нравится. Вся возня с SecureBoot сделана ради одной единственной цели — усложнить конечному пользователю модификацию БИОСа или загрузчика ОС, независимо от цели модификации. Если у них все получится, как они хотят, то придется делать «Jailbreak» своему ноутбуку. К счастью для нас, пока все их усилия не привели ни к чему, кроме небольшой потери времени на поиск недокументированных ключей или сборку программатора SPI-flash из спичек и желудей, но эта ситуация может измениться к худшему с выходом каждой следующей линейки процессоров и чипсетов Intel. На данный момент — все фарс и тлен, специалисты по безопасности хмыкают и крутят пальцем у виска, а паранойики уже давно на ARM, еще с момента переезда Management Engine в чипсет.
SecureBoot же MS продавливает очень сильно, и Windows 8.1 даже пишет в правом нижнем углу рабочего стола «SecureBoot отключен», чтобы пользователь видел, что системе это не нравится. Вся возня с SecureBoot сделана ради одной единственной цели — усложнить конечному пользователю модификацию БИОСа или загрузчика ОС, независимо от цели модификации. Если у них все получится, как они хотят, то придется делать «Jailbreak» своему ноутбуку. К счастью для нас, пока все их усилия не привели ни к чему, кроме небольшой потери времени на поиск недокументированных ключей или сборку программатора SPI-flash из спичек и желудей, но эта ситуация может измениться к худшему с выходом каждой следующей линейки процессоров и чипсетов Intel. На данный момент — все фарс и тлен, специалисты по безопасности хмыкают и крутят пальцем у виска, а паранойики уже давно на ARM, еще с момента переезда Management Engine в чипсет.
Правильно ли я понимаю, что оно теоретически ведёт к отсутствию необходимости всевозможных grub/pxe и прочих многостадийных загрузчиков?
8192 екзабайт винт, 16 екзабайт памяти. Опять мало заложили на будущее.
Устареет лет через 15 и опять будем мучатся. Опять напишут какую-то хрень и назовут UEBI. Блииин.
Устареет лет через 15 и опять будем мучатся. Опять напишут какую-то хрень и назовут UEBI. Блииин.
UEFI позволяет также обойтись совсем без ассемблера для запуска ОС: blog.theincredibleholk.org/blog/2013/11/18/booting-to-rust/
Sign up to leave a comment.
UEFI — Ааа, слышал… но все же, что это?