Вся левая ерунда нужна маркетологам, чтобы было чем выделить свою плату среди сотни других таких же. «У нас звук при загрузке!», «Зато мы умеем с флешки БИОС восстанавливать после сбоя!», «А у нас управление настройками БИОСа возможно прямо из ОС», «А на нашу плату можно Mac OS X поставить без бубна» и так далее. Ясно, что нам, как потребителям, эта возня мышинная только вредит — слишком много времени тратится на вытребеньки, а не на отладку действительно важного кода.
Про ключи — это отдельная тема. Ребята решили устроить Chain of trust, которая начиналась бы поближе к аппаратуре (спят и видят ключи прямо в процессоре, я уверен), а заканчивалась поближе к кошельку пользователя.
Идея подписывания содержимого микросхемы SPI и выполняемого при загрузке кода — она не настолько плохая, как может показаться, с учетом того, что теперь obscurity нет вообще, и любая программа может делать с содержимым микросхемы SPI все, что угодно.
Никто, черт побери, не мешал решить эту проблему обыкновенным джампером или тумблером на задней панели и не городить огород. SecureBoot в его нынешнем виде продавлен Майкрософтом и сочувствующими, т.к. MS потеряла немало прибыли на пользователях, добавлявших себе в БИОС таблицу SLIC и активировавших свою систему как OEM'ную, и теперь им любые модификации БИОСа — как соль на рану.
Плюс UEFI в том, что некоторые глюки, которые меня бесят, я могу взять и отладить самостоятельно, пользуясь привычными и доступными средствами, дизассемблерами, эмуляторами и отладчиками, не разгребая при этом BLOB на 4 мегабайта.
Понятно, что сделано не очень, и линуксоиды справились бы лучше, скорее всего. Но вариантов нет, изучаем то, что есть.
Пользуйся UEFI или иди на ARM — тут позиция Intel и производителей десктопных плат вполне однозначная.
Сложность, по сравнению с BIOS'ами последних лет, только понизилась.
Я говорю как о сложности программирования и отладки, так и о сложности процесса загрузки.
Основная задача UEFI — загрузить и выполнить все доступные прошивки для всех подлюченных к системе устройств, и выполняет он эту задачу на «твердую четверку». Я бы тоже предпочел CoreBoot, если бы у меня был выбор, но между BIOS и UEFI я выбираю UEFI, несмотря на все его недостатки.
Опыт показывает, что идея таких загрузчиков, которые «немного проинициализировали и отдали управление ОС» хорошая, но слишком трудно реализуемая. Со стороны ОС приходится делать слишком много действий, отчего появляются устройства, которые не работают нигде, кроме конкретной ОС (не будем показывать на нее пальцем). Поэтому с течением времени в BIOS начали переносить все больше и больше вещей, которыми «должна заниматься ОС», тот же ACPI можно сразу вспомнить (которым до сих пор никто, кроме Apple, толком и не научился пользоваться). Современным ОС для правильной и быстрой загрузки понадобился некий уровень абстракции от оборудования, который решал бы задачи начальной инициализации и отдавал ОС уже подготовленные к дальнейшей работе устройства (которым не нужно дополнительно загружать прошивку, к примеру), для чего и был создан UEFI.
Я согласен с тем, что это далеко не идеальное решение, где-то слишком перегруженное, где-то довольно плохо продуманное и тот же CoreBoot в деле загрузки Linux'а даст прикурить любому UEFI, но сравнивать возможности и скорости UEFI с возможностями и скоростью BIOS нельзя уже сейчас — слишком большой разрыв. Когда отладят кодовую базу и перестанут устраивать в коде революции каждые полгода — будет совсем хорошо.
Не понял про несовместимость.
От всего UEFI после фазы BDS и передачи управления ОС остается совсем малая часть: Runtime-сервисы и SMM-драйверы (через которые после внедрения SecureBoot реализуется запись в NVRAM и микросхему SPI). Если несовместимость и будет, то это будет желанием производителя платформы, а не разработчиков UEFI. Да и BIOS ничего не мешает сделать несовместимым ни с чем, при желании.
Дело в том, что вводная на уже написана.
Если у вас есть, что добавить к той моей статье — отлично, я с удовольствием почитаю, но рассказывать второй раз про одно и то же (и используя в качестве источника ту же самую документацию по UEFI PI) было бы странно, на мой взгляд.
Я вас поддерживаю в любом случае, и напоминаю НЛО об остуствии хаба UEFI, в который как нельзя лучше попали бы эта и похожие статьи. Уважаемая хабракоманда, сделайте с этим что-нибудь, пожалуйста. А уж за наполнением дело не станет.
Я могу привести несколько преимуществ 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 при правильном его применении — это скорее хорошо, чем плохо.
Мне кажется, это уже было в Симпсонах. :)
Напишите про другие интересные вещи, пожалуйста.
Про EBC, про недавний вынос всего, чего можно, в SMM, про защиты от прошивки модифицированного БИОСа и методы их обхода, про CryptoPkg и сетевой стек UEFI — да про что угодно, там тема необъятная.
Все, что я хочу сказать по поводу Фортрана: GO TO (320,330,340,350,360), K
Ну и не ясно, почему тогда не C с теми же самыми плюсами (невольный каламбур), что и Фортран, только еще более распространенный, с не меньшим количеством библиотек и значительно более востребованный.
Ничего не хочу сказать плохого про AVR, возможно, они действительно идеальны для ваших задач, но я бы все равно советовал неспеша переходить на ARM. Не холивара ради, просто совет.
После работы с каким-нибудь STM32F4, читая о том, что AVR «мощные» и у них «куча переферии», как-то внутренне улыбаешься. STM32F1xx есть в любом магазине, стоят они не намного дороже, при грамотной разводке (т.е. почитать не только даташит на конкретный чип, а еще и compatibility note) поставить чип другой серии тоже проблема не большая, а навесные убердевайсы вообще мало привязаны к конкретной архитектуре и производителю МК. AVR — это глобально и надежно, но будущее все же за 32-битными МК, как мне кажется. Да и выбор производителя, IDE и всего остального — значительно шире.
Забрал последний Vostro 3360 из онлайн-магазина Dell в Германии, не пожалел ни секунды. Да, не все гладко, и кое-что все таки нет-нет, да бесит, но то, что они свернули эту линейку — это крайне печально.
MOV EAX, EDX — это просто чуть более понятная человеку запись числа 0x89D0 (возмем, для определенности, Intel syntax для x86-64), ни больше, ни меньше, и сама по себе запись ничего никуда не копирует. И если для вышеуказанной команды опкод существует — она будет работать, а если нет — не будет, хотя и построена по аналогии. Мне никто не мешает написать mov eax, DWORD PTR CS:0x0, которое будет транслированно в 0х2E8B042500000000, но команду mov DWORD PTR CS:0x0, DWORD PTR DS:0x0, построенную «по аналогии» транслировать уже не во что — нет такого опкода.
Вы, скорее всего, не работали с ассемблерами для простых процессоров с минимальным числом опкодов. Это у x86 есть опкоды почти на все случаи жизни, а у МК бывает так, что mov работает только между этими несколькими регистрами, операции с отдельными битами — вообще с одним единственным регистром, а сохранность содержимого вот этого регистра вам никто не гарантирует. И таких ограничений бывает столько и таких забавных, что лучшый способ не погрязнуть в них — не строить вообще никаких аналогий, как Ди и предлагает.
В качестве упражнения для понимания ассемблера я бы рекомендовал написать ассемблер.
Простейший, без директив, без макросов и прочих высокоуровневых конструкций, на том языке, который вы уже знаете.
А если по хардкору, то прямо в машинных кодах процессора, который вы видите впервые (но имеете на него документацию и errata, иначе это не упражнение, а мазохизм). ;)
Это сродни обучению плавать методом выбрасывания из лодки, конечно, но зато понимание приходит раз и насовсем, и далее разобраться о очередным вариантом ассемблера большого труда уже не составляет, была бы документация.
За широко известное в узких кругах «my name is Lennart Poettering and I pronounce Linux as shshshshshs». PA очень сильно портит звук на некоторых устройствах, и поэтому его наоборот обычно приходится вырывать с корнями.
Это кошмар, но здесь нисколько не лучше. Через инернет невозможно купить даже единственный микроконтролер, и вообще практически любую радиодеталь, не являсь представителем какой-либо фирмы или студентом профильной специальности. Я тоже занимался производством пробной партии SPI-программатора на базе FT232H, и в Китае заказывать не стал по этим же причинам — таможня очень суровая, и у меня она еще и в другом городе находится. Заказал производство плат у немецкой фирмы, паял сам, ибо там устройство очень простое. Производство окупилось, и меня это радует, т.к. заработать я не планировал.
Про кабалу — в России сейчас гораздо свободнее, чем в Германии. Финансы здесь государство контролирует давно и прочно, полиция имеет гораздо большие полномочия (к счастью, и гораздо более высокую квалификацию, в среднем), наличными деньгами можно расчитаться практически только за продукты в супермаркете, а наличие большой суммы наличности автоматически вызывает подозрение. А штрафы за нарушение законов такие, что вы не захотите их нарушать.
И это не угнетает, понимаете? У меня нет желания бороться с правительством, не пользоваться услугами банков и государства, бойкотировать их иннициативы и т.п. — я просто живу и работаю, и все это если и мешает, то не сильно. Перегибы случаются везде, конечно, но пока от того, что государство знает обо мне все, я только в выигрыше. Возможно, в будущем мнение изменится, но пока я не вижу причин для того, чтобы быть против и выступать против. Система не очень, но она работает.
Они написаны не переводчиком документации, и не диванным аналитиком, и уже этим они очень ценны.
Искреннее большое спасибо.
Про ключи — это отдельная тема. Ребята решили устроить Chain of trust, которая начиналась бы поближе к аппаратуре (спят и видят ключи прямо в процессоре, я уверен), а заканчивалась поближе к кошельку пользователя.
Идея подписывания содержимого микросхемы SPI и выполняемого при загрузке кода — она не настолько плохая, как может показаться, с учетом того, что теперь obscurity нет вообще, и любая программа может делать с содержимым микросхемы SPI все, что угодно.
Никто, черт побери, не мешал решить эту проблему обыкновенным джампером или тумблером на задней панели и не городить огород. SecureBoot в его нынешнем виде продавлен Майкрософтом и сочувствующими, т.к. MS потеряла немало прибыли на пользователях, добавлявших себе в БИОС таблицу SLIC и активировавших свою систему как OEM'ную, и теперь им любые модификации БИОСа — как соль на рану.
Плюс UEFI в том, что некоторые глюки, которые меня бесят, я могу взять и отладить самостоятельно, пользуясь привычными и доступными средствами, дизассемблерами, эмуляторами и отладчиками, не разгребая при этом BLOB на 4 мегабайта.
Понятно, что сделано не очень, и линуксоиды справились бы лучше, скорее всего. Но вариантов нет, изучаем то, что есть.
Пользуйся UEFI или иди на ARM — тут позиция Intel и производителей десктопных плат вполне однозначная.
Я говорю как о сложности программирования и отладки, так и о сложности процесса загрузки.
Основная задача UEFI — загрузить и выполнить все доступные прошивки для всех подлюченных к системе устройств, и выполняет он эту задачу на «твердую четверку». Я бы тоже предпочел CoreBoot, если бы у меня был выбор, но между BIOS и UEFI я выбираю UEFI, несмотря на все его недостатки.
Я согласен с тем, что это далеко не идеальное решение, где-то слишком перегруженное, где-то довольно плохо продуманное и тот же CoreBoot в деле загрузки Linux'а даст прикурить любому UEFI, но сравнивать возможности и скорости UEFI с возможностями и скоростью BIOS нельзя уже сейчас — слишком большой разрыв. Когда отладят кодовую базу и перестанут устраивать в коде революции каждые полгода — будет совсем хорошо.
От всего UEFI после фазы BDS и передачи управления ОС остается совсем малая часть: Runtime-сервисы и SMM-драйверы (через которые после внедрения SecureBoot реализуется запись в NVRAM и микросхему SPI). Если несовместимость и будет, то это будет желанием производителя платформы, а не разработчиков UEFI. Да и BIOS ничего не мешает сделать несовместимым ни с чем, при желании.
Если у вас есть, что добавить к той моей статье — отлично, я с удовольствием почитаю, но рассказывать второй раз про одно и то же (и используя в качестве источника ту же самую документацию по UEFI PI) было бы странно, на мой взгляд.
Я вас поддерживаю в любом случае, и напоминаю НЛО об остуствии хаба UEFI, в который как нельзя лучше попали бы эта и похожие статьи. Уважаемая хабракоманда, сделайте с этим что-нибудь, пожалуйста. А уж за наполнением дело не станет.
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 при правильном его применении — это скорее хорошо, чем плохо.
Напишите про другие интересные вещи, пожалуйста.
Про EBC, про недавний вынос всего, чего можно, в SMM, про защиты от прошивки модифицированного БИОСа и методы их обхода, про CryptoPkg и сетевой стек UEFI — да про что угодно, там тема необъятная.
А можно выложить архив с результатом
для ленивых?GO TO (320,330,340,350,360), KНу и не ясно, почему тогда не C с теми же самыми плюсами (невольный каламбур), что и Фортран, только еще более распространенный, с не меньшим количеством библиотек и значительно более востребованный.
После работы с каким-нибудь STM32F4, читая о том, что AVR «мощные» и у них «куча переферии», как-то внутренне улыбаешься. STM32F1xx есть в любом магазине, стоят они не намного дороже, при грамотной разводке (т.е. почитать не только даташит на конкретный чип, а еще и compatibility note) поставить чип другой серии тоже проблема не большая, а навесные убердевайсы вообще мало привязаны к конкретной архитектуре и производителю МК. AVR — это глобально и надежно, но будущее все же за 32-битными МК, как мне кажется. Да и выбор производителя, IDE и всего остального — значительно шире.
Вы, скорее всего, не работали с ассемблерами для простых процессоров с минимальным числом опкодов. Это у x86 есть опкоды почти на все случаи жизни, а у МК бывает так, что mov работает только между этими несколькими регистрами, операции с отдельными битами — вообще с одним единственным регистром, а сохранность содержимого вот этого регистра вам никто не гарантирует. И таких ограничений бывает столько и таких забавных, что лучшый способ не погрязнуть в них — не строить вообще никаких аналогий, как Ди и предлагает.
Простейший, без директив, без макросов и прочих высокоуровневых конструкций, на том языке, который вы уже знаете.
А если по хардкору, то прямо в машинных кодах процессора, который вы видите впервые (но имеете на него документацию и errata, иначе это не упражнение, а мазохизм). ;)
Это сродни обучению плавать методом выбрасывания из лодки, конечно, но зато понимание приходит раз и насовсем, и далее разобраться о очередным вариантом ассемблера большого труда уже не составляет, была бы документация.
Про кабалу — в России сейчас гораздо свободнее, чем в Германии. Финансы здесь государство контролирует давно и прочно, полиция имеет гораздо большие полномочия (к счастью, и гораздо более высокую квалификацию, в среднем), наличными деньгами можно расчитаться практически только за продукты в супермаркете, а наличие большой суммы наличности автоматически вызывает подозрение. А штрафы за нарушение законов такие, что вы не захотите их нарушать.
И это не угнетает, понимаете? У меня нет желания бороться с правительством, не пользоваться услугами банков и государства, бойкотировать их иннициативы и т.п. — я просто живу и работаю, и все это если и мешает, то не сильно. Перегибы случаются везде, конечно, но пока от того, что государство знает обо мне все, я только в выигрыше. Возможно, в будущем мнение изменится, но пока я не вижу причин для того, чтобы быть против и выступать против. Система не очень, но она работает.