Поясните про анти-опенсорсную опасность UEFI BIOS?

man Secure Boot

Ты вообще нифига не понял.
UEFI это не BIOS. И никто никогда не писал, что UEFI каким-то образом мешает. Ты, скорее всего, про Secure Boot говоришь, но это отдельная история.

UEFI тут ни при чём.

Опасность в том, что микрософт, как обычно влезла. Поначалу всё было хорошо. Secure Boot - в принципе неплохая технология.

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

В результате сообщество и засуетилось.

На мой взгляд UEFI без secure boot вполне безобидная вещь, если не считать потраченное время на разбирательства и чтение новой документации по разбивке диска, загрузчикам, refind. И придется осилить gpt - штатные и привычные дисковые утилиты тут бессильны.

Более поздние спецификации UEFI поддерживают secure boot с «криптографией от микософт». В моей железке в биосе есть UEFI но ни слова о secure boot. Возможно повезло - просто было меньше возьни с одной стороны.

Для начала почитать: http://www.rodsbooks.com/gdisk/ и на педивикии по ключевым словам

загрузи http://www.sysresccd.org/SystemRescueCd_Homepage - там есть утилиты для uefi и собственно сам загрузчик диска.

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

Так он для этого и придуман был.

Как будто секьюр бут невозможен без UEFI...

http://habrahabr.ru/post/185492/

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

Мне честно говоря по барабану если оно работает. BIOS нормально работал. Пусть и г-но мамонта написанное в реальном режиме. Намедни сменил матплату. Пусть там и нет SecureBoot, но огреб проблемы в виду того, что на дефолтных настройках Linux начинает паниковать и на каждый USB девайс пишет полотно с ошибками вида read/64 error -32. В итоге пришлось пол-вечера потратить, чтобы поправить все это.

В UEFI не вижу плюсов, но вижу много препятствий.

Проблема заключается в том, что если Secure Boot будут легко обходить в мире Open Source, то смысл этой опции как основного средства против буткитов, превратится в лопнувший мыльный пузырь

биос бы и дальше прекрасно работал если бы не появились винчестеры размером больше 4Тб... тут появилась маленькая проблема с ограничением накладываемым старым добрым MBR на максимальный размер диска... а учить биос грузить систему из GPT никто видимо не собирается... так что теперь всем остальным остаётся только грызть кактус.

а учить биос грузить систему из GPT

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

биос бы и дальше прекрасно работал если бы не появились винчестеры размером больше 4Тб...

2TB.

UEFI - сам опенсорц

Секьюр бут с вендор локом, а также проталкивание майкрософтовских форматов исполняемых файлов и файловых систем на уровень «биоса».

А... Ну спасибо, разъяснили!

Он такой же опенсорц как windows система с запущенным apache сервером.

А вообще, еще полезно посмотреть на код edk2 tianocore, чтобы понять кто и под какими веществами его писал. Вообще, сам по себе UEFI - это ОС, нподобие ДОС, а за саму инициализацию железа отвечает PI (Platform Initialization), который можно заменить на coreboot.

SecureBoot - defective by design. Потому как UEFI не задумывался как система, с безопасностью в уме. См. доклад про взлом SecureBoot на BlackHat 2013 https://www.blackhat.com/us-13/briefings.html#Bulygin

Как это его будут легко обходить, если ключи генерировал бы сам пользователь, как это изначально и задумывалось?

Вся проблема с Secure Boot в том, что с подачи MS захотели сделать так, что «вот тут у нас ключики подписаны на винду и больше ничего не ставь.»

1. Это не BIOS

2. Опасность в том, что оно предполагает блобы и закрытость, для чего в жертву была принесена технически грамотная архитектура.

3. SecureBoot - логическое продолжение UEFI, поскольку UEFI делали именно для того, чтобы было проще вендорлокерам реализовывать свои задумки.

mm3> биос бы и дальше прекрасно работал если бы не появились винчестеры размером больше 4Тб... тут появилась маленькая проблема с ограничением накладываемым старым добрым MBR на максимальный размер диска...

Ничто не мешает это ограничение отодвинуть. Как раньше и делали.

Плюс было несколько биосов, которые поддерживали GPT

Почему бы биосу не «знать» только про первый терабайт, в котором уже нормальная ОС, которая видит всё? Это был бы отнюдь не самый большой костыль в истории PC...

если Secure Boot будут легко обходить в мире Open Source, то смысл этой опции как основного средства против буткитов, превратится в лопнувший мыльный пузырь

Почему? Разработчики дистрибутивов же подписывают пакеты, при этом пакеты всё так же свободное ПО «по Столлману» (можно пересобрать и убедиться в идентичности), а секретные ключи всё так же секретные. Тут то же самое, только открытый ключ где-то в материнке зашит.

А вот самосборные ядра, видимо, придётся пересобирать на отдельном чистом livecd, чтобы гарантировать отсутствие бэкдора.

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

Вкратце - даже Secure Boot сам по себе хорошая вещь, позволяющая защититься от загрузки вредоносного кода в пространство ядра - напрмер, руткитов.

если это делать через штатную функции, условно «Загрузить_модуль()» то позволяет, а если ты используеь, условно переполнение буфера, то нет.

UEFI не задумывался как система, с безопасностью в уме

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

Кстати, а как починил ошибки вида read/64 error -32 ?

Разработчики дистрибутивов же подписывают пакеты, при этом пакеты всё так же свободное ПО

Это всё конечно хорошо, но при таком подходе бесчисленное количество патчей, исправляющее или добавляющее что-то, идут теперь лесом так как теперь невозможно будет просто скачать исходники накатить патч перестроить и пользоваться, то-есть умрёт та самая свобода которая упоминается в аббревиатуре Open Source.

Включением какой-то функции эмуляции в биосе. Emulate 60/64 чего-то там. Врубил её и IOMMU. Работает.

Ну да, и поэтому выбрали flat память, так что можно поставить любой свой код на место uefi кода просто заменив: Phoenix - UEFI Security Defenses

Почему? Если можно добавлять свои ключи - то «наложил патчи, подписал» и вперёд. (А если нельзя, то Secure Boot абсолютное зло и УБИВАТ)

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

В общем-то да, по здравому размышлению - «но зачем?»

что-что заменить? и как

И придется осилить gpt - штатные и привычные дисковые утилиты тут бессильны.

Все популярные дистрибутивы поддерживают установку на GPT уже несколько лет, а многие даже предлагают его по дефолту не только на UEFI, но и на BIOS. Какие такие дисковые утилиты его не поддерживают?

а учить биос грузить систему из GPT никто видимо не собирается... так что теперь всем остальным остаётся только грызть кактус.

На самом деле BIOS-у пофиг, как разбиты твои диски, ему лишь бы загрузчик лежал в первом секторе. GPT вполне можно использовать с BIOS, но не в венде.

Так и делают, только не про первый терабайт, а про первый сектор и максимум первые несколько мегабайт, если загрузчик очень жирный.

(можно пересобрать и убедиться в идентичности)

Убедиться в идентичности — не так-то просто.

например утилиты семейства fdisk из пакета sys-apps/util-linux для gentoo и остальных:

при запуске, выдает сообщение:

fdisk /dev/sda
...
WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
...

Автор пакета sys-apps/gptfdisk позиционирует его как замену устаревающему fdisk

Без secure boot это дуршлаг.

2. Опасность в том, что оно предполагает блобы и закрытость, для чего в жертву была принесена технически грамотная архитектура.

кстати да - без secure boot, закрытость все-же остается, хотя и в случае обычного BIOS та-же закрытая «фирмаварь». Когда-то была популярна тема дизассемблирования BIOS... В случае UEFI наверное это выглядит несколько иначе.

Без secure boot это дуршлаг.

а в случае оного более высокоуровневое решето...

слив защитан