Жесткие диски бывают разные, они подключаются к разным интерфейсам.

Какие проблемы зайти на сайт производителя, скачать и установить (подписать/отписать/зашифровать) модуль/драйвер/блоб, работающий по открытому «универсальному интерфейсу»? А ли «универсальный интерфейс» - не универсальный?

сразу из флеша грузит Linux… Без поддержки DOS и Windows

Могут же, когда захотят, некоторые. А некоторые не могут или не хотят.

Что значит «контролирует устройство»?

То и значит: имея достаточно знаний, можно управлять поведением.

А выясняется - знаешь, что не можешь. Твое распоследнее железо с «универсальным интерфейсом» работает только под оффтопом, или только под огрызком. И знание «универсального интерфейса» тебе ничего не дает. Нужно знать скрытые возможности, описанные в скрытой спецификации. Остается только универсальный жест Линуса показывать.

Какие проблемы зайти на сайт производителя, скачать и установить

То есть нужен второй компьютер. А ещё прошивка должна быть достаточно обмазана универсальными интерфейсами, чтобы в неё можно было доставлять эти самые модули.

В UEFI сделали ещё лучше — системная прошивка может получать свои кусочки (по стандартизованному протоколу) от плат расширения, так что и качать ничего не нужно.

И за это приходится платить сложностью. Универсальное сложнее простого, жёстко сконфигурированного на момент генерации монолита.

Могут же, когда захотят, некоторые.

Большинство пользователей не хочет ковыряться с coreboot. Они хотят plug-and-play, чтобы всё сразу работало, без приложения усилий, в любых конфигурациях и без необходимости обретать дополнительные знания.

То и значит: имея достаточно знаний, можно управлять поведением.

Получается, что если количество знаний, необходимое для управления поведением слишком велико (настолько, что не влезает в одного человека), то никто не может контролировать устройство единолично?

И что значит «управлять поведением»? Если менять абсолютно любой его аспект, то см. выше. Если любое управление подойдёт, то я могу разломать молотком процессор, и он перестанет работать (поведение изменилось из-за моего вмешательства); это значит я процессоры контролирую с помощью молотка?

Повторю предыдущий вопрос: как изменится мой уровень контроля, если я смогу преодолеть отрицательные кольца защиты? Какие принципиально новые возможности я получу?

Твое распоследнее железо с «универсальным интерфейсом» работает только под оффтопом

Да, просто потому, что под другие ОС реализацию интерфейса не завезли. Но если интерфейс специфицирован, а спецификации доступны всем желающим, то и реализацию можно в любимую ОС добавить. Просто для этого надо потратить какое-то количество усилий. Или подождать, пока это сделает кто-нибудь ещё. Прямо как с coreboot.

Универсальный жест Линус показывал совсем другим ребятам — которые не хотят специфицировать протоколы взаимодействия со своим железом и раскрывать подробности его работы. Там нет никаких универсальных интерфейсов.

Для самих современных ОС в UEFI есть runtime services

Насколько я знаю, ничего полезного среди них нет, кроме, может, SystemReset() и работы с переменными.

ОС нужно уметь взаимодействовать с UEFI, чтобы рассказать ему перед suspend, как восстановить состояние железа.

Да, в общем то, не обязательно. ACPI хватает для этих целей.

То есть ОС, работающая в UEFI-окружении и не использующая ни legacy CSM, и при этом игнорирующая факт существования UEFI, будет сильно ограниченной в своих возможностях.

Вряд ли. Ограничения самые мизерные, если вообще.

(int10, последнее время всё чаще работающие внутри VM, v86d)

Да бросьте, где вы, в дикой природе, встречали v86d? Это мертвейший костыль. Все обращения к прерываниям выполняются загрузчиком, а ядро получает от него эту инфу уже по своему протоколу загрузки.

Одновременно с ОС (на том же процессоре) работают установленный UEFI или legacy BIOS SMM-код.

Не всегда. Если ядро сделало биосу хэнд-офф на УСБ, то отключается СММная эмуляция легаси оборудования. Можно и вообще SMI потом запретить.

ACPI хватает для этих целей.

А кто S3 bootscript выполнит? По сути тот же вызов сервиса, просто необычным образом отложенный.

Ограничения самые мизерные, если вообще. Можно и вообще SMI потом запретить.

Тогда где же ОС, которые в качестве конкурентного преимущества будут заявлять, что они безопаснее и стабильнее, ведь после загрузки они убивают жизнедеятельность системной прошивки до ребута?

Вживую видел современную платформу, где SMI использовался для watchdog и для синхронизации TSC между процессорами. Отключение SMI на ней приведёт к некоторой потере функциональности. Собственно SMM для того и придумали, чтобы прятать туда такие штуки, про которые ОС может не знать. На некоторых платформах (например Geode) это доведено до абсурда — текстовый режим сделан из графического целиком на SMM (софтовым знакогенератором). А ещё под Linux (по крайней мере раньше) не было родного драйвера для звука, поэтому работала реализованная в SMM эмуляция SB16.

Думаю, что примерно на любой современной платформе при нормальной эксплуатации периодически происходят SMI.

Да бросьте, где вы, в дикой природе, встречали v86d?

Полтора года назад в инсталляторе системы. Это оказался наиболее универсальный способ поднять консоль, не притаскивая иксы и драйвера на все случаи жизни. Особенно лучше становилось на тот момент с последними картами от NVIDIA, которые требуют проприетарных драйверов — с nouveau они не работали совсем никак. efifb тоже неплохо работает, но видимо есть существенная доля пользователей с CSM.

А кто S3 bootscript выполнит?

А кто сказал, что это необходимо делать, если операционка сама управляет всеми устройствами? Этот скрипт, вроде бы, нужен только при использовании уефайных дров, или я не прав? Кроме того, драйверам операционки никто не запрещает дёргать ACPI методы соотв девайса при резьюме, так что я не вижу тут проблемы.

Тогда где же ОС, которые в качестве конкурентного преимущества будут заявлять, что они безопаснее и стабильнее, ведь после загрузки они убивают жизнедеятельность системной прошивки до ребута?

В этом и есть безопасность и стабильность. На соотв железе, разумеется. Всякие ноутбучные квирки сюда не относятся. :)

Вживую видел современную платформу, где SMI использовался для watchdog и для синхронизации TSC между процессорами.

А я могу использовать NMI вочдог, и синхронизация ТСЦ на современных процах уже не представляет проблем, насколько я знаю.

Собственно SMM для того и придумали, чтобы прятать туда такие штуки

… костыли.

про которые ОС может не знать.

Это и в ACPI методы можно прятать.

текстовый режим сделан из графического целиком на SMM (софтовым знакогенератором).

Ну так операционка попросит хэнд-офф, и сделает модесет сама. SMM в основном для легаси, и ваш пример это отлично подтверждает.

А ещё под Linux (по крайней мере раньше) не было родного драйвера для звука, поэтому работала реализованная в SMM эмуляция SB16.

Вот-вот. :) Это всё легаси.

Думаю, что примерно на любой современной платформе при нормальной эксплуатации периодически происходят SMI.

Наколеночного железа сейчас много, но есть и нормальное. :) Если, к примеру, плата с ТианоКоре работает, я сильно сомневаюсь, что там будут эсэмаи бегать.

Это оказался наиболее универсальный способ поднять консоль

А для консоли то он зачем? fbcon будет отлично рендерить консоль на фрейм-буффер. Модесет тут не особо нужен. И, кстати, к Вам, как к спецу, вопрос: где драйвер для VBE3/PM? Вот для VBE2 сделали, только он с прот модом не дружит. VBE3 дружит - драйвер под линукс не напилили, ещё с этим v86d лезут… Куда такое годится? :)

А кто сказал, что это необходимо делать, если операционка сама управляет всеми устройствами?

ОС хотелось бы знать, в каком именно состоянии окажутся устройства после того, как firmware передаст управление на S3 wakeup vector. Хотя вроде бы Linux тупо переинициализирует всё подряд, как при обычной загрузке. В это место давно не смотрел, так что могу наврать.

… костыли.

От них-то и растёт сложность, увы. Если их убрать, то потребуется заместить их некостыльной реализацией во всех ОС, что нельзя сделать мгновенно. Поэтому и приходится костылять.

Это и в ACPI методы можно прятать.

Ага, а потом оказывается, что особенности конфигурирования разными драйверами/ОС железок важны, и приходится сравнения строк _OSI и _REV писать. Посмотрите, например, на таблички у типичного PC с вендорским биосом и на них же на той же машине, но с coreboot — разница в объёме будет раза в четыре. Так что от методов костыли никуда не делись, их просто спрятали в байткод.

NMI вочдог

А кто возбудит NMI? Да, где-то это всё ещё делает чипсет, а где-то как раз счётчик внутри SMM с возбуждаемым SMI по таймеру от чипсета. Да и NMI можно потерять/повиснуть в обработчике ОС в случае ошибки в драйвере, а от ребута в SMI handler не спрячешься.

В этом и есть безопасность и стабильность.

Так где же взять такую готовую ОС с кнопкой «сделай мне безопасно»? В тот же Qubes это бы отлично вписалось.

Если, к примеру, плата с ТианоКоре работает, я сильно сомневаюсь, что там будут эсэмаи бегать.

Сейчас под рукой есть китайская noname-коробока на Braswell. Не знаю, насколько всё там близко к TianoCore, но менюшки выглядят так, будто при генерации прошивки ничего не настраивали вообще — открыто абсолютно всё, включая те опции, которые точно нерелевантны этому железу. На ней в линуксе SMI происходит по крайней мере два раза в секунду. Что внутри обработчика — не знаю. Если SMI замаскировать, то вроде бы ничего не ломается, за полчаса она не зависла.

Куда такое годится? :)

Не годится, конечно же. Это недостаток, который пока не исправлен. :) Просто мало кому это интересно, ведь есть нормальные драйвера.

То есть нужен второй компьютер.

Всю жизнь устанавливали драйвера со сторонних источников для неизвестных устройств. UEFI практически никак не изменил ситуацию. Теперь придется делать это два раза на каждый чих: и прошивку менять и драйвера в системе устанавливать. Размножение сложности.

А перезаписываемые пзу были и до uefi, и не при чем он здесь.

Большинство пользователей не хочет ковыряться с coreboot. Они хотят plug-and-play

То есть не работает этот «универсальный интерфейс». Новое железо - новая прошивка. Или сам ковыряйся. Или покупай новый программно-аппаратаный комплекс от производителя с жестко привязанными идентификаторами железа в прошивке. Зато «универсально», аж уникально.

Получается, что если количество знаний, необходимое для управления поведением слишком велико

Это признание искусственного переусложнения проблемы управления/владения устройством?

Зачем начальному загрузчику tcp/ip? Почему этим не может заниматься прикладной софт, который установит пользователь по своему желанию?

как изменится мой уровень контроля, если я смогу преодолеть..?

Так и измениться. Если сумеешь преодолеть. Ты либо трусы одень, либо… Раз ты уже преодолел и пишешь свои прошивки, то ты прекрасно знаешь, как у тебя изменился уровень контроля.

Да, просто потому, что под другие ОС реализацию интерфейса не завезли.

Вроде, ты в начале говорил, что «универсальность» избавляет от «не завезли». А теперь оказывается надо и прошивку надо завозить и ОС. Размножение сложности?

Универсальный жест Линус показывал…

…за то, что некоторые хотят в универсум Линуса, но не пускают в свой универсум.

особенности конфигурирования разными драйверами/ОС железок важны, и приходится сравнения строк _OSI и _REV писать.

Как будто с uefi не так.

Ага, а потом оказывается, …

… что конкретный «универсальный» efi работает только с конкретным программно-аппаратным окружением.

Добавлю.

ACPI хотя бы не зависит от системы команд процессора

Если их убрать, то потребуется заместить их некостыльной реализацией во всех ОС

Да не надо во всех. :) Просто, для нормальных ОС, UEFI без надобности после этапа загрузки. А легаси ОСям и с биосом хорошо работалось. В результате, «рынок» рантайм-сервисов уефая не слишком-то велик. Стоило оно того, чтобы такие велосипеды городить - непонятно. ACPI уже решал вопрос доступа к биосу из защ режима.

Так что от методов костыли никуда не делись, их просто спрятали в байткод.

Это понятно. Непонятно, для чего было городить уефай, когда и так уже все эти задачи были решены. Новая внутренняя архитектура биоса - это хорошо. Но зачем понадобилось и все внешние АПИ менять, когда операционке в рантайме нужно совсем чуть, и это «чуть» есть уже в ACPI? Либо пускай чётко скажут: «ACPI не взлетел, а в следующих процах мы ещё и риалмод выкинем, вот и решили всё переделать заранее» - ну это как вариант. Но я пока такого не слышал.

А кто возбудит NMI?

Лапик, Холмс. :) lapic.

Так где же взять такую готовую ОС с кнопкой «сделай мне безопасно»?

Она должна быть не с «кнопкой», а с сертифицированным под неё железом. Касперский вот пытался корешиться с различными вендорами железа (Kraftway, Advantech) для своей KasperskyOS, посмотрим, что там выйдет… Идея была в том, что, на кривом железе, безопасной ОС не будет в любом случае, так лучше сразу делать под вендора.

Не знаю, насколько всё там близко к TianoCore

Я имел в виду тианку поверх коребута.

Зачем начальному загрузчику tcp/ip? Почему этим не может заниматься прикладной софт, который установит пользователь по своему желанию?

Тут не соглашусь с коллегой анонимусом: нет ничего плохого в том, что они в биос запихнули tcp/ip - пользователь всё ещё может это всё ставить и по своему желанию. Зато теперь вы можете зайти в биос, и скачать обновление биоса прямо оттуда. А то и вовсе, посерфить по инету, не загружая операционку. :) Со временем, можно будет на армовый проц накатить биос с qemu и пускать винду.

Вроде, ты в начале говорил, что «универсальность» избавляет от «не завезли». А теперь оказывается надо и прошивку надо завозить и ОС. Размножение сложности?

Задача прошивки PC — настроить железо достаточным образом для того, чтобы ОС могла на нём функционировать. ОС может быть старой, но прошивка скорее всего примерно соответствует поколению железа.

Железо содержит кусочки прошивки на тот случай, если системная прошивка окажется староватой. Например, контроллер NVMe может научить UEFI использовать себя в качестве блочного устройства.

Если ОС настолько старая, что не может пользоваться железом, прошивка может помочь ОС — обманывать ОС, представляя новое железо старым, с которым она умеет работать. Так, например, DOS может работать с USB-устройствами.

Такой подход увеличивает сложность, но и универсальность программно-аппаратного комплекса железо+прошивка.

Есть другой подход, когда в программно-аппаратный комплекс затаскивается конкретная ОС. Тогда не может возникнуть несоответствия эпох, и не надо никого хачить и обманывать. Как с coreboot и Linux — кода меньше, хаков меньше, грузится быстрее. Но надо ковыряться.

А перезаписываемые пзу были и до uefi, и не при чем он здесь.

То есть не работает этот «универсальный интерфейс». Новое железо - новая прошивка. Или сам ковыряйся. Или покупай новый программно-аппаратаный комплекс от производителя с жестко привязанными идентификаторами железа в прошивке. Зато «универсально», аж уникально.

Пользователь не хочет перезаписывать ПЗУ, чтобы заставить работать новую железку, которая нужна для загрузки ОС. Он хочет, чтобы прошивка железки научила системную прошивку работе с ней.

Без UEFI приходилось делать предположения относительно того, как устроен монолитный BIOS и добавлять биососпецифичные хаки.

С UEFI всё работает само. Без ковыряний и перепрошивок. Потому что есть стандартные интерфейсы, про которые производители сторонних железок знают.

Это признание искусственного переусложнения проблемы управления/владения устройством?

Нет, я пытаюсь понять, какой уровень контроля считается достаточным. Если чайник сидит перед преднастроенным компьютером и не умеет устанавливать программы, а только лишь запускать те, что есть на рабочем столе — он контролирует компьютер? А если научился устанавливать готовые программы?

Один человек не сможет уметь и знать вообще всё. Он будет вынужден кому-то что-то делегировать, взять у него готовое, и доверять этому.

Если и процессоры, и прошивку Intel ME делает одна и та же компания, и контроля над внутренностями процессора у меня нет, то почему меня должна волновать технология Intel ME? Если она может следить за мной, то процессор уж точно сможет. Если на внутренности Intel ME я хоть как-то могу посмотреть, то найти закладку в CPU мне будет уже не по силам.

На материнской плате есть куча микросхем, которые я не могу исследовать. Тот же поизводитель материнской платы написал системную прошивку, в которой есть обработчик SMI. Если он захочет перехватить управление моим компьютером, то микросхеме это будет проще сделать, чем коду в SMM. Аналогично, если на код в SMM я хоть как-то могу посмотреть и что-то там подправить, то с закладкой в микросхеме я уже не справлюсь.

Раз ты уже преодолел и пишешь свои прошивки, то ты прекрасно знаешь, как у тебя изменился уровень контроля.

Уровень контроля можно долго повышать. Кто-то умеет писать прошивки, а кто-то — микрокод для процессоров. Кто-то умеет проектировать процессоры. А если продолжать этот ряд, то в какой-то момент всё упрётся в ограничения физической реальности, которые не получается контролировать. В какой момент будет разумно остановиться и сказать, что контроля достаточно?

Зачем начальному загрузчику tcp/ip? Почему этим не может заниматься прикладной софт, который установит пользователь по своему желанию?

Потому что может быть некуда устанавливать этот прикладной софт. У компьютера может не быть жёсткого диска. Или этот жёсткий диск может не содержать прикладной софт, а самой целью сетевой загрузки будет как раз установка прикладного софта на него.

Раньше приходилось по гораздо более ограниченным протоколам (BOOTP и TFTP) раздавать 16-битный код, который по-разному работал на разных BIOS’ах. Через TFTP долго и небезопасно тащить большой образ ОС в память (количество которой опять же будет зависеть от конкретной платформы), а загрузчик, встроенный в сетевую карту ничего не знает про Linux, поэтому обычно раздавали промежуточный загрузчик, который знает и про Linux, и про TCP/IP. Но поскольку он работает в плохоспецифицированном realmode окружении, приходилось использовать различные хаки и костыли. Интерфейс загрузчика сетевой карты тоже расчитывал на realmode, и не всегда переживал переход в PM и обратно, поэтому существовала возможность встроить в промежуточный загрузчик драйвер для сетевой карты.

Теперь всё это не нужно. Достаточно положить внутрь ядра Linux EFISTUB и раздать его по HTTP. Остальное уже готовая прошивка сделает сама.

Вроде, ты в начале говорил, что «универсальность» избавляет от «не завезли».

На другом этапе избавляет, который происходит до загрузки ОС.

Как будто с uefi не так.

UEFI не может решить все проблемы. ACPI никуда не делся.

что конкретный «универсальный» efi работает только с конкретным программно-аппаратным окружением

Да, потому что системная прошивка распространяется вместе с материнской платой, которая поддерживает ограниченный набор процессоров.

Но это не мешает остальным железкам научить универсальный UEFI использовать их для загрузки ОС.

Например, контроллер NVMe может научить UEFI использовать себя в качестве блочного устройства.

И будет содержать бинари для всех возможных платформ? Универсально или уникально?

обманывать ОС, представляя новое железо старым

Это уже давно умеет прикладное ПО - эмуляторы, виртуальные машины. Так и скажи, теперь в прошивке - ОС с виртуализацией устройств. ОС с виртуализацей на ОСи с виртуализацией ОСью с виртуализацией погоняет. Платите ваши денежки за наши капризы гигабайты ПЗУ.

Достаточно положить внутрь ядра Linux EFISTUB

Не надо превращать закуску в еду начальный загрузчик в «ПЗУ типа жесткий диск». Пусть начальный загрузчик грузит с ПЗУ (флеш, жд и тп) прикладную программу для этого, который может установить производитель.

системная прошивка распространяется вместе с материнской платой, которая поддерживает ограниченный набор процессоров.

И ограниченный набор (из одной) ОС (конкретной версии). «Универсально».

У uefi один плюс: он заставляет производителей пускать в свой универсум. Вот они и пустили и сразу же закрылись жесткой привязкой к id’шникам и secureboot.

Статьи про UEFI

На хабре Николай Шлей aka CodeRush писал цикл статей про безопасность UEFI. Вот список его статей https://m.habr.com/ru/users/CodeRush/posts/

P.S. На конференции оверов он является модератором ветки о модификации BIOS/UEFI

И будет содержать бинари для всех возможных платформ? Универсально или уникально?

Или содержать бинари для всех возможных платформ, или использовать байткод (EBC).

Пусть начальный загрузчик грузит с ПЗУ (флеш, жд и тп) прикладную программу для этого, который может установить производитель.

Так тоже можно сделать. Но для этого нужно сначала прошить флеш, разметить жд, выполнить какие-то подготовительные операции, требующие наличия ещё одного работающего компьютера.

В случае с UEFI производитель уже всё сделал за меня. Впрочем, как и в non-UEFI системах, просто ограничений стало меньше. И костыли для обхода этих ограничений современным ОС стали не нужны.

Как предлагаете сделать сетевую загрузку простой, если в компьютере нет ни одного диска? Скажем, я пошёл в магазин, купил Intel NUC и оперативную память к нему, а теперь хочу сделать из него бездисковый терминал с загрузкой по сети. Как должна работать правильная системная прошивка, если я хочу загрузить ядро+initramfs с удалённого сервера?

И ограниченный набор (из одной) ОС (конкретной версии).

Почти во всех реализациях UEFI есть CsmCore, который позволяет эмулировать сервисы BIOS для тех ОС, которые про UEFI ничего не знают. И можно запускать ОС, которые про UEFI знают. В чём ограничение? Вы можете написать свою ОС, определённым образом структурировав ядро или загрузчик.

Вот они и пустили и сразу же закрылись жесткой привязкой к id’шникам и secureboot.

Кто от кого закрылся? Код, реализующий PCI ID whitelisting, был и в монолитных legacy BIOS. Из UEFI выкинуть такой код гораздо проще, благодаря модульности.

Secure Boot с настройками по-умолчанию вообще довольно бесполезен. Его нужно либо выключить, либо загрузить туда свои собственные ключи. Тогда он начнёт работать на владельца машины, мешая злоумышленнику закрепиться в системе.

Не понимаю, в чём именно претензии к универсальности, если сравнивать legacy BIOS и UEFI. Раньше был неуниверсальный монолит, который давал примерно те же возможности, что и сейчас, но требовал пачки костылей и хаков для обхода ограничений. Сейчас есть модульный UEFI, где костыли можно не использовать, а ограничения сильно подняты.

Или то, что legacy BIOS позволял (после некоторых страданий) запихнуть в себя стек TCP/IP и грузить системы по сети это тоже плохо?

Но для этого нужно сначала прошить флеш

Прошивку прошивать не надо?

Я тебя сейчас вообще не понимаю: второй компьютер (програмно-аппаратный комплекс) плохо, а прошивальщик (программно-аппаратный комплекс) - хорошо. Почему разное отношение к программно-аппаратным комплексам?

Почему производитель может прошить прошивку, но не может прошить прошивку с простой unix-way прикладной программой для единственной задачи или с несколькими?

Почти во всех реализациях UEFI есть CsmCore

В большинстве современных биос для ноутбуков (и тп устройств) нет legacy. И там на заводе установлен оффтоп определенной версии с жестко прописанными dsdt для конкретной версии. И онтопику приходится притворятся, что он оффтопик, чтобы устройства работали в полноценном режиме.

Я не эксперт по рынку, но думаю продажи ноутов и тп техники значительно превышает настольные системы.

Secure Boot с настройками по-умолчанию вообще довольно бесполезен.

Поэтому он насильно включен в основной массе. Для кого бесполезен: для уникального вендора или для универсального пользователя?

Не понимаю, в чём именно претензии к универсальности

Универсальность не достигается сваливанием всего в одну кучу (пусть даже размеченную, чтобы маскировать монолитность). Одну кучу сменили на другую - разноцветную.

Я тебя сейчас вообще не понимаю: второй компьютер (програмно-аппаратный комплекс) плохо, а прошивальщик (программно-аппаратный комплекс) - хорошо. Почему разное отношение к программно-аппаратным комплексам?

Это разные сценарии. В одном пользователь является производителем программно-аппаратного комплекса. Покупает general-purpose PC по частям, и специализирую его для своей задачи. Тут все средства хороши — можно и с прошивальщиком поковыраться, и coreboot пособирать, и модули UEFI рекомбинировать. В итоге получится то, что хорошо решает его задачу.

Есть другой сценарий. В нём есть предприятие, которое не хочет тратить средства на ковыряние с железом, а вместо этого хочет получить готовый компьютер, который ведёт себя предсказуемо — хорошо интегрируется во внутреннюю инфраструктуру (нужны загрузка по сети, удалённая аттестация, управление, диагностика, secure boot), запускает старый софт (на него уже куплены лицензии, обучены сотрудники).

И ещё один сценарий. Домашний пользователь, который не хочет ничего ни про какие биосы/уефи знать. Иногда хочет апгрейдить своё железо — новую железку воткнуть, и не думать про совместимость с прошивками и ОС, а чтобы оно само взяло и заработало.

Во втором сценарии программаторы приемлимы, но нежелательны — не для того бизнес деньги платил производителю, чтобы напильником дорабатывать потом ещё его железо. На это пойдут только в крайнем случае.

В третьем сценарии у пользователя может не быть ни программатора, ни второго компьютера для генерации образов системной прошивки, ни желания и знаний про всё это. Надо чтобы само хоть как-нибудь работало, а что там внутри — не важно. Но желательно, чтобы ОС была похожей на ту, что на прошлом компьютере — привык к кнопочкам на своих местах и не хочет переучиваться.

Почему производитель может прошить прошивку, но не может прошить прошивку с простой unix-way прикладной программой для единственной задачи или с несколькими?

Может. Тогда вместо general-purpose PC получится программно-аппаратный комплекс, решающий единственную задачу. И продавать он его будет, как специализированное устройство. Для этого устройства никто не обещает работу различных ОС, различных карт расширения, поэтому простая прошивка отлично подойдёт для такого специализированного компьютера.

В большинстве современных биос для ноутбуков (и тп устройств) нет legacy.

Если так, то видимо моё представление о рынке устарело. Из последнего, что я видел — в HP EliteBook 735 G5 есть и legacy-режим (CSM), и secure boot настраивается как угодно, и линуксы работают всякие.

Буду внимательнее при покупке устройств, спасибо за предупреждение.

И онтопику приходится притворятся, что он оффтопик, чтобы устройства работали в полноценном режиме.

Это проблемы кривого DSDT. Они как в legacy BIOS были, так в UEFI и остались. Увы, это следствие недостаточного тестирования. «Надо скорее выпускать на рынок сырое устройство, критические проблемы потом как-нибудь починим апдейтами.»

Но и тут UEFI лучше. :) Если малоквалифицированный специалист полезет в монолитный legacy BIOS, то он с большей вероятностью накосячит. А в модульной системе UEFI можно использовать гораздо более популярные и современные средства разработки и тестирования.

Одну кучу сменили на другую - разноцветную.

Но раньше была однородная масса, в которую ОС/загрузчикам/OpROM приходилось наугад тыкать палочкой, смотреть на реакцию и подстраивать своё поведение.

А сейчас есть разноцветная куча, в которой красные куски точно будут, и будут строго определённой формы (UEFI специфицирует протоколы), поэтому гадать больше не нужно.

Раньше надо было ужиматься в сотни байт и делать многостадийные загрузчики, помнить про особенности 16-битной архитектуры, жонглировать режимами работы процессора и таблицами трансляции, писать программы, которые патчат программы, а сейчас можно используя современные языки и компиляторы написать мегабайты кода, используя при этом готовые драйвера для работы с консолью/дисками/сетью/фс. Работа системного программиста становится проще, причём во всех областях — разработка системной прошивки, OpROM карты расширения, загрузчика или ядра ОС.

Intel прекращает поддержку BIOS

А она разве поддерживала? Тогда в чем заключалась поддержка?

Поддержку BIOS осуществляет ядро Linux и загрузчик GRUB.

Владимир

Это те же люди что несколько лет назад кричали что btrfs depricated, а потом стали предлагать устанавливаться не неё? Пофигу, пускай выпиливают что хотят, все равно их поделками мало кто пользуется.

640k хватит для всего! Ваш К.О.