Джеймс Боттомли (James Bottomley), известный разработчик ядра Linux, входящий в координационный технический комитет Linux Foundation, объявил (http://blog.hansenpartnership.com/linux-foundation-secure-bo.../) о доступности для свободного использования нового универсального загрузчика, подписанного ключом Microsoft и позволяющего организовать загрузку любых дистрибутивов Linux в режиме UEFI Secure Boot на системах, изначально поставляемых с Windows 8.
Загрузчик рассчитан на выполнение первой фазы загрузки с последующей передачей управления штатному загрузчику дистрибутива с проверкой его корректности по контрольной сумме, сохраняемой в процессе установки дистрибутива в специальной служебной области UEFI. Несмотря на то, что такие дистрибутивы, как Fedora и Ubuntu уже подготовили свои решения для загрузки на системах UEFI Secure Boot, небольшие проекты или дистрибутивы управляемые сообществом лишены возможности прохождения длительного процесса заверения загрузчика в сервисе Microsoft (организация Linux Foundation потратила (http://www.opennet.me/opennews/art.shtml?num=35388) более трёх месяцев на урегулирование разных формальностей и попутно возникающих проблем). Представленный Linux Foundation загрузчик может быть без ограничений использован любыми дистрибутивами у которых нет ресурсов или желания заверения собственного решения ключом Microsoft.Напомним, что для сертификации оборудования на совместимость с Windows 8, компания Microsoft требует обязательной активации по умолчанию режима безопасной загрузки UEFI, блокирующего загрузку систем, не имеющих заверенной цифровой подписи. Вариант поставки собственного проверочного ключа связан с большими организационными трудностями, потребовавшими бы согласования с каждым OEM-производителем вопроса включения проверочного ключа в прошивку, что неизбежно отразилось бы в появлении оборудования, которое не поддерживает Linux. Возможность заверения только первичного загрузчика, без формирования подписей для ядра и драйверов, укладывается в требования спецификации UEFI Secure Boot, которая нацелена главным образом на защиту начальной стадии загрузки, до запуска ядра.
Код (http://git.kernel.org/?p=linux/kernel/git/jejb/efitools.git;...) загрузчика и связанного с ним инструментария поставляется под лицензией GPL. Для загрузки доступно два заверенных ключом Microsoft EFI-компонента PreLoader.efi (http://blog.hansenpartnership.com/wp-uploads/2013/PreLoader.efi) и HashTool.efi (http://blog.hansenpartnership.com/wp-uploads/2013/HashTool.efi). Также создан (http://blog.hansenpartnership.com/wp-uploads/2013/sb-usb.img) готовый образ для быстрой организации загрузки систем с USB-накопителей. Файл KeyTool.efi с реализацией инструмента для управления ключами был отклонён компанией Microsoft из-за выявления возможности обхода ограничений безопасности UEFI на одной из UEFI-платформ, содержащей ошибку в своей реализации. До того как проблема будет устранена KeyTool.efi можно использовать с его ручной верификацией по хешу.
В отличие от ранее опубликованного (http://www.opennet.me/opennews/art.shtml?num=35475) загрузчика Shim, созданного Мэтью Гарретом (Matthew Garrett), заверенного ключом Microsoft и также рассчитанного на загрузку сторонних дистрибутивов, решение Linux Foundation выполнено в виде UEFI-расширения и имеет более универсальный характер. В частности, если Shim может передавать управление таким загрузчикам, как GRUB, то продукт Linux Foundation может быть использован совместно с более сложными загрузчиками, такими как Gummiboot (http://www.opennet.me/opennews/art.shtml?num=34222).
В отличие от GRUB, Gummiboot непосредственно не запускает Linux, а использует для запуска ОС механизмы UEFI (силами UEFI производится динамическое определение наличия пригодных для загрузки систем и передача им управления через UEFI вызов BootServices->LoadImage()). При активном режиме UEFI Secure Boot при таком подходе используется штатный механизм UEFI для проверки валидности загружаемых через BootServices->LoadImage() компонентов, т.е. ядро должно иметь валидную цифровую подпись (например, должно быть заверено ключом Microsoft). В связи с этим, системы с загрузчиком Gummiboot не могут работать с загрузчиком Shim (http://www.codon.org.uk/~mjg59/shim-signed/).Суть работы загрузчика Linux Foundation сводится к перехвату функций UEFI по проверке валидности образа и предоставление собственного обработчика, который для проверки неизменности ядра и Gummiboot задействует подтверждённые пользователем хэши, вместо верификации по проверочным ключам. Для реализации данной идеи в загрузчике были использованы методы (https://www.suse.com/blogs/uefi-secure-boot-details/), воплощённые инженерами проекта SUSE в загрузчике Shim 0.2 и позволяющие сохранять параметры заслуживающих доверия компонентов (проверочные хэши) в базе "MOKs" (Machine Owner Keys). Таким образом, вместо формирования официальных цифровых подписей разработчикам дистрибутивов теперь достаточно создать и сохранить в MOK хэши допустимых к загрузке компонентов.
URL: http://blog.hansenpartnership.com/linux-foundation-secure-bo.../
Новость: http://www.opennet.me/opennews/art.shtml?num=36068
Во всей этой канители я вижу такой профит для Мекрозофт.
На определенном этапе (примерно с 2007 года) установка Линукса стала проще, чем Виндовс.Теперь же, с выкрутасами UEFI SB, Мекрозофт снова задвинула линукс в категорию "сложные при установке ОС". Хомячье просто не захочет заморачиваться (элементарно: с флэшки уже так просто не загрузишься!) - на это и расчет.
Сносим W8, включаем Legacy Mode, ставим W7 и делаем что хотим.
Сносим W8, шлем нафиг W7 и ставим Linux. Вот это я понимаю, вариант :)
ага особеннов домене 2008 самое место линуксам...
С флешки то как раз и легко загрузиться будет. Ну а дальше дело инсталлятора. Правда, если что-то пойдет не так, то можно остаться без загружающейся машины. Хотя остается же флешка! :)
раньше для загрузки с диска нужно было зайти в биос и клацнуть на устройство привода. никто не обламывался. ты наблюдаешь отупевших за несколько лет людей? я вот не наблюдаю
Наконец-то!
Не нужно оно, железо, зависящее от ключа некрософт.
ты это объясни тем, кто такое железо производитосновной массе юзеров вообще фиолетово, ибо они не знают, что такое загрузчик, им главное чтобы работало
вой у них начнётся, когда не смогут семёрочку поставить всесто восьмёрочки и более совершенных творений M$
Та некоторый вой уже начался. При попытке переразбить винт не средствами W8 ноуты HP перестают грузиться. Повторные попытки установки W8 не увенчались успехом. Слава Всевышнему продавцы обменивают такие ноуты по гарантии. Чем больше такого гауна вернется производителю, тем, ИМХО, будет лучше. Если порекомендовать продвинутым хомячкам разбить винт PQ magicom, например, может возникнуть хардверная DDOS-атака из рекламаций на производителей.
> хомячкам разбить винт PQ magicom,А это идея! :)
Здравствуйте! Предлагаю создать специальный ресурс для случаев рекомендации хомячкам переразбития винта средствами каких-то распространенных утилит, акронисом например и pqmagicom. Вывести его в топ по ключевику/ключевикам : "как ускорить W8" "как переустановить w8" "ускорение w8" "смена w8 на w7". венDDOS обеспечен.
> вой у них начнётся, когда не смогут семёрочку поставить всесто восьмёрочки и
> более совершенных творений M$Вой будет недолгий. Сделают загрузчик 7ки на основе линуксового загрузчика, потому что тому без разницы что грузить vmlinuz или bootmgfw.efi.
Самое главное то пройти первичную валидацию, а потом можно грузить все что угодно.
> Самое главное то пройти первичную валидацию, а потом можно грузить все что
> угодно.Что, кстати, накрывает медным тазом всю идею этой безопасной загрузки.
> Что, кстати, накрывает медным тазом всю идею этой безопасной загрузки.Не совсем так: юзер явно аппрувит что "да, я хочу загружать именно это". Делая некие действия которые сложно сделать нечаянно. Для руткитов и буткитов такое свойство достаточно неудобно. Руткит которому надо спрашивать разрешение на запуск - это забавно :)
Обычно, юзверь, когда его что то спрашивают непонятное, тупо нажимает "Энтер"
> Сделают загрузчик 7ки на основе линуксового загрузчика, потому что
> тому без разницы что грузить vmlinuz или bootmgfw.efi.Тому же elilo разница есть, но доступны и универсальные. Правда, те склонны как раз вызовами фирмвари грузить, что при включенном SB приводит к попытке валидации подписи.
Читаем: "Суть работы загрузчика Linux Foundation сводится к перехвату функций UEFI по проверке валидности образа и предоставление собственного обработчика". Т.е. мы уже в памяти. Дальше можно делать все что угодно, механизм SB фактически не работает.
> Не нужно оно, железо, зависящее от ключа некрософт.Тогда для десктопа останется только приобретать что-то серверное,на xeon и формата 1U.
Все десктоп машинки ,скорее всего,будут с win UEFI.
Достаточно покупать железо без ОС - и все. Секуребут - условие субсидированой цены на ОЕМ-винду. Нет ОЕМ-винды - нет условий - нет секуребута.Тут главное довести до сведения покупателей, что дешевая предустановленная ОЕМ-винда автоматически означает вендор-лок и кучу гемора с альтернативными ОС, вплоть до умертвия железа. Мол, бесплатность сыра - она неспроста.
Нужен единый список системных плат и готовых устройств, безусловно подходящих для установки любой ОС.(Устройства без "безопасной" загрузки и устройства, где ее можно отключить.)
И такой список надо как можно шире публиковать.
> Нужен единый список системных плат и готовых устройств, безусловно подходящих для установки
> любой ОС.
> (Устройства без "безопасной" загрузки и устройства, где ее можно отключить.)
> И такой список надо как можно шире публиковать.Кстати, хорошая идея для hardware white list на wiki.opennet.ru
и даже самсунга ?
Сделал git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
Потом сделал make:высыпалась куча ошибок исходного кода.Что за фигня?
Лучше git clone <приватный ключик мс> сделай.
И сабж будет нинужен.
> Лучше git clone <приватный ключик мс> сделай.
> И сабж будет нинужен.git push <куча бабосов> не потребуется?Или чего-то пропустил?
gmake делал ?
> Сделал git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
> Потом сделал make:высыпалась куча ошибок исходного кода.Что за фигня?Скорее всего, понадобится установленный gnu-efi. Только лучше 3.0r, с 3.0s есть нюансы (апстрим уже в курсе).
т.е. есть теперь любой виреписатель может скачать этот загрузчик и запустить своё поделие на машине с секурбутом?
> т.е. есть теперь любой виреписатель может скачать этот загрузчик и запустить своё
> поделие на машине с секурбутом?Ага :) Причем загрузчик подменяется элементарно.
что будет в дебе? тоже что и в бунте или другое?
LinuxBIOS-же, вот решение.
Сделать свой ключик и аналогичным образом не пущать винду на комп.
Да.
Вот только компы такие пока(?) не продаются.
Только под вантуз.
Продаются. У них внутри процессоры mips или arm.
Я уже спрашивал, но никто не ответил, чем обеспечена защита этих самых краеугольных “Boot Services Only” variables?
> Я уже спрашивал, но никто не ответил, чем обеспечена защита этих самых
> краеугольных “Boot Services Only” variables?Лучше сразу смотреть спецификацию.
Я не понимаю, почему они свою дырявую ось защищают методами, которые нормальным осям ненужны? Совсем похерели, стульчик под жопой загорелся. И кстате, где гарантия, что вирус таким-же способом не перехватит вызовы uefi, и не загрузчит ещё чего-нибудь левое?
EULA почитайте, где там про гарантии?
> Я не понимаю, почему они свою дырявую ось защищают методами, которые нормальным осям ненужны?Именно затем и защищают.
> Я не понимаю, почему они свою дырявую ось защищают методами, которые нормальным
> осям ненужны? Совсем похерели, стульчик под жопой загорелся. И кстате, где
> гарантия, что вирус таким-же способом не перехватит вызовы uefi, и не
> загрузчит ещё чего-нибудь левое?Ну так, нормальные ОСы у них считаются угрозой "дырявой" ОСе ;) Потому и защищают такими методами.
А разве SecureBoot предложен не в качестве защиты от запуска в UEFI чего попало (рутки**апчхи) перед загрузкой ЛЮБОЙ операционной системы?
> А разве SecureBoot предложен не в качестве
> защиты от запуска в UEFI чего попало (рутки**апчхи)
> перед загрузкой ЛЮБОЙ операционной системы?:)
*nix опенсорс-системы по которым прошлись аудиторы безопасности и не имеющие UEFI это всё-таки не чего попало. В отличие от редмондского шита.
Ну, справедливости ради аудит безопасности операционной системы означает лишь то, что на него потратили деньги и не более того. Как показывает практика, его эффективность практически равна нулю. Почему? Ну просто если бы он позволял выявить все потенциальные закладки в системе, то после аудита в системе не должно было остаться ни одной уязвимости — потому что закладка может быть сделала в виде якобы случайно сделанной уязвимости. Поскольку в системах, прошедших сертификацию, находили уязвимости, значит вся процедура сертификации по факту лишь напрасная трата времени и денег (ну а для кого-то — возможность на этом заработать).В общем, по сути сертифицированная система — это такая же система, как без сертификата, только с сертификатом.
> Я не понимаю, почему они свою дырявую ось защищают методами,По моему скромному, в сумме с ос-лок железом это как просьба пинками под зад.
Но вот хрен они угадали.> которые нормальным осям ненужны
100%
При этом:
> подписанного ключом Microsoft- благодарствую барин, премного благодарны за вашу доброту.
(б#%@ь)
> PreLoader.efi и HashTool.efiИ чего с ними нужно делать?
вообще не пойму почему это должна определять, что и как, это должна делать независимая организация!
Он для 32-битного UEFI или для 64-битного?
> Он для 32-битного UEFI или для 64-битного?1) SB известен сейчас только на x86_64 и ARM, насколько знаю;
2) о, а у Вас есть 32-битное железо с UEFI?
Есть. Не было бы - не спрашивал.
почему фас не запрещает продукты ограниченные одной ОС ?
Мобильники на андроид, например ;)
>Вариант поставки собственного проверочного ключа связан с большими организационными трудностями, потребовавшими бы согласования с каждым OEM-производителем вопроса включения проверочного ключа в прошивку, что неизбежно отразилось бы в появлении оборудования, которое не поддерживает LinuxДа всех проблем это бы не решило, но почему нельзя было действовать сразу в двух направлениях.
Еще есть ключ canonical
Мдя одни выдумали неугодный способ загрузки, а другие кинулись его поддерживать. Причём правильно поддерживать. Хотя можно было, бы забраковать. В стиле не одна открытая ось не будет это поддерживать принципиально. Может быть и выгорело чтото. Но нет мало того что поддерживают так ещё и полностью по стандарту пытаются. Прогнулись под M$ по полной.
Я не понимаю, что технически мешает добавить в BIOS возможность использовать для подписания загрузчика и/или ядра собственный ключ, а также возможность установки/удаления/резервной копии ОЕМ ключей?
Например:
1. Ставим систему с отключенным UEFI
2. На рабочей системе генерируем ключ для данной системы или для данной копии(т.е снес систему - другую не поставишь)
3. Подписываем этим ключом ядро системы или что там ей ещё для загрузки требуется.
4. Скидываем ключ на носитель
5. Заходим в BIOS
6. Добавляем ключ
7. Включаем UEFI
8. PROFIT!!!Имеем самолично установленную систему загружающуюся через UEFI SecureBoot, безо всяких там ключей от мелкософта.
> что технически мешает добавить в BIOS возможность использовать для
> подписания загрузчика и/или ядра собственный ключ?Технически мешают производители плат, в которые этот биос зашивается.
Кстати, господа, есть обладатели lenovo x120e? Он ведь с UEFI?
Или это старая модель, в которой достаточно "где-то в биосе" отключить UEFI и всё будет пучком, ставь что хочешь?
UEFI с возможностью выбора классической загрузки (legacy boot). Линуксы загружаются и в том и в другом режиме. Secure boot нет.
в биосе включаешь legacy а дальше делай что хощь
Ну я счастливый юзер Gentoo, и для меня неизменённость ядра, порою, вопрос недельный. В общем радости нет границ..