Джеймс Боттомли (James Bottomley) рассказал (http://blog.hansenpartnership.com/lca2013-and-rearchitecting.../) об изменениях в разработке проекта по созданию универсального решения для загрузки любых дистрибутивов Linux на системах с активным по умолчанию режимом UEFI Secure Boot. По сравнению с первоначальным вариантом (https://www.opennet.ru/opennews/art.shtml?num=35059) реализация загрузчика была значительно переработана (http://blog.hansenpartnership.com/wp-uploads/2013/02/UEFI-Se...) для обеспечения поддержки совместной работы с более сложными загрузчиками, такими как Gummiboot (https://www.opennet.ru/opennews/art.shtml?num=34222).
В отличие от GRUB, Gummiboot непосредственно не запускает Linux, а использует для запуска ОС механизмы UEFI (силами UEFI производится динамическое определение наличия пригодных для загрузки систем и передача им управления через UEFI вызов BootServices->LoadImage()). При активном режиме UEFI Secure Boot при таком подходе используется штатный механизм UEFI для проверки валидности загружаемых через BootServices->LoadImage() компонентов, т.е. ядро должно иметь валидную цифровую подпись (например, должно быть заверено ключом Microsoft). В связи с этим, системы с загрузчиком Gummiboot не могут работать с первым вариантом загрузчика от Linux Foundation или загрузчиком Shim (http://www.codon.org.uk/~mjg59/shim-signed/), подготовленным (https://www.opennet.ru/opennews/art.shtml?num=35475) Мэтью Гарретом для решения аналогичных задач по загрузке любых дистрибутивов Linux на системах с UEFI Secure Boot.Поскольку основной задачей проекта Linux Foundation было обеспечение поддержки работы с любыми загрузчиками, ограниченная поддержка не устроила разработчиков и они стали искать альтернативные пути реализации проекта. Выход из сложившегося положения был найден в перехвате функций проверки валидности образа и предоставлении собственного обработчика, который для проверки неизменности ядра и Gummiboot задействует подтверждённые пользователем хэши, вместо верификации по проверочным ключам. Для реализации данной идеи в загрузчике были использованы некоторые хитрости (https://www.suse.com/blogs/uefi-secure-boot-details/), воплощённые инженерами проекта SUSE в загрузчике Shim 0.2 и позволяющие сохранять параметры заслуживающих доверия компонентов (проверочные хэши) в базе "MOKs" (Machine Owner Keys). Таким образом, вместо формирования официальных цифровых подписей при использовании загрузчиков типа Gummiboot разработчикам дистрибутивов теперь достаточно создать и сохранить в MOK при помощи специально подготовленной утилиты хэши допустимых к загрузке компонентов.
Что касается процесса заверения загрузчика Linux Foundation ключом Microsoft для его работы из коробки на всех сертифицированых для Windows 8 компьютеров, первая попытка которого завершилась провалом (https://www.opennet.ru/opennews/art.shtml?num=35388), то сообщается, что все ранее всплывшие проблемы были устранены и 21 января была отправлена заявка на формирование цифровой подписи для нового варианта загрузчика. Ожидается, что подписанная версия будет готова не позднее, чем через две недели после отправки заявки. После этого новый загрузчик, подписанный ключом Microsoft, будет опубликован для свободного использования на сайте Linux Foundation.
Тем временем, Мэтью Гаррет (Matthew Garrett), один из разработчиков ядра Linux, последнее время занимающийся обеспечением загрузки Linux на системах с UEFI, подытожил (http://mjg59.dreamwidth.org/22028.html) наблюдаемое в настоящее время проблемное оборудование, на котором невозможна загрузка Linux с использованием UEFI. Кроме ноутбуков Samsung, теряющих (https://www.opennet.ru/opennews/art.shtml?num=35973) работоспособность после загрузки Linux в режиме UEFI, в обзоре отмечены ноутбуки Toshiba, которые отказываются (https://bugzilla.redhat.com/show_bug.cgi?id=896212) в режиме UEFI Secure Boot загружать дистрибутив Fedora 18, загрузчик которого подписан ключом Microsоft, а также некоторое ноутбуки Lenovo, которые из-за ошибки (https://www.opennet.ru/opennews/art.shtml?num=35355) соглашаются загружать с использованием UEFI только Windows и Red Hat Enterprise Linux.
URL: http://blog.hansenpartnership.com/lca2013-and-rearchitecting.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=35997
в настоящее время списочек проблемного оборудования таки растет...
s/проблемного/неконкурентного/gтолько дебил боится конкуренции...
Не в конкуренции дело, хотя и это важно. Казалось, что уже прошли времена когда под линукс нужно было подбирать оборудование. Но в итоге: "нет ничего нового под солнцем".
> Не в конкуренции дело, хотя и это важно. Казалось, что уже прошли
> времена когда под линукс нужно было подбирать оборудование. Но в итоге:
> "нет ничего нового под солнцем".а под виндовс ХР не надо будет? Она тоже не будет работать на сих компах...
> s/проблемного/неконкурентного/g
> только дебил боится конкуренции...Ну да, глядя на это
http://nnm.ru/blogs/SSSR/ssha-desyat-let-tyurmy-za-razlochku.../
можно с уверенностью сказать что лет так через 5 загрузка чего то кроме винды на плате с
UEFI будет караться 3-х летним тюремным заключением. И все для вашего блага ...
Вы путаете, по ссылке представлено обычное нарушение контрактных обязательств.
Контрактные обязательства наверно можно и припахать.
Ну так как начали повсеместно переходить на UEFI косяки то косяками и пошли. Ну вот лень производителям firmware тестить свои поделия на соответствие спекам. Ну подумаешь, работало же в 1.0 с 128 байтами, ну и кто ж мог представить что в 2.0 можно уже буфер неограниченной длины предоставлять?
Но что самое обидное, конечные производители оборудования не спешат нагибать тот же Phoenix и выпускать хотя бы обновления для BIOSов. Хотя та же Lenovo знала о проблеме как минимум пол года, а никакой официальной реакции даже не последовало.
Сама же спецификация UEFI практически не содержит механизмов защиты от дурака, так что не удивительно, что все эти секуребуты долго не протянут в нынешнем виде.
Как только первый вирусописатель напишет под винду (поскольку там легче всего найти и заразить хомяка) "убийцу самсунгов" - думается, что к UEFI начнут подходить осторожнее.
Да здраствует новий «Чернобыль»...
> списочек проблемного оборудования таки растет...Samsung можете вычёркивать! проблему решают с двух сторон (и инженеры Самсунга и инженеры Линуксов. в итоге проблема возникнет ТОЛЬКО у тех кто использует ОДВНОВРЕМЕННО: и старый Линукс и старый Ноутбук).
итак -- список стабилизирется... :)
Леново и Тошиба, значит остались
У самсунга в биосе две проблемы, о чем все забывают. Первая это раскрученная ошибка в модуле samsung-laptop, а вторая, общая для всех firmware от Phoenix: забивание на требования спецификации 2.0 на размер буфера, что приводит к затиранию загрузочных записей в NVRAM.
Так что посмотрим что конкретно они исправят.
> Samsung можете вычёркивать! проблему решают с двух сторон (и инженеры Самсунга и
> инженеры Линуксов. в итоге проблема возникнет ТОЛЬКО у тех кто использует
> ОДВНОВРЕМЕННО: и старый Линукс и старый Ноутбук).Ну, если уж совсем честно, то проблему могут РЕШИТЬ только инженеры Самсунга, разработчики Linux могут проблему ОБОЙТИ, но проблема-то останется, и не факт, что где-то когда-то она не вылезет еще каким нибудь боком.
Посмотрим...
А чего тут смотреть? Если перевести на человечий, то это сообщение о том что:1) Заверить свой загрузчик ключом от мелокомягких до сих пор не получилось
2) Список не поддерживаемого оборудования растет
3) Найдена дырка, позволяющая вместо заверенной ключами оси, запускать заверенные х. з. кем компоненты. И эта дырка все что у нас на данный момент есть, что бы запускаться.ИМХО, зря они думают использовать мелкософтовский ключик, - не дадут им его (под благовидным поводом, конечно). И дырку закроют. А единственно на что можно ставить так это на валву с убунтой. Вот они возможно дадут какую-то часть производителей железа рассчитанного на игроманов. Ну и наверное свободная реализация UEFI что-то сможет отвоевать. Но все это "слезки", считанные проценты рынка.
> ИМХО, зря они думают использовать мелкософтовский ключик, - не дадут им его (под благовидным поводом, конечно). И дырку закроют.вряд ли это дырка. (или где-то всё же написано что это дырка?). думаю это штатная функция UEFI, так как расчитанно что УЖЕ загрузился загрузчик который был проверен через SecureBoot [а уж дальше что загрузчик делает -- пофигу.]
но ключик дёмаю не дадут, или дадут но потом отзовут. когда узнают что с помошью всех этих "хитростей" можно запускать вендовые буткиты :)
....либо Майкрософт совсем дибилы, если не отзовут ключ.
# P.S.: всё крутится вокруг этой Венды, блин. центр вселенной прямо... ну ладно, ладно, ...
Вот мне интересно, как вы себе представляете этот отзыв. Навыпускали производители железяк, что дальше?
затем майкрософт уведомила всех производителей о том что мол вот свежий список отпечатков для чёрного личта!..затем производители сделали обновления.. (гдето не сдлали конешно, из-за лени :))
блин. ну как-то ведь получили разработчики железа от Майкрософта изначальные ключи, следовательно они сотрудничают. следовательно связь с Майкрософтом есть!
Я представляю так:
1) выпускаем новый ключ и запихиваем его во все новое оборудование
2) выпускаем пакет обновления обязательный для применения, с какими нибудь супер-вкусными плюшками (к примеру, бесплатный подъем базовой версии, до ультимэйт), но только для установивших новый ключик (сам ключик валяется тут же, как и инструкция по его установке). Забивших на наши плюшки предупреждаем о том, что старый ключ скоро прекратит свое действие и ось не запустится
3) Ждем 3-4 месяца
4) Отзываем старый ключ
5) Объявляем на весь мир, что раздача лишних слонов... то есть ключей прекращена, ввиду их отсутствияИ все что для этого надо, так это возможность средствами самой оси поменять текущий ключ. А это вполне возможно, поскольку менять будет ось (точнее ее подписанный компонент) уже известная и доверенная для биоса. И линуксоиды пойдут, - при этом варианте, - в сад воскуривать бамбук, поскольку биос им поменять ключ не даст, ибо будет пытается менять неизвестный (не доверенный) ему компонент оси.
угу… может быть… если в очередной раз не сфэйлят:
>Самое интересное, что судя по параметрам подписи, файл был подписан основным ключом Microsoft и как для продукта Microsoft (в поле получателя было указано Microsoft Corporation, вместо Linux Foundation), без возможности отзыва подписи.
> Вот мне интересно, как вы себе представляете этот отзыв.
> Навыпускали производители железяк, что дальше?Так через виндовые обновления. Нет винды -- нет и этой проблемы ;)
похоже что появились исходники части вируса кладущего на попытки uefi защитить процес загрузки операционки... :)
Это что же, с каждой новой сборкой загрузчика идти на поклон к MS, и кляньчить у них - подпишите, мол, пожалуйста?
Было бы смешно, если бы не было так грустно.
> Это что же, с каждой новой сборкой загрузчика идти на поклон к
> MS, и кляньчить у них - подпишите, мол, пожалуйста?
> Было бы смешно, если бы не было так грустно.смотря про какой загрузчит идёт речь...
...теперь ведь из тут аж целая цепочка! :-D
я конечно же надеюсь разработчики первоначальных загрузчиков (Pre-BootLoader, Shim, ... и подобные) -- достаточно умные, чтобы не раздувать внутри них огромные абзацы кода :)
> Это что же, с каждой новой сборкой загрузчика идти на поклон к
> MS, и кляньчить у них - подпишите, мол, пожалуйста?Благодаря находчивости и трудам Гаррета с openSUSE-шным народом -- нет, достаточно shim.
> Было бы смешно, если бы не было так грустно.
Это да, ситуация выглядит достаточно абсурдно даже с такой поправкой. MS пошло ва-банк.
а куда антимонопольщики смотрят?
> а куда антимонопольщики смотрят?а чё случилось? Майкрософт официально велела всем x86_64-производителям добавить возможность отключать SecureBoot ...
...ну а уж по поводу того что часть производителей "случайно"(?) сделали реализации EFI которые прекрасно работают с Windows но глючат с Linux -- здесь майкрософт официально не виновата :-)
кстате говоря я тут вижу два возможных варианта:
1. теория заговора
2. теория глупости (Бритва Хэнлона :))
> а чё случилось? Майкрософт официально велела всем x86_64-производителям добавить возможность
> отключать SecureBoot ...а можно линк на сией решение?
>> Майкрософт официально велела всем x86_64-производителям добавить возможность
>> отключать SecureBoot ...
> а можно линк на сией решение?Было дело после того, как их приложили на относительно ранней стадии.
Гляньте в окрестностях https://www.opennet.ru/opennews/art.shtml?num=31841
> а куда антимонопольщики смотрят?Как всегда - в сторону. Причем в ту, откуда ветер несет запах бабла.
нужно переждать, пускай они перебесятся и все будет хорошо. через 3 года на новом ПК будет можно запускать любую ОСь хоть с UEFI Secure Boot, хоть без него
Через 3 года выйдет вынь10 с супердуперсекуре2 в требованиях.
Они всегда так делают.
Меня удивляют всякие "меленькие хитрости" и прочие словечки, создающие впечатление похаканного secure boot. Все просто - негрософт доверяет-подписывает (или не доверяет) линуксовому или иному прочему загрузчику. Все. точка. Дальше этот shim, или как его там, делает, что хочет, включая любые костыли вроде подсованных ключей. Хеши - тощая подпорка, ибо boot service only не впечатляет совершенно.
Прогнулись - таки прогнулись. Поздравляем! Чего там у нас говорил по этому поводу "ненормальный" бородач? ;)
вообще не пойму это все, почему кто-то за меня должен решать. МОЙ компьютер и я в праве решать, что с ним делать- что хочу то и гружу
> Представлен новый вариант
> UEFI Secure Boot загрузчика от Linux FoundationSecure boot [Disable]
Legacy mode [Enable]# mkfs.ext3 /dev/C:
И все проблемы исчезают моментально.
Проблем тут нет. Вопрос только во времени и наверно в адаптации бизнес модели опенсорс к новым условиям.