Комментарии 144
Т.е. вскоре о BIOS можно будет забыть?
Я уже забыл. У меня все диски в GPT и загрузка только UEFI. В целом, проблем меньше и работает быстрее.
работает быстрее
Вы имеете в виду ОС стартует быстрее или в процессе работы быстрее?
На счет меньше проблем зря вы так, UEFI добавляет головняка, его проще выключить и забыть чем настроить и действительно полноценно использовать его функционал.
Загружается быстрее, работает так же.
UEFI мне не добавила проблем, может быть, только при самой первой установке. Secure Boot мой лаптоп не поддерживает, это вот с ним нужно немного повозиться, а обычная UEFI-загрузка, по-моему, проще BIOS-загрузки, создал FAT32 раздел, кинул туда загрузчик или ядро, и забыл.
UEFI мне не добавила проблем, может быть, только при самой первой установке. Secure Boot мой лаптоп не поддерживает, это вот с ним нужно немного повозиться, а обычная UEFI-загрузка, по-моему, проще BIOS-загрузки, создал FAT32 раздел, кинул туда загрузчик или ядро, и забыл.
«создал FAT32 раздел»
т.е. для загрузки установщика Windows в режиме UEFI с флешки или USB харда при размере install.wim > 4GB нет вариантов? Или возможно использовать дополнительные сторонние загрузчики, «понимающие» NTFS?
т.е. для загрузки установщика Windows в режиме UEFI с флешки или USB харда при размере install.wim > 4GB нет вариантов? Или возможно использовать дополнительные сторонние загрузчики, «понимающие» NTFS?
Не могу ответить, не знаю. Возможно, можно создать FAT32 и NTFS, на фате будет только загрузчик, а на нтфс остальные файлы.
FAT должен пониматься UEFI firmware изначально, без использования дополнительных драйверов. Если очень надо работать с файловыми системами из UEFI, то можно загрузить дополнительные драйвера для этого.
Но на практике это не нужно — проще загрузить уже ядро операционной системы, и получить уже и поддержку многозадачности, защиту памяти и т.п.
Но на практике это не нужно — проще загрузить уже ядро операционной системы, и получить уже и поддержку многозадачности, защиту памяти и т.п.
Поддержка файловых систем «в ногу со временем» получается. Хорошая идея была, но танцы, видать, всегда заранее в стандарты закладывают.
Разницы в скорости работы и загрузки между GPT и MBR на ноуте с SSD не вижу. Загрузка происходит одинаково мегабыстро. Однако на ноуте предпочитаю полностью шифровать диск. TryeCrypt, к сожалению, не обновлялся более года(забросили его что ли?) и полная поддержка 8-ки, а также GPT на UEFI системах до сих пор числится в будущих планах, а не в реализованном. Поэтому сижу на MBR.
Совсем забыть про BIOS получится пока только у обладателей оборудования с UEFI-совместимыми прошивками и отсутствием необходимости legacy-загрузки из MBR или с внешних устройств. Они могут отключить Compatibility Support Module совсем, после чего всем оборудованием вроде RAID/USB/SATA/Ethernet-контролеров начнут управлять драйверы UEFI, а не старые модули BIOS из CSM.
На некоторых платах можно выбрать, какая именно прошивка будет использоваться для вышеперечисленных контролеров, но на ноутбуках я такого пока не встречал.
UEFI GOP firmware есть «из коробки» на встроенных в SB/IB/Haswell графических картах Intel, а также на некоторых картах Nvidia 6xx и 7xx и ATI 7xxx. Вообще, тема UEFI достаточно интересная и там можно многое написать.
Если кому-то интересно, могу написать обзор формата файла EFI Capsule, типов используемых файлов и особенностях их модификации.
Заодно и пару полезных в хозяйстве патчей можно будет обсудить.
На некоторых платах можно выбрать, какая именно прошивка будет использоваться для вышеперечисленных контролеров, но на ноутбуках я такого пока не встречал.
UEFI GOP firmware есть «из коробки» на встроенных в SB/IB/Haswell графических картах Intel, а также на некоторых картах Nvidia 6xx и 7xx и ATI 7xxx. Вообще, тема UEFI достаточно интересная и там можно многое написать.
Если кому-то интересно, могу написать обзор формата файла EFI Capsule, типов используемых файлов и особенностях их модификации.
Заодно и пару полезных в хозяйстве патчей можно будет обсудить.
Если кому-то интересно, могу написать обзор формата файла EFI Capsule, типов используемых файлов и особенностях их модификации.
Пишите, естественно!
Написал первую часть, вот она.
Вторую напишу в ближайшее время.
Вторую напишу в ближайшее время.
А есть какой-то профит от отключения режима совместимости?
Неистово голосую «за», напишите пожалуйста! Я что-то понимаю отдаленно, не моя область, но очень интересно!
Пишите! Тема актуальная, интересная, только, фактически, начала развиваться. Нам всем с этим жить не год и не два теперь. Врага надо знать в лицо.
Думаю написать статью про TPM и про Trusted Boot. Интересно?
Если UEFI описан стандартом (Intel к делу руку приложил, если не ошибаюсь), то почему подпись то нужна от M$?
Чтобы проблем меньше было. Ключики MS встраивают большинство, хотя я думаю все, OEM-производители лаптопов и десктопных материнок. А договориться с OEM-производителями для включения их ключей, каждому дистрибутиву просто нереально. Была идея сделать «общий» ключ FSF, но от нее быстро отказались. Шумиха была из-за того, что было мало информации, и все думали, что либо Secure Boot будет неотключаемый, либо ключи нельзя будет заменить. А сейчас, подписанные майкрософтовским ключом пре-загрузчики нужны, в основном, для запуска дистрибутива с флешки или болванки, чтобы не лезть в настройки UEFI и не выключать на время Secure Boot.
Ведь такое положение вещей дискредитирует саму идею подписывания ключами и находится где-то на одном уровне с подписанными mail.ru даунлоадерами, скачивающими трояны.
Не совсем, ибо перед использованием надо ключ добавить в локальную базу UEFI, т.е. по сути — в ручную.
Вопрос только в том, где эта локальная база хранится и насколько хорошо она зашифрована.
Не скажу наверняка, у меня нет платы с поддержкой SecureBoot в данный момент, но скорее всего хранится эта база в регионе BIOS в той же самой микросхеме, а зашифрована либо никак либо практически никак.
Буду рад ошибаться, но по опыту работы с UEFI мнение складывается именно такое.
Не скажу наверняка, у меня нет платы с поддержкой SecureBoot в данный момент, но скорее всего хранится эта база в регионе BIOS в той же самой микросхеме, а зашифрована либо никак либо практически никак.
Буду рад ошибаться, но по опыту работы с UEFI мнение складывается именно такое.
Печально как то получается в таком случае. Тоже не особо разбираюсь в технологии, однако сомневаюсь, что ключи можно легко переписать чем то сторонним.
А какой смысл шифровать базу открытых ключей? Защитить от модификации (MAC, HMAC) — да, нужно, хотя врятли её дадут просто так перезаписать. Но шифровать-то зачем?
Насколько я слышал, UEFI облегчило жизнь хакинтошникам (на совместимых чипсетах), меньше проблем с чипсетом, драйверами, и железом, всё ставится почти нативно как на родную.
Это правда?
Как хакнутая Mac OS загружается, если UEFI должен этому помешать? На мою мать (X79, ASUS Sabertooth) умелец поставил оригинальный образ Mac OS, добавив в него лишь один файл .kext и потом после установки пошаманил что-то насчет видюхи только, чтобы ускорение заработало. Остальное «из коробки» заработало. (аудиокарта у меня внешняя USB)
Как так? Зачем UEFI и подписи?
Это правда?
Как хакнутая Mac OS загружается, если UEFI должен этому помешать? На мою мать (X79, ASUS Sabertooth) умелец поставил оригинальный образ Mac OS, добавив в него лишь один файл .kext и потом после установки пошаманил что-то насчет видюхи только, чтобы ускорение заработало. Остальное «из коробки» заработало. (аудиокарта у меня внешняя USB)
Как так? Зачем UEFI и подписи?
Secure Boot — это опциональный механизм защиты от запуска неподписанного кода, на старых компьютерах его либо нет, либо он идёт отключенным по-умолчанию (например, на Dell OptiPlex с Windows 7 или Ubuntu).
Чипсет X79 — он как-бы не старый! Официально он до сих пор топовый из топовых в линейке Intel на десктоп, хоть и не самый новый, согласен.
Но десктопно Xeon, да еще и 6-ти ядерные только под этот чипсет и идут.
Вот планок памяти там дофига намудрили, мне чтобы 4 (из 8 возможных) планки поставить и при этом радиатором планки кулер OCZ не задевать, пришлось 16 гиг поставить на домашний-то комп.
Хотя сейчас не жалею конечно, памяти — завались!
Но десктопно Xeon, да еще и 6-ти ядерные только под этот чипсет и идут.
Вот планок памяти там дофига намудрили, мне чтобы 4 (из 8 возможных) планки поставить и при этом радиатором планки кулер OCZ не задевать, пришлось 16 гиг поставить на домашний-то комп.
Хотя сейчас не жалею конечно, памяти — завались!
Я ничего не знаю про маки, так что не смогу ответить вам на этот вопрос. Вообще, UEFI нужна потому, что BIOS — жуткое старье и уже ограничивает современные компьютеры, например, код BIOS можно писать только на ассемблере и он выполняется в 16-битном режиме процессора, в то время, как UEFI написан на C и выполняется в 64-битном режиме. А Secure Boot это так, приятное дополнение.
Ну в последних бздохах ami8 уже имел USB подсистему написанную на C и выполняющуюся в 32битном режиме. Но это был костыль приделаный к другому костылю третьего костыля. Про award я лучше промолчу, топик могут читать дети, а кроме матершины в голову ничего не лезет.
То, что BIOS — жуткое старьё, не говорит о том, что UEFI (ещё более громоздкая надстройка) нужна.
В наше время всё может выполнить сама операционная система. Input/Output System (кроме той, что уже есть в ОС) ей не нужна, ни в каком виде.
Настоящее будущее это Coreboot. UEFI — навязанный зонд, и непонятно, почему вы его так защищаете. Он хуже всего, на что можно было перейти с BIOS. Смысл был в том, чтобы уменьшить функции загрузчика до минимума и Coreboot, в отличие от UEFI, этому идеально соответствует.
В наше время всё может выполнить сама операционная система. Input/Output System (кроме той, что уже есть в ОС) ей не нужна, ни в каком виде.
Настоящее будущее это Coreboot. UEFI — навязанный зонд, и непонятно, почему вы его так защищаете. Он хуже всего, на что можно было перейти с BIOS. Смысл был в том, чтобы уменьшить функции загрузчика до минимума и Coreboot, в отличие от UEFI, этому идеально соответствует.
Нет. С помощью одного только coreboot вы операционку не загрузите.
Почему это не загрузим?
Потому, что coreboot слишком прост для этого. Всё, что он может — это загрузить payload (с реализацией интерфейса BIOS или UEFI, например), который уже достаточно функционален, чтобы загрузить ОС.
Говорить, что «UEFI не нужен, так как есть Coreboot» — это всё равно, что утверждать «автобус не нужен, потому, что есть колесо».
Говорить, что «UEFI не нужен, так как есть Coreboot» — это всё равно, что утверждать «автобус не нужен, потому, что есть колесо».
> Всё, что он может — это загрузить payload (с реализацией интерфейса BIOS или UEFI, например), который уже достаточно функционален, чтобы загрузить ОС.
Ах, вы в этом смысле.
Ах, вы в этом смысле.
Вот именно поэтому вы ошибаетесь. Linux может непосредственно быть payload для coreboot. Т.е. непосредственно coreboot загрузит операционную систему.
Linux откуда угодно можно загрузить. Разговор же идёт о загрузке операционной системы вообще, а не только одного только Linux'а.
Линукс — это вполне себе операционка. То, что отдельные представители не грузятся на Coreboot, вовсе не означает, что на нем загрузиться невозможно.
Справедливости ради надо сказать, линукс как раз и есть та единственная операционка, которая грузится coreboot без промежуточных пайлоадов. Что, тем не менее, не отменяет того факта, что такая операционка есть, и значит вывода, что coreboot в принципе достаточно продвинут, чтобы быть способным загрузить операционку общего назначения непосредственно (например, эту), была бы операционка достаточно продвинутая.
P.S. Никаких внешних загрузчиков не было, гарантирую, файл добавлялся в тот образ, что я в официальном магазине приложений с легального компа купил за 30 баксов.
И кстати, я обманул — сейчас вспомнил, он добавил два кекса, второй был для сетевой карты, чтобы заработала. В остальном оригинальный образ и оригинальный загрузчик.
И кстати, я обманул — сейчас вспомнил, он добавил два кекса, второй был для сетевой карты, чтобы заработала. В остальном оригинальный образ и оригинальный загрузчик.
Это правда.
При использовании хорошего загрузчика, вроде Clover, для нормальной работы OS X на типичном современном железе (за исключением X79, у которого проблемы с поддержкой CPU power management, и Z87 по причине его новизны) нужна установка всего пары кекстов.
Как минимум, это FakeSMC.kext и драйверы для оборудования вроде встроенного Ethernet.
Наличие UEFI, кстати, для нормальных загрузчиков не обязательно, они эмулируют среду EFI для OS X. Более того, очень часто бывает, что в UEFI имеются ошибки и несовместимости с Apple EFI, отчего одна и та же система может лучше работать с legacy-загрузкой, чем с UEFI.
Есть небольшая проблема с поддержкой CPU power management в OS X на всех современных платах, кроме плат Gigabyte, которая решается либо патчем БИОСа, либо патчем кекста, либо установкой другого кекста взамен стандартного.
Я предпочитаю первый способ, для чего написал утилиту PMPatch.
При использовании хорошего загрузчика, вроде Clover, для нормальной работы OS X на типичном современном железе (за исключением X79, у которого проблемы с поддержкой CPU power management, и Z87 по причине его новизны) нужна установка всего пары кекстов.
Как минимум, это FakeSMC.kext и драйверы для оборудования вроде встроенного Ethernet.
Наличие UEFI, кстати, для нормальных загрузчиков не обязательно, они эмулируют среду EFI для OS X. Более того, очень часто бывает, что в UEFI имеются ошибки и несовместимости с Apple EFI, отчего одна и та же система может лучше работать с legacy-загрузкой, чем с UEFI.
Есть небольшая проблема с поддержкой CPU power management в OS X на всех современных платах, кроме плат Gigabyte, которая решается либо патчем БИОСа, либо патчем кекста, либо установкой другого кекста взамен стандартного.
Я предпочитаю первый способ, для чего написал утилиту PMPatch.
Проблемы есть. Частота проца не меняется осью, а видюха постоянно работает на максимуме, как если в крайзис рубишься. Есть решения, но я не заморачивался… Но сейчас что-то опять интерес проснулся, уже чисто исследовательский. )))
Частота не меняется потому, что это X79. Решения есть, но пока они недостаточно хороши.
По поводу GPU power management — тут я подсказать не могу, HD3000 работает исправно.
Если исследовательский интерес действительно есть, присоединяйтесь к профильным сообществам вроде AppleLife и InsanelyMac и исследуйте на здоровье.
По поводу GPU power management — тут я подсказать не могу, HD3000 работает исправно.
Если исследовательский интерес действительно есть, присоединяйтесь к профильным сообществам вроде AppleLife и InsanelyMac и исследуйте на здоровье.
Про сетевую я чуть раньше вспомнил вашего коммента. По ссылке перешел на знакомый сайт, я туда заходил когда-то, теперь знаю кого в личку трясти если что ))
P.S. А вот левых загрузчиков точно не было, нативно грузилось, поставил на SSD, на полке лежит, сейчас подключу, ох блин )
P.S. А вот левых загрузчиков точно не было, нативно грузилось, поставил на SSD, на полке лежит, сейчас подключу, ох блин )
Не верю. Либо загрузчик запускается в тихом режиме и вы его не видите, либо он модифицирован.
А насчет лички — без проблем, но помните, я не настоящий сварщик и каску нашел на стройке. :)
Для меня OS X — не основная, и даже не второстепенная ОС, поэтому и разбираюсь я в ней соответственно.
Благо в сообществе есть более опытные участники, которые помогут, если правильно попросить.
А насчет лички — без проблем, но помните, я не настоящий сварщик и каску нашел на стройке. :)
Для меня OS X — не основная, и даже не второстепенная ОС, поэтому и разбираюсь я в ней соответственно.
Благо в сообществе есть более опытные участники, которые помогут, если правильно попросить.
> в то время как MBR поддерживает без костылей только 4.
это неправда
это неправда
Автор ещё не упомянул о принципиально важной фиче (U)EFI:
BIOS был 16-битным. А это проблемы со «свежестью» компиляторов, с поиском программистов для этого режима, с написанием и отладкой firmware, с производительностью, переносимостью и т.п.
UEFI же работает в «родном» для процессора режиме, ему доступны все гигабайты оперативной памяти компьютера, внутреннее API хорошо документировано и т.п.
В результате можно написать приложение, которое будет работать в графике и поддерживать мышь. Причём будет работать и на Apple и на PC, тот же самый бинарник, и всё это — до запуска операционной системы.
BIOS был 16-битным. А это проблемы со «свежестью» компиляторов, с поиском программистов для этого режима, с написанием и отладкой firmware, с производительностью, переносимостью и т.п.
UEFI же работает в «родном» для процессора режиме, ему доступны все гигабайты оперативной памяти компьютера, внутреннее API хорошо документировано и т.п.
В результате можно написать приложение, которое будет работать в графике и поддерживать мышь. Причём будет работать и на Apple и на PC, тот же самый бинарник, и всё это — до запуска операционной системы.
Это да, я об этом в комментарии написал
Ну это полный бред. BIOS начиная с первых четверок был 32 разрядным, по крайней мере никто не брезговал юзать 32-битные команды. И когда он например память пишет системную он работает в протект моде если что. Кстати, 16-битное не обязательно плохо. Иногда 16-битное работает быстрее, чем 32-битное (ибо сами опкоды меньше, а это значит меньше кеш засирается хотя-бы). Биос совмещает и 16 битные и 32 битные команды.
Хехе, память он тестирует не в протектед, а unreal mode или flat mode или voodoo mode, кто его только как не называл.
… чтобы включить который нужно временно перейти в защищённый режим.
Хотя, как пишут на osdev, сам x86-процессор стартует с адреса 0xfffffff0, который в реальном режиме недоступен. Другими словами, машина изначально запускается как бы в unreal mode.
Кроме того, больше 4 гб памяти в этом режиме не протестируешь. А если её 32 Гб в машине?
Хотя, как пишут на osdev, сам x86-процессор стартует с адреса 0xfffffff0, который в реальном режиме недоступен. Другими словами, машина изначально запускается как бы в unreal mode.
Кроме того, больше 4 гб памяти в этом режиме не протестируешь. А если её 32 Гб в машине?
А тут вступает в дело ещё один мегакостыль в ами висящий отдельным модулем (MemoryOver4GbTest). Брррр, боюсь представить что сделали в аварде.
Да и забавный факт в том, что этот unreal mode какбы баг и недокументированная фича у интела =)
Да и забавный факт в том, что этот unreal mode какбы баг и недокументированная фича у интела =)
Не баг и вполне документированная фича. Документировано следующим образом: при смене режима (например, mov cr0,ax) и при загрузке сегментных регистров в реальном режиме (mov ds,bx) в кэше дескриптора меняются не все поля. Документировано, если не ошибаюсь, начиная с пентиума.
А появилось с 386го =) И уже там активно юзалось AMI =)
Ну это больше похоже на то, что забыли документировать. Потом просто исправили ошибку.
Сравните с LOADALL, которая не была документирована, было две версии — 286 и 386, последняя в 486 была доступна только в SMM режиме, а в пентиуме и далее её вообще убрали. Однако тоже юзалась, пока была.
Сравните с LOADALL, которая не была документирована, было две версии — 286 и 386, последняя в 486 была доступна только в SMM режиме, а в пентиуме и далее её вообще убрали. Однако тоже юзалась, пока была.
Откройте код современного BIOSа, откопайте обработчик unknown opcode и насладитесь эмуляцией LOADALL, она даже на кор2дуровских семействах есть. Хотя кроме himem и os/2 её мало что юзало, а то, что юзало уже давно мертво и закопано. Интел блюдет совместимость однако
и неограниченное количество разделов
Стоять, как это «неограниченное количество»? Там ограничение в 128 разделов. Даже на схеме это хорошо видно.
Ну это по умолчанию, можно и больше сделать.
НЛО прилетело и опубликовало эту надпись здесь
Подскажите чайнику, как будут именоваться диски после окончания алфавита? х_х
А не надо использовать ограниченные ОСи ;) На самом деле, NTFS начиная с Windows 2000 поддерживает volume mount points, или по-русски — возможность монтировать диск в папку на другом диске, как в UNIX-like ОСях. Т.е. можно иметь 128 разделов, и «всего» один том «C:», а всё остальное будет доступно как папка, например, C:\Users уже может быть другим разделом.
У возможности добавления своих устройств в список загрузочных есть обратная сторона.
Эти добавочные строки хранятся в 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 вредоносным кодом в данный момент.
Надо и про это тоже писать отдельную статью, наверное.
Эти добавочные строки хранятся в 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 вредоносным кодом в данный момент.
Надо и про это тоже писать отдельную статью, наверное.
Так SecureBoot и позволяет защититься от подмены загрузчика. Но, в целом, вы правы, пока некоторые реализации UEFI хромают.
Скажем так, в данный момент все реализации UEFI, доступные конечному пользователю, хромают на обе ноги, и не только в плане безопасности.
Что у Phoenix, что у AMI баги висят месяцами и переживают по 3-6 обновлений, пока их удается локализовать и исправить. А в новых версиях стабильно вылезают новые. Когда ситуацию станет лучше — непонятно, но пока — вот так.
Лучшая реализация безопасности UEFI на десктопных платах была у Intel, но они перестали их выпускать.
Что у Phoenix, что у AMI баги висят месяцами и переживают по 3-6 обновлений, пока их удается локализовать и исправить. А в новых версиях стабильно вылезают новые. Когда ситуацию станет лучше — непонятно, но пока — вот так.
Лучшая реализация безопасности UEFI на десктопных платах была у Intel, но они перестали их выпускать.
Когда ситуацию станет лучше — непонятно, но пока — вот так.
У тайваньцев — никогда, они даже PXE толком не осилили. У Dell в корпоративных сериях уже есть нормальная реализация, думаю, что и HP с Lenovo не отстают.
И Phoenix, и InsydeH2O, которые как раз и используюся Dell, HP и Lenovo — нисколько не менее глючные. Про новые Dell с UEFI 2.3.1C и SecureBoot сказать ничего пока не могу — не сталкивался, а вот на старых багов не меньше, если не больше, чем на десктопных AMI, и чинят их также крайне неохотно. Но хотя бы белых списков оборудования Dell не вводит и файлы BIOS Update не шифрует, как это делают HP и Lenovo.
Только за одни белые списки, из за которых каждую новую версию БИОСа приходится модифицировать и шить нестандартными способами, я больше никогда решения ни HP ни Lenovo не куплю, пусть там UEFI хоть каким отличным будет. Оборудование и так делают все более закрытым, а чтобы какой-то кореец решал, какие 3G-модем и WiFi-карту я могу поставить в свой ноутбук, а какие нет — увольте.
Только за одни белые списки, из за которых каждую новую версию БИОСа приходится модифицировать и шить нестандартными способами, я больше никогда решения ни HP ни Lenovo не куплю, пусть там UEFI хоть каким отличным будет. Оборудование и так делают все более закрытым, а чтобы какой-то кореец решал, какие 3G-модем и WiFi-карту я могу поставить в свой ноутбук, а какие нет — увольте.
Я добавлю по X79 — у меня на Asus Sabertooth есть отдельный порт USB 2.0 на задней панели, отмеченный белым.
В теории, если ВСЁ УМЕРЛО, ПОЛНЫЙ КОЛЛАПС ВСЕХ СИСТЕМ, и вообще ниче не происходит… особенно после неудачной перепрошивки, что наверное невозможно, Но.
Надо на другом компе на флешку закачать некие бинарники «образцово-показательные» с сайта в корень флешки, потом просто воткнуть эту флешку в белый разъем и включить питание. Если питание на материнке есть — все будет хорошо.
В описании так это описано, как некий «предбутовый всего и вся» загрузчик, самопрошивальщик себя на материнке.
На практике не проверено, но охотно верю по описаниям, что это правда.
В теории, если ВСЁ УМЕРЛО, ПОЛНЫЙ КОЛЛАПС ВСЕХ СИСТЕМ, и вообще ниче не происходит… особенно после неудачной перепрошивки, что наверное невозможно, Но.
Надо на другом компе на флешку закачать некие бинарники «образцово-показательные» с сайта в корень флешки, потом просто воткнуть эту флешку в белый разъем и включить питание. Если питание на материнке есть — все будет хорошо.
В описании так это описано, как некий «предбутовый всего и вся» загрузчик, самопрошивальщик себя на материнке.
На практике не проверено, но охотно верю по описаниям, что это правда.
Такое реализовано практически везде, просто многие не документируют.
Называется эта технология USB BIOS Flashback и есть она только у ASUS, только на топовых платах X79, Z77 и Z87 (и на Maximus IV Extreme на Z68), и работает только с регионом BIOS. От повреждения (намеренного или случайного, не важно) других регионов она не защищает и после разрушения дескриптора восстановить ей БИОС не получится, проверено не одни раз.
Intel Desktop Boards умеют восстанавливаться с любых носителей, а благодаря наличию legacy режима им не страшны повреждения Descriptor и NVRAM.
Не только, у Gigabate вообще есть Dual Bios, который в случае фейла ругнётся, и автоматически вернёт резервную копию.
Тоже вариант, и намного лучше, чем UBF.
Под «только у ASUS» я имел в виду не отсутствие средств восстановления у других производителей, а отсутствие у них именно описанного в посте Lincoln6Echo метода с USB-носителем и кнопкой на задней панели. Неудачно выразился, прошу меня простить.
Отличительной особенностью технологии USB BIOS Flashback является возможность прошивки BIOS'а без процессора и оперативной памяти. Нужны только дежурное питание, FAT32 USB-носитель с правильно названным файлом BIOS'а и поддержка этой технологии со стороны платы.
Под «только у ASUS» я имел в виду не отсутствие средств восстановления у других производителей, а отсутствие у них именно описанного в посте Lincoln6Echo метода с USB-носителем и кнопкой на задней панели. Неудачно выразился, прошу меня простить.
Отличительной особенностью технологии USB BIOS Flashback является возможность прошивки BIOS'а без процессора и оперативной памяти. Нужны только дежурное питание, FAT32 USB-носитель с правильно названным файлом BIOS'а и поддержка этой технологии со стороны платы.
Да ничего страшного, не берите в голову. Главное что бы из получившегося обсуждения в итоге вышел толк, я вот, к примеру, после прочтения топика и комментариев узнал много нового. В общем — чем больше тут будет информации по теме тем лучше будет для сообщества. Да и вообще, если бы вы не написали свой комментарий, именно так как написали, то не факт, что у кого то возникло бы желание ответить на него в контексте опровержения и (или) явного дополнения. А так получилось, что потихоньку ветка дополняется технологиями от разных производителей, а ведь это чудесно :)
Я прикладной прогер сам довольно долго тупил, пока читал мануалы и гугл, что это за фигня и каков принцип действия, и засем отдельный порт. Нужно только только 5В на порт и все будет хорошо. Мать адская. Надеюсь способ восстановления через «белый» порт мне не пригодится.
Sabertooth X79 ведет себя как очень покладистая характером. А с шестиядрёным Зионом на борту и 16 гигами это капец числомолотика, а не комп. Играя в Крайзис переключаюсь по альт-таб чтобы ответить в скайпе, и потом обратно, и не парюсь, ни лагов ни микрофризов.
Sabertooth X79 ведет себя как очень покладистая характером. А с шестиядрёным Зионом на борту и 16 гигами это капец числомолотика, а не комп. Играя в Крайзис переключаюсь по альт-таб чтобы ответить в скайпе, и потом обратно, и не парюсь, ни лагов ни микрофризов.
Не все так хорошо. Это просто способ для перепрошивки BIOS из винды из юзерского графического интерфейса, и фейлов с этим связанных. + маркетинг.
"… резервная BIOS, при условии целостности Boot-сектора на _жестком_ _диске_, автоматически возьмет управление загрузкой ПК на себя..." тоже как бы намекает.
Второй БИОС там на харде, в особой области, забыл как называется
"… резервная BIOS, при условии целостности Boot-сектора на _жестком_ _диске_, автоматически возьмет управление загрузкой ПК на себя..." тоже как бы намекает.
Второй БИОС там на харде, в особой области, забыл как называется
Нет, это про другое. На платах Gigabyte установлено 2 микросхемы SPI flash и при невозможности старта с основной происходит старт с дополнительной, копирование содержимого дополнительной в основную и старт с основной. Таким образом, пользователю после сбоя достаточно подождать 2 минуты, пока выполняется копирование, и потом выставить свои настройки заново.
Вообще, идея установки на плату нескольких микросхем SPI flash — очень хорошая, жаль, что не все производители это понимают.
Вообще, идея установки на плату нескольких микросхем SPI flash — очень хорошая, жаль, что не все производители это понимают.
А ещё очень забавно было, когда родной жыжабайтовский флешер мне сразу запорол обе прошивки, но это ещё не понятно чей косяк был, мой или флешера.
Собственно ихний механизм автооперделения битой прошивки частенько косячит, ну а если побило бутблок, то финита ля комедия, он вообще не работает.
Кроме того первые реализации были супер веселыми — вторая флешка не обновлялась (хотя поидее должна была после удачного старта перешиться на обновленную версию биоса) при прошивках никогда. Соответственно человек, купивший плату и топовый проц, который платой понимался только после обновления биоса, при неудачном обновлении всеравно получал пищащий овощь вместо компа.
Собственно ихний механизм автооперделения битой прошивки частенько косячит, ну а если побило бутблок, то финита ля комедия, он вообще не работает.
Кроме того первые реализации были супер веселыми — вторая флешка не обновлялась (хотя поидее должна была после удачного старта перешиться на обновленную версию биоса) при прошивках никогда. Соответственно человек, купивший плату и топовый проц, который платой понимался только после обновления биоса, при неудачном обновлении всеравно получал пищащий овощь вместо компа.
ИМХО, лучшая реализация «двойного» БИОСа сейчас у EVGA на новых платах.
Там три разных микросхемы, одна из которых не припаяна, а посажена в ZIF-кроватку.
Никаких хитрых механизмов нет и не нужно, сломалось — щелкнул тумблером, загрузился, щелкнул обратно, прошил новую версию.
И всякие проприентарные прошивальщики они не используют, доверяя прошивку надежному и простому Intel FPT.
Там три разных микросхемы, одна из которых не припаяна, а посажена в ZIF-кроватку.
Никаких хитрых механизмов нет и не нужно, сломалось — щелкнул тумблером, загрузился, щелкнул обратно, прошил новую версию.
И всякие проприентарные прошивальщики они не используют, доверяя прошивку надежному и простому Intel FPT.
Не знаю, откуда в русской версии презентации эти слова про диск, в английской их нет. Да и микросхем там все же две, а восстановление работает без жестких дисков, так что вопросы тут к переводчику, скорее.
С диска он тоже может восстанавливаться. Насколько я помню, если версия биоса на диске новее, чем в резервной флешке (а биос он хранит в HPA), то он восстанавливает оттуда. Только, честно говоря, лично мне не очень нравится подход с HPA.
Имеется ввиду наверное, что при наличии валидного бут-сектора резервный биос сможет загрузить операционку, а не просто инициализировать систему.
На днях стал счастливым (пока что) владельцем ноута ASUS с UEFI и Win8.
При этом с трудом отбился от ненавязчивых предложений продавцов прикупить «расширенную гарантию», а также (отдельно) процедуру «резервного копирования настроек БИОСа на случай слета/переустановки ОСи и т.п.» Напуганный продавцами, придя домой сразу слил «на всякий случай» ключи (КЕК, ПК, ДБ, ДБХ)… Утилиту резервного копирования «всего УЕФИ» не нашел — вшитая в ноут могла только залить новый БИОС, опция сохранения «старого» производителем, видимо, не предусмотрена…
Отсюда вопрос — чем хабрасообщество посоветует создать резервную копию? Попытки загрузиться с флешки при выключенном Secure Boot и CMD не помогли (видимо, флешки уже «не те»)…
При этом с трудом отбился от ненавязчивых предложений продавцов прикупить «расширенную гарантию», а также (отдельно) процедуру «резервного копирования настроек БИОСа на случай слета/переустановки ОСи и т.п.» Напуганный продавцами, придя домой сразу слил «на всякий случай» ключи (КЕК, ПК, ДБ, ДБХ)… Утилиту резервного копирования «всего УЕФИ» не нашел — вшитая в ноут могла только залить новый БИОС, опция сохранения «старого» производителем, видимо, не предусмотрена…
Отсюда вопрос — чем хабрасообщество посоветует создать резервную копию? Попытки загрузиться с флешки при выключенном Secure Boot и CMD не помогли (видимо, флешки уже «не те»)…
В общем случае, для UEFI не требуется ставить загрузчик, если вы хотите мультизагрузку. Можно добавлять свои пункты меню, и они появятся в загрузочном меню UEFI, прямо рядом с дисками и флешками. Это очень удобно и позволяет грузить Linux вообще без загрузчика, а сразу ядро. Таким образом, можно установить Windows и Linux без сторонних загрузчиков.
Немного зануды: это справделиво только для обычных жестких дисков.
Мне тут потребовалось поставить ось с UEFI и BIOS fallback на переносной GPT диск. И поскольку на новом пк не будет всех моих пунктов загрузки с этого диска, пришлось ставить gummiboot как загрузчик в \efi\boot\bootx64.efi. Ну и syslinux для загрузки из BIOS режима. Работает шикарно, проблемы были только почему-то с GRUB, который нехотя поставился для uefi (но потом все равно отвалился), и вообще никак не хотел для BIOS.
«Любой компьютер сертифицированный для Windows 8 обязан иметь возможность отключения Secure Boot».
Ага. ASUS N56VZ (win7, но не суть) — возможность отключить Secure Boot есть, но появилась только путём отката на самую раннюю версию eeprom.
ASUS N76VZ (практически тот же, но 17'' и Win8) — отключение Secure Boot в принципе недоступно
«А зачем отключать?» — а может я форк свой от kolibriOS делаю, например
Ага. ASUS N56VZ (win7, но не суть) — возможность отключить Secure Boot есть, но появилась только путём отката на самую раннюю версию eeprom.
ASUS N76VZ (практически тот же, но 17'' и Win8) — отключение Secure Boot в принципе недоступно
«А зачем отключать?» — а может я форк свой от kolibriOS делаю, например
Посмотрел в доступные настройки BIOS'а N76VZAS.213 на предмет отключения SecureBoot с помощью AMIBCP.
Возможность эта в прошивке есть и должна быть на вкладке Security.
Отображается эта настройка или нет — другой вопрос, конечно.
Возможность эта в прошивке есть и должна быть на вкладке Security.
Отображается эта настройка или нет — другой вопрос, конечно.
Часть скриншота AMIBCP
Честно говоря, про AMIBCP раньше не слышал. Гугл по запросу «ASUS N56VZ disable secure boot» тоже не особо помог на тот момент. Значит, спасибо за информацию, будет у меня теперь свежая прошивка в ноуте :) А настройка да, в bios не отображается (в случае N56 отображается только в самой ранней версии прошивки), там только можно отключить доступ к usb и, кажется, к cdromу
С учетом включенных на этом ноутбуке по умолчанию Intel AT и защиты от записи сторонними утилитами прошить такой модифицированный БИОС может быть очень непросто.
Поэтому нужно писать в техническую поддержку и требовать возврата опции в список доступных для редактирования. Если быть достаточно настойчивым — вернут.
Поэтому нужно писать в техническую поддержку и требовать возврата опции в список доступных для редактирования. Если быть достаточно настойчивым — вернут.
Ага. ASUS N56VZ (win7, но не суть) — возможность отключить Secure Boot есть, но появилась только путём отката на самую раннюю версию eeprom.
Обладатель точно такой же желязяки. Выпуск — июнь 2012. Secure Boot отключил без каких-либо плясок с бубном.
НЛО прилетело и опубликовало эту надпись здесь
Файловая система, написанная Майкрософт и ключи, выданные Майкрософт. Когда-то это уже проходили.
У меня стандартно два раздела — / и /home. Аптайм — два-три месяца, потом делаю какие-нибудь апгрейды ядра. Не вижу ни одной причины для перехода.
У меня стандартно два раздела — / и /home. Аптайм — два-три месяца, потом делаю какие-нибудь апгрейды ядра. Не вижу ни одной причины для перехода.
Причина перехода — защита от запуска неподписанных модулей и ядер. Например, у вас сервер и на него залезли, каким-то образом получили права рута и хотят поставить руткит в виде модуля ядра, а нифига, ничего не получится. Хотя бы это уже является весомым основанием для перехода, как по мне.
> получили права рута
… и добавили свой загрузчик с помощью efibootmgr.
… и добавили свой загрузчик с помощью efibootmgr.
… И сервер просто не загрузит неподписанный или подписанный не той подписью загрузчик.
Не так.
1. Получаем рута
2. Переписываем ключи uefi
3. Делаем winlocker, который невозможно сломать программными средствами
1. Получаем рута
2. Переписываем ключи uefi
3. Делаем winlocker, который невозможно сломать программными средствами
mbr и RussianNeuroMancer, ключи нельзя именно менять из не-EFI окружения, т.е. из ОС. И то, это нужно быть в Setup режиме, а не в User.
Вот мне этот момент интересен.
Есть всего два способа защитить безопасность системы от атак из ring0
1. Запускать из виртуальной машины. Что явно должно сказаться на производительности
2. Сделать аппаратный патч на процессор. В арме точно нет. Насчет x86 я не уверен, но мне кажется, что это слишком дорогое решение и не универсальное.
Т.е. абсолютное решение имеет свою цену. Остальное — отламывается.
Есть всего два способа защитить безопасность системы от атак из ring0
1. Запускать из виртуальной машины. Что явно должно сказаться на производительности
2. Сделать аппаратный патч на процессор. В арме точно нет. Насчет x86 я не уверен, но мне кажется, что это слишком дорогое решение и не универсальное.
Т.е. абсолютное решение имеет свою цену. Остальное — отламывается.
Есть ещё один способ: Lock-бит рядом с данными, сбрасывающийся только при глобальном RST#. Пока система не загружена, Lock-бит нулевой, в данные писать можно. Перед тем, как передавать управление системе, BIOS/UEFI ставит Lock-бит, и изнутри системы никакая сила даже из ring0 данных не запишет. Так защищается память режима SMM, к слову.
Дело в том, что загрузку модулей ядра регулирует само ядро и только само ядро. Загрузчик или UEFI ничего не знают про модули ядра, как они устроены, как загружаются и тому подобное.
Если в ядре есть подходящая уязвимость, через неё можно загрузить руткит, и от UEFI тут ничего не зависит и никакой в принципе помощи быть не может.
Если в ядре есть подходящая уязвимость, через неё можно загрузить руткит, и от UEFI тут ничего не зависит и никакой в принципе помощи быть не может.
Теоретически все правильно.
Но на практике мы имеем:
1. Активизировавшихся копирастов от железа и полностью закрытый ARM (x86 я как перспективную платформу не рассматриваю). Куча железок, за которые ты, по сути, платишь, но не владеешь ими в полной мере.
2. Это не спасает от дыр в самом uefi
3. Это не спасает от целенаправленной атаки ну ни разу. Пример со stuxnet, подписанной ворованными ключами очень показателен.
4. Чувство ложной защищенности заставляет админа расслабиться и потенциально словить руткит. Да, не пропишется в uefi. Сворует ключи/пароли и хватит ему :)
Но на практике мы имеем:
1. Активизировавшихся копирастов от железа и полностью закрытый ARM (x86 я как перспективную платформу не рассматриваю). Куча железок, за которые ты, по сути, платишь, но не владеешь ими в полной мере.
2. Это не спасает от дыр в самом uefi
3. Это не спасает от целенаправленной атаки ну ни разу. Пример со stuxnet, подписанной ворованными ключами очень показателен.
4. Чувство ложной защищенности заставляет админа расслабиться и потенциально словить руткит. Да, не пропишется в uefi. Сворует ключи/пароли и хватит ему :)
Проще переставить. Т.к. модули ядра надо будет ставить не подписанные (их множество, тот же KVM обновляющийся раз в неделю).
Да и проблема может крыться в утилитах мира, что еще хуже.
Можно переделать cron и уже оттуда рулить чем хочешь.
Да и проблема может крыться в утилитах мира, что еще хуже.
Можно переделать cron и уже оттуда рулить чем хочешь.
Вот именно. Какой смысл усложнять загрузку, если всё равно целевыми часто являются данные и конечные интерфейсы пользователя? От кражи данных никакой secure boot никогда не спасёт.
SecureBoot нужен только потому, что без него там вообще никакой безопасности нет. UEFI — это самая настоящая OS, работающая в ring 0, а частями и ниже, и имеющая собственные драйверы, собственный сетевой стек и доступ до всей памяти и всех устройств в обход основной ОС.
Без какой-либо защиты, в том виде, в котором оно реализовано на платах на P67/Z68 — это кошмар любого безопасника.
Любой получивший один раз рута код может сделать с БИОСом что угодно.
И не просто стереть его, а записать своих модулей, которые, при грамотном программировании, даже обновление БИОСа стандартными средствами будут переживать.
И все это вот нам подается под соусом «ускоряем загрузку на 10 секунд, пишем БИОС на С, в настройках высокое разрешение и мышь!» Поэтому SecureBoot — все-таки хоть какой-то, но выход из сложившейся ситуации.
Без какой-либо защиты, в том виде, в котором оно реализовано на платах на P67/Z68 — это кошмар любого безопасника.
Любой получивший один раз рута код может сделать с БИОСом что угодно.
И не просто стереть его, а записать своих модулей, которые, при грамотном программировании, даже обновление БИОСа стандартными средствами будут переживать.
И все это вот нам подается под соусом «ускоряем загрузку на 10 секунд, пишем БИОС на С, в настройках высокое разрешение и мышь!» Поэтому SecureBoot — все-таки хоть какой-то, но выход из сложившейся ситуации.
К слову, есть интересный UEFI Bootkit — Dreamboot
Dreamboot has two specific payloads: Privilege escalation and Windows local authentication bypass. DreamBoot comes in the form of a bootable ISO, to use preferably as part of a physical attack (i.e. when the attacker has physical access to the machine peripherals: DVD or USB ports). It is also fully functional in virtualized environments like VMWare Workstation or ESX.
Не далее как вчера-позавчера грузил свои ключи в SB x230, о чем думал написать на хабр :)
Такой Вам вопрос, как владельцу похожего агрегата, может знаете.
Превращу ли я в кирпич ноут, если отзову ленововские ключи через dbx?
Такой Вам вопрос, как владельцу похожего агрегата, может знаете.
Превращу ли я в кирпич ноут, если отзову ленововские ключи через dbx?
Запросто. Если у ваших личных юристов больше бюджет, чем у юристов леновы.
(Вазелин пока прикупите, пока у вас есть деньги)
(Вазелин пока прикупите, пока у вас есть деньги)
Прикольно, не знал, что там есть Secure Boot. У меня на X220 нету, да и UEFI спецификации 2.0 или 2.1, не помню, в общем, не самый новый. Хочу на форуме леново написать, чтобы обновили.
Думаю, в кирпич вы лаптоп не превратите, но ленововский софт может перестать запускаться.
Думаю, в кирпич вы лаптоп не превратите, но ленововский софт может перестать запускаться.
А может ли прикладная программа (не ОС), например, попросить UEFI проверить ключ/подпись чего-то? То есть, возможно ли таким образом реализовать привязку к железу?
Да, ядро линукса проверяет подпись модулей через UEFI, Windows 8 драйверы, тоже, вроде, но не уверен.
крутяк, от души
Здорово было бы, если бы UEFI взял на себя роль HAL. На своей машине из под Ubuntu столкнулся с тем, что система не может работать с модулем Ralink. В сети прочитал, что причина тому — закрытая спецификация компании. Поэтому удалось с бубном поднять только Wi-Fi (и то с глюками), а bluetooth висел на внешнем USB адаптере. Это не честно, друзья мои!
Я покупаю машину, и мое дело, какую систему туда ставить. Сравнение ОС — дело пустое, как я думаю. Но поддержка одной и игнорирование другой — это не профессионально. Кроме того, Linux доказал, что способен быть полноценной осью на сегодняшний день. Если бы драйвера железа были бы в UEFI, то ОС осталось бы только транслировать системные вызовы в вызовы универсального интерфейса. Обновления драйверов, думаю, тоже проблем бы не составили. С другой стороны, за производителем железа осталось бы право на закрытый код. Ведь системе он не нужен. Может я ошибаюсь и так уже делается?
Я покупаю машину, и мое дело, какую систему туда ставить. Сравнение ОС — дело пустое, как я думаю. Но поддержка одной и игнорирование другой — это не профессионально. Кроме того, Linux доказал, что способен быть полноценной осью на сегодняшний день. Если бы драйвера железа были бы в UEFI, то ОС осталось бы только транслировать системные вызовы в вызовы универсального интерфейса. Обновления драйверов, думаю, тоже проблем бы не составили. С другой стороны, за производителем железа осталось бы право на закрытый код. Ведь системе он не нужен. Может я ошибаюсь и так уже делается?
Это вы предложили сейчас драйвер для драйвера.
Я покупаю железо, и я хочу знать, как им управлять. Другими словами, спецификации должны быть открыты.
Я покупаю железо, и я хочу знать, как им управлять. Другими словами, спецификации должны быть открыты.
Или так. Я вообще не понимаю в чем смысл закрывать спецификацию. Это как не прикладывать инструкцию к телевизору. :D
Комерческое ноу-хау ( теперь усё автоматом делается, юзеру надо только ткнуть кнопку) или хауно-у ( чтобы сменить диапазон с 2 на 5 ггц запишем в эту сотню регистров это, потом дернем этот пин, а потом включим и выключим стабилизатор ) будучи раскрытым портит поток денег, кроме того проще один раз закрыть код и переодически делать абдейты, чем разбираться, что тот вумный юзер там понаписал, а то ещё его поделие в виде драйвера на нашу кофеварку, под калькулятор электроника, может дом сжечь — такое может урон имиджу нанести -> меньше бабла будет. Я тут намедни видел замечательный набор бреда:
Кто в здравом уме такое напишет?
xor eax, eax
cmp eax, 0h
jz eeee1
eeee1: mov eax, 0h
Кто в здравом уме такое напишет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного про UEFI и Secure Boot