Грег Кроа-Хартман (Greg Kroah-Hartman), мантейнер нескольких подсистем ядра Linux и ответственный за поддержку стабильной ветки ядра, сообщил о присоединении огранизации Linux Foundation к группе UEFI.org (http://www.uefi.org/) и подготовил (http://www.linuxfoundation.org/news-media/blogs/browse/2013/...) подробную инструкцию с описанием процесса сборки и загрузки ядра Linux на системах с UEFI Secure boot с использованием собственного ключа для верификации неизменности загружаемого ядра и модулей. Ядро собирается в форме бинарного файла EFI и загружается непосредственно прошивкой UEFI, без использования промежуточных загрузчиков.URL: http://www.linuxfoundation.org/news-media/blogs/browse/2013/...
Новость: https://www.opennet.ru/opennews/art.shtml?num=37812
какой в этом смысл?
А смысл такой, что если твое ядро изменит какая-то программа или кто-то захочет поиметь тебя, то оно не загрузится!
> А смысл такой, что если твое ядро изменит какая-то программа или кто-то
> захочет поиметь тебя, то оно не загрузится!если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.
> если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.А о чем? Готовить ведро вазелина чтоли? В конце концов, проверка целостности системы сама по себе абсолютным злом не является. Если это дадено юзеру под контроль.
Само по себе это не большее зло чем замок на входной двери, где ключи раздали только своим любимым а остальные видят железную дверь. Проблемы начинаются когда появляется какой-то левый хрен, который в вашей квартире ставит свой замок, начинает контролировать время прихода и ухода и вообще ведет себя как какой-то гестаповец.
>> если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.
> А о чем?о том, как дошёл до жизни такой.
> о том, как дошёл до жизни такой.Так это... проклятые корпорасы же. Ну ты наверное как и я не паяешь 6-слойную плату такого размера у себя на кухне, да? И разводить переростка о 1000 шариков сам наверное не очень мечтаешь, так? :)
А вы даёте гарантию, что всю эту "верификацию" слишком сложно поиметь, при том, что она вообще не имеет связи с пользователем?Если имеют OS это видно в OS. Что и где можно мониторить в этой недо-ос-пере-загрузчике?
А что мешало так сделать раньше?
> А что мешало так сделать раньше?то есть -- что мешало написать подробную инструкцию? :)
да... вопрос интересный...
Отсутствие возможности запихнуть эти ключики в уефи большинства материлок, где живут только ключики мс.
Ваш кэп.
Т.е. ад с мелкософтом и ключами закончился?
> Т.е. ад с мелкософтом и ключами закончился?Нет, он только начался.
это уже не противоречит лицензии? или бинарным будет только загрузчик?
Это не противоречит лицензии, поскольку здесь нет даже тивоизации — ты собрал ядро из исходников, ты его подписал, ты же его и скормил EFI.Другое дело, что это слегка противоречит здравому смыслу, но что делать.
почему? это гарантирует неизменность. что и приследовалось
> почему? это гарантирует неизменность. что и приследовалосьОт прямой подмены ядра это защитит, но поскольку ключ известен, можно пересобрать ядро и подписать его на той же машине, где оно стоит. Что лишает затею смысла.
>поскольку ключ известенпо-хорошему, ключ должен быть известен только владельцу машины. тогда это всё имеет смысл
> но поскольку ключ известен,А откуда кому-то левому известен твой приватный ключ?
Ключ не известен. Но *возможность* сгенерить собственный ключ и подписать уже им - гарантия защиты от тивоизации и выполнение GPLv3. А с v2 еще проще ;)
Не лишает. Тот кто не хочет возиться с перекомпиляцией нисколько не пострадает от подобного. Но в организациях, к примеру, для хранения приватных ключей можно выделить специальный не подключенный к сети комп.
> Не лишает. Тот кто не хочет возиться с перекомпиляцией нисколько не пострадает
> от подобного. Но в организациях, к примеру, для хранения приватных ключей
> можно выделить специальный не подключенный к сети комп.если в организации некто неучтённый самовольно заменил ядро — то проблема там совсем-совсем не в ключах…
Пока еще не встретил десктопную материнку с неотключаемым UEFI Secure Boot и он даже отключен по умолчанию (Asus, AsRock)
> Пока еще не встретил десктопную материнку с неотключаемым UEFI Secure Boot и
> он даже отключен по умолчанию (Asus, AsRock)на некоторых материнских платах есть дополнительная строчка (но зачем её подумали?) которая обозначет название операционной системы которая предполагает загружаться.
там может быть знчение "Microsoft Windows" или "Other".
тыг вот бывает такое что пока не выбирешь "Other" -- нельзя отключить Secure Boot.
такая ситуация может заставлять людей -- писать на форумах о том что Secure Boot якобы не отключается..
Ноутбуки :(
А так же скорость старта, для того-же ноута к примеру.
На материнках AsRock c "ГУАШ" 3 опции:
- normal
- "quick" (точно не помню, разница с normal 1-2сек).
- Fast <- вот тут, если переключить сюда рубильник, то нужна Win8 что бы отменить его, т.к. в UEFI не зайти (так пишет встроенная справка UEFI).Ноуты, не сталкивался, т.к. собирал обычный дэсктоп. Но думаю, что это в основном будет как в материнках, проблема лишь в том, что в предустановленной Win8, "FAST" может быть включен по дэфолту. Тут появляется 2 проблемы:
- что делать, если мы отказываемся от Win8? в этом случае нужно отключить "FAST", но не заходить в Win8 (не соглашатся с лицензией, не активировать и т.д., что бы не обвинили в ее использовании).
- если сбросить в дэфолт UEFI, в каком режиме он будет? Если в "FAST", то это печалька...Кто сталкивался с Win8 на ноуте, отпишите плиз, очень уж интересно знать. Не покупать же ноуты для проверки :-D
чтобы отключить FastBoot разве обязательно нужно Win8 ?нельзя чтоле загрузиться из загрузочного linux-USB-образа и выставить режим "Reboot to EFI Setup"
ну GUMMIBOOT же!!
А для того чтобы загрузится с USB, надо отключить FastBoot.
> Кто сталкивался с Win8 на ноуте, отпишите плиз, очень уж интересно знать.
> Не покупать же ноуты для проверки :-DС невозможностью попасть в фирмварь по причине ещё не инициализированного USB при включении fast boot _пока_ не сталкивался, но читал.
Вообщем, вроде нормально. Как и предполагал лучший выход - самоподписаные ключи. С помощью опенсорс утилит удаляешь (предварительно сохранив) пришедшие с ноутом ключи и ставишь на их место свои. И подписываешь свое собранное ядро. Плохо что ФС ФАТ.И загрузчик уэфи закрытый.
uefi открытый, а вот реализация от AMI проприетарная.
> uefi открытый, а вот реализация от AMI проприетарная."Теоретически, Петька, мы с тобой миллионеры. А практически..."
На самом деле, FAT это не плохо, по простой причине - он ВЕЗДЕ поддерживается, если только намерено не вырезается.
ИМХО, содержимое /boot очень редко когда меняется, поэтому журнал для этого раздела не критичен, т.к. там нет критически важных и уникальных декументов и файлов, и которые легко восстановить, если уже такое произошло. И скорость не важна, т.к. 99,9% использования этого раздела - только чтение и ядро с initramfs весит до пары десятков мегабайт.Другое дело, патентные разбирательства со стороны Мелкософта, а вот с этой точки зрения, следовало бы им выбирать патентно-чистую дэфолтно-поддерживаемую файловую систему.
fat используется не для /boot, а для EFI Partition.
> fat используется не для /boot, а для EFI Partition."EFI System Partition" -- нужна только для Microsoft Windows , а НЕ для процесса загрузки UEFI ..
Линуксу же (в отличии от Microsoft Windows) -- абсолютно пофигу на то -- существует ли раздел "EFI System Partition" или отсуствует.
а вот сама прошивка материской платы -- вообще ни как НЕ учитывает тип раздела во время загрузки (её пофигу, сущесвует ли ESP или отсутсвует, так же как и для GNU/Linux).
прошивка пытается загружать любой /EFI/BOOT/BOOTX64.EFI , без разницы на каком разделе она его найдёт (ESP или НЕ -- ESP для прошивки это всё равно).
> fat используется не для /boot, а для EFI Partition.
так что -- я с уверренностью могу сказать что имеет смысл делать FAT32 именно для /boot/ .. а вот ESP-раздел -- вообще делать НЕ надо, в случае если отсутствует Microsoft Windows на компьютере.
Вы, простите, заткнётесь на тему UEFI до хотя бы элементарного изучения матчасти? Например, здесь: http://www.rodsbooks.com/efi-bootloaders/principles.html> "EFI System Partition" -- нужна только для Microsoft Windows ,
> а НЕ для процесса загрузки UEFI ..
> Линуксу же (в отличии от Microsoft Windows) -- абсолютно пофигу на то
> -- существует ли раздел "EFI System Partition" или отсуствует.
> а вот сама прошивка материской платы -- вообще ни как НЕ учитывает
> тип раздела во время загрузки (её пофигу, сущесвует ли ESP или
> отсутсвует, так же как и для GNU/Linux).То-то даже с ISO9660 не загрузиться.
> прошивка пытается загружать любой /EFI/BOOT/BOOTX64.EFI , без разницы на каком разделе
> она его найдёт (ESP или НЕ -- ESP для прошивки это
> всё равно).
> так что -- я с уверренностью могу сказать что имеет смысл делать
> FAT32 именно для /boot/ .. а вот ESP-раздел -- вообще делать
> НЕ надо, в случае если отсутствует Microsoft Windows на компьютере.Всё процитированное является ложью.
PS: добавил оверквотинг, т.к. неверно _всё_ написанное Вами в #43.
> Вы, простите, заткнётесь на тему UEFIда, я затыкаюсь :-) ..
доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :).
кто хочет -- тот может проверить #43 -- на любом современном компьютере. я лично проверял на нескольких.
кому особо не интересно -- может не проверять, а вместо этого верить в то во что хочет верить :)..
а вот болтовня на форуме -- ну точно ни чего не изменит :-)
> доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :).Наверное потому что такие глупые скрипткидисы как ты понимают что тут что-то не так только когда уже "ААА!!! Kurwa!!!".
> я лично проверял на нескольких.
Очень репрезентативная выборка - опробовать пару писюков из миллиарда.
>> Вы, простите, заткнётесь на тему UEFI
> да, я затыкаюсь :-) ..Спасибо. И меня не стесняйтесь заткнуть, когда чушь несу.
> доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :)
> кто хочет -- тот может проверить #43 -- на любом современном компьютере.
> я лично проверял на нескольких.И всё-таки идите на rodsbooks учить матчасть. Как вариант -- показывайте выхлоп gdisk -l /dev/sdX и ls /sys/firmware/efi с таких машин для предметного продолжения разговора.
исправление - самоподписаное ядро. Еще рамдиск надо или в ядро встраивать или обходиться без него.
Просто оставлю здесь efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -u root=/dev/sda3 ro initrd=EFI/arch/initramfs-arch.img
initrd у тебя не подписаный.
> Просто оставлю здесь efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux"
> -l '\EFI\arch\vmlinuz-arch.efi' -u root=/dev/sda3 ro initrd=EFI/arch/initramfs-arch.imgAlso, as we don’t have an initrd passed by the bootloader to the kernel,
if you want to use one, you need to build it into the kernel itself.
The option CONFIG_INITRAMFS_SOURCE should be set to your
pre-built cpio initramfs image you wish to use.
> if you want to use one, you need to build it into
> the kernel itself.не понятно только, нафига тогда вообще этот initrd нужен в таком случае.
> Просто оставлю здесь efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux"
> -l '\EFI\arch\vmlinuz-arch.efi' -u root=/dev/sda3 ro initrd=EFI/arch/initramfs-arch.imgи ядро у тебя сегодня майкрософт подписала, а завтра передумала.
Передумала, сперла с ЛОРа libastral.so, залезла через него на комп и прибила ключ? Не говоря о том, что отзыв ключа всегда влечет такие проблемы, что его даже по серьезным причинам частенько не делают.
> Просто оставлю здесь efibootmgr -c -d /dev/sda -p 1 -L "Arch Linux" -l '\EFI\arch\vmlinuz-arch.efi' -u root=/dev/sda3 ro initrd=EFI/arch/initramfs-arch.imgкстате -- переименовывать "vmlinuz-arch" в "vmlinuz-arch.efi" -- не обязателно :)
Interoperation with Open Systems
To enable proper operation with open systems, all UEFI secure boot platforms should ship in
setup mode, with no Platform Key installed. This enables the Platform Owner to take control of
the platform securely by installing their own platform key or allowing the Operating System install
process to do so.
Лучший выход - coreboot
> Лучший выход - corebootразве там есть Secure Boot?
> разве там есть Secure Boot?Гугель кстати что-то такое писал насчет верификации. Они и к uboot какую-то приблуду накатали.
>> Лучший выход - coreboot
> разве там есть Secure Boot?а где есть? вот повсеместное внедрение restricted boot — вижу. а вот секурности в нём никакой не вижу.
> секурности в нём никакой не вижу.Замок на двери, несомненно, ограничивает доступ в помещение. Однако вопрос в том будет ли ущемлена твоя свобода или нет - сводится к наличию у тебя ключа. Если у тебя есть ключ - как бы ты свободен делать что пожелаешь. А если ключа нет - значит ты посторонний человек, и вовсе не хозяин помещения нифига. Вот это следует понимать.
restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.
> restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.Конкретно UEFI'анство которое запихано в большинство мамок, с проприетарной фирмварой и ключами майкрософта - пожалуй таки да.
>> restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.
> Конкретно UEFI'анство которое запихано в большинство мамок, с проприетарной фирмварой
> и ключами майкрософта — пожалуй таки да.ну дык я именно про то, что сейчас уже имеем, а не про саму идею как таковую. идею-то можно было допилять до чего-то нормального.
> ну дык я именно про то, что сейчас уже имеем, а не
> про саму идею как таковую. идею-то можно было допилять до чего-то
> нормального.Ну так конкретно кернельная реализация в этом плане ничем особо не мешается. И в каком-нить coreboot может быть и вполне честная реализация подобной хрени. Ну ок, как максимум - может какая-то тивоизированная хрень появится лишних пару раз. Учитывая что уефанство тот еще миндфак, кому оно надо и так сделали бы, не так так иначе. А кому не надо - заморачиваться не станут.
> Ну так конкретно кернельная реализация в этом плане ничем особо не мешается.мешает. это официальная поддержка бесполезной вражеской технологии.