The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Верификация загрузки ядра Linux с использованием собственной цифровой подписи

03.09.2013 22:04

Грег Кроа-Хартман (Greg Kroah-Hartman), мантейнер нескольких подсистем ядра Linux и ответственный за поддержку стабильной ветки ядра, сообщил о присоединении огранизации Linux Foundation к группе UEFI.org и подготовил подробную инструкцию с описанием процесса сборки и загрузки самоподписаного ядра Linux на системах с UEFI Secure boot с использованием собственного ключа для верификации неизменности загружаемого ядра и модулей. Ядро собирается в форме бинарного файла EFI и загружается непосредственно прошивкой UEFI, без использования промежуточных загрузчиков.

  1. Главная ссылка к новости (http://www.linuxfoundation.org...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/37812-kernel
Ключевые слова: kernel, boot, uefi
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (57) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:55, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    какой в этом смысл?
     
     
  • 2.50, Murky (?), 19:04, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А смысл такой, что если твое ядро изменит какая-то программа или кто-то захочет поиметь тебя, то оно не загрузится!
     
     
  • 3.51, arisu (ok), 19:15, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А смысл такой, что если твое ядро изменит какая-то программа или кто-то
    > захочет поиметь тебя, то оно не загрузится!

    если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.

     
     
  • 4.52, Аноним (-), 19:35, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.

    А о чем? Готовить ведро вазелина чтоли? В конце концов, проверка целостности системы сама по себе абсолютным злом не является. Если это дадено юзеру под контроль.

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

     
     
  • 5.54, arisu (ok), 19:42, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> если тебя кто-то хочет поиметь, то тут надо не о цифровых подписях думать.
    > А о чем?

    о том, как дошёл до жизни такой.

     
     
  • 6.59, Аноним (-), 07:34, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > о том, как дошёл до жизни такой.

    Так это... проклятые корпорасы же. Ну ты наверное как и я не паяешь 6-слойную плату такого размера у себя на кухне, да? И разводить переростка о 1000 шариков сам наверное не очень мечтаешь, так? :)

     
  • 3.63, Аноним (-), 23:26, 07/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А вы даёте гарантию, что всю эту "верификацию" слишком сложно поиметь, при том, что она вообще не имеет связи с пользователем?

    Если имеют OS это видно в OS. Что и где можно мониторить в этой недо-ос-пере-загрузчике?

     

  • 1.2, Аноним (-), 22:55, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что мешало так сделать раньше?
     
     
  • 2.10, Xasd (ok), 23:37, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А что мешало так сделать раньше?

    то есть -- что мешало написать подробную инструкцию? :)

    да... вопрос интересный...

     
  • 2.33, ананим (?), 09:12, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Отсутствие возможности запихнуть эти ключики в уефи большинства материлок, где живут только ключики мс.
    Ваш кэп.
     

  • 1.4, Аноним (-), 22:59, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Т.е. ад с мелкософтом и ключами закончился?
     
     
  • 2.5, Аноним (-), 23:05, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > Т.е. ад с мелкософтом и ключами закончился?

    Нет, он только начался.

     

  • 1.7, Аноним (-), 23:19, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    это уже не противоречит лицензии? или бинарным будет только загрузчик?
     
     
  • 2.13, Aceler (ok), 23:43, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Это не противоречит лицензии, поскольку здесь нет даже тивоизации — ты собрал ядро из исходников, ты его подписал, ты же его и скормил EFI.

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

     
     
  • 3.16, Аноним (-), 23:54, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    почему? это гарантирует неизменность. что и приследовалось
     
     
  • 4.17, Aceler (ok), 23:55, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > почему? это гарантирует неизменность. что и приследовалось

    От прямой подмены ядра это защитит, но поскольку ключ известен, можно пересобрать ядро и подписать его на той же машине, где оно стоит. Что лишает затею смысла.

     
     
  • 5.19, Пиу (ok), 00:21, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >поскольку ключ известен

    по-хорошему, ключ должен быть известен только владельцу машины. тогда это всё имеет смысл

     
  • 5.24, Аноним (-), 03:15, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > но поскольку ключ известен,

    А откуда кому-то левому известен твой приватный ключ?

     
  • 5.32, VoDA (ok), 08:41, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ключ не известен. Но *возможность* сгенерить собственный ключ и подписать уже им - гарантия защиты от тивоизации и выполнение GPLv3. А с v2 еще проще ;)
     
  • 5.37, Аноним. (?), 12:05, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не лишает. Тот кто не хочет возиться с перекомпиляцией нисколько не пострадает от подобного. Но в организациях, к примеру, для хранения приватных ключей можно выделить специальный не подключенный к сети комп.
     
     
  • 6.38, arisu (ok), 15:45, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Не лишает. Тот кто не хочет возиться с перекомпиляцией нисколько не пострадает
    > от подобного. Но в организациях, к примеру, для хранения приватных ключей
    > можно выделить специальный не подключенный к сети комп.

    если в организации некто неучтённый самовольно заменил ядро — то проблема там совсем-совсем не в ключах…

     

  • 1.8, KT315 (ok), 23:27, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Пока еще не встретил десктопную материнку с неотключаемым UEFI Secure Boot и он даже отключен по умолчанию (Asus, AsRock)
     
     
  • 2.11, Xasd (ok), 23:42, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пока еще не встретил десктопную материнку с неотключаемым UEFI Secure Boot и
    > он даже отключен по умолчанию (Asus, AsRock)

    на некоторых материнских платах есть дополнительная строчка (но зачем её подумали?) которая обозначет название операционной системы которая предполагает загружаться.

    там может быть знчение "Microsoft Windows" или "Other".

    тыг вот бывает такое что пока не выбирешь "Other" -- нельзя отключить Secure Boot.

    такая ситуация может заставлять людей -- писать на форумах о том что Secure Boot якобы не отключается..

     
  • 2.34, NikolayV81 (?), 10:55, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ноутбуки :(
    А так же скорость старта, для того-же ноута к примеру.
     
     
  • 3.35, KT315 (ok), 11:34, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На материнках AsRock c "ГУАШ" 3 опции:
    - normal
    - "quick" (точно не помню, разница с normal 1-2сек).
    - Fast <- вот тут, если переключить сюда рубильник, то нужна Win8 что бы отменить его, т.к. в UEFI не зайти (так пишет встроенная справка UEFI).

    Ноуты, не сталкивался, т.к. собирал обычный дэсктоп. Но думаю, что это в основном будет как в материнках, проблема лишь в том, что в предустановленной Win8, "FAST" может быть включен по дэфолту. Тут появляется 2 проблемы:
    - что делать, если мы отказываемся от Win8? в этом случае нужно отключить "FAST", но не заходить в Win8 (не соглашатся с лицензией, не активировать и т.д., что бы не обвинили в ее использовании).
    - если сбросить в дэфолт UEFI, в каком режиме он будет? Если в "FAST", то это печалька...

    Кто сталкивался с Win8 на ноуте, отпишите плиз, очень уж интересно знать. Не покупать же ноуты для проверки :-D

     
     
  • 4.42, Xasd (ok), 16:42, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    чтобы отключить FastBoot разве обязательно нужно Win8 ?

    нельзя чтоле загрузиться из загрузочного linux-USB-образа и выставить режим "Reboot to EFI Setup"

    ну GUMMIBOOT же!!

     
     
  • 5.45, Антоним (?), 23:08, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А для того чтобы загрузится с USB, надо отключить FastBoot.
     
  • 4.46, Michael Shigorin (ok), 01:22, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто сталкивался с Win8 на ноуте, отпишите плиз, очень уж интересно знать.
    > Не покупать же ноуты для проверки :-D

    С невозможностью попасть в фирмварь по причине ещё не инициализированного USB при включении fast boot _пока_ не сталкивался, но читал.

     

  • 1.12, Аноним (-), 23:42, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вообщем, вроде нормально. Как и предполагал лучший выход - самоподписаные ключи. С помощью опенсорс утилит удаляешь (предварительно сохранив) пришедшие с ноутом ключи и ставишь на их место свои. И подписываешь свое собранное ядро. Плохо что ФС ФАТ.И загрузчик уэфи закрытый.
     
     
  • 2.18, Аноним (-), 23:56, 03/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    uefi открытый, а вот реализация от AMI проприетарная.
     
     
  • 3.25, Аноним (-), 03:16, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > uefi открытый, а вот реализация от AMI проприетарная.

    "Теоретически, Петька, мы с тобой миллионеры. А практически..."

     
  • 2.36, KT315 (ok), 11:50, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На самом деле, FAT это не плохо, по простой причине - он ВЕЗДЕ поддерживается, если только намерено не вырезается.
    ИМХО, содержимое /boot очень редко когда меняется, поэтому журнал для этого раздела не критичен, т.к. там нет критически важных и уникальных декументов и файлов, и которые легко восстановить, если уже такое произошло. И скорость не важна, т.к. 99,9% использования этого раздела - только чтение и ядро с initramfs весит до пары десятков мегабайт.

    Другое дело, патентные разбирательства со стороны Мелкософта, а вот с этой точки зрения, следовало бы им выбирать патентно-чистую дэфолтно-поддерживаемую файловую систему.

     
     
  • 3.41, Аноним (-), 16:37, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    fat используется не для /boot, а для EFI Partition.
     
     
  • 4.43, Xasd (ok), 16:52, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > 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 на компьютере.

     
     
  • 5.47, Michael Shigorin (ok), 01:25, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы, простите, заткнётесь на тему 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.

     
     
  • 6.49, Xasd (ok), 18:46, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Вы, простите, заткнётесь на тему UEFI

    да, я затыкаюсь :-) ..

    доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :).

    кто хочет -- тот может проверить #43 -- на любом современном компьютере. я лично проверял на нескольких.

    кому особо не интересно -- может не проверять, а вместо этого верить в то во что хочет верить :)..

    а вот болтовня на форуме -- ну точно ни чего не изменит :-)

     
     
  • 7.60, Аноним (-), 07:38, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :).

    Наверное потому что такие глупые скрипткидисы как ты понимают что тут что-то не так только когда уже "ААА!!! Kurwa!!!".

    > я лично проверял на нескольких.

    Очень репрезентативная выборка - опробовать пару писюков из миллиарда.

     
  • 7.62, Michael Shigorin (ok), 17:03, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Вы, простите, заткнётесь на тему UEFI
    > да, я затыкаюсь :-) ..

    Спасибо.  И меня не стесняйтесь заткнуть, когда чушь несу.

    > доказывать что белое это белое а чёрное это чёрное -- не вижу смысла :)
    > кто хочет -- тот может проверить #43 -- на любом современном компьютере.
    > я лично проверял на нескольких.

    И всё-таки идите на rodsbooks учить матчасть.  Как вариант -- показывайте выхлоп gdisk -l /dev/sdX и ls /sys/firmware/efi с таких машин для предметного продолжения разговора.

     

  • 1.14, Аноним (-), 23:44, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    исправление - самоподписаное ядро. Еще рамдиск надо или в ядро встраивать или обходиться без него.
     
     
  • 2.28, Аноним (-), 07:37, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Просто оставлю здесь 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
     
     
  • 3.29, Аноним (-), 07:51, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    initrd у тебя не подписаный.
     
  • 3.30, Аноним (-), 08:00, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто оставлю здесь 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

    Also, 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.

     
     
  • 4.39, arisu (ok), 15:48, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > if you want to use one, you need to build it into
    > the kernel itself.

    не понятно только, нафига тогда вообще этот initrd нужен в таком случае.

     
  • 3.31, Аноним (-), 08:03, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто оставлю здесь 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

    и ядро у тебя сегодня майкрософт подписала, а завтра передумала.

     
     
  • 4.48, Crazy Alex (ok), 13:12, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Передумала, сперла с ЛОРа libastral.so, залезла через него на комп и прибила ключ? Не говоря о том, что отзыв ключа всегда влечет такие проблемы, что его даже по серьезным причинам частенько не делают.
     
  • 3.44, Xasd (ok), 18:12, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Просто оставлю здесь 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" -- не обязателно :)

     

  • 1.15, Аноним (-), 23:50, 03/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    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.
     
  • 1.20, Аноним (-), 00:28, 04/09/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Лучший выход  - coreboot
     
     
  • 2.22, Xasd (ok), 02:51, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Лучший выход  - coreboot

    разве там есть Secure Boot?

     
     
  • 3.26, Аноним (-), 03:18, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > разве там есть Secure Boot?

    Гугель кстати что-то такое писал насчет верификации. Они и к uboot какую-то приблуду накатали.

     
  • 3.40, arisu (ok), 15:48, 04/09/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> Лучший выход  - coreboot
    > разве там есть Secure Boot?

    а где есть? вот повсеместное внедрение restricted boot — вижу. а вот секурности в нём никакой не вижу.

     
     
  • 4.53, Аноним (-), 19:39, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > секурности в нём никакой не вижу.

    Замок на двери, несомненно, ограничивает доступ в помещение. Однако вопрос в том будет ли ущемлена твоя свобода или нет - сводится к наличию у тебя ключа. Если у тебя есть ключ - как бы ты свободен делать что пожелаешь. А если ключа нет - значит ты посторонний человек, и вовсе не хозяин помещения нифига. Вот это следует понимать.

     
     
  • 5.55, arisu (ok), 19:43, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.
     
     
  • 6.56, Аноним (-), 22:00, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.

    Конкретно UEFI'анство которое запихано в большинство мамок, с проприетарной фирмварой и ключами майкрософта - пожалуй таки да.

     
     
  • 7.57, arisu (ok), 22:34, 05/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> restricted boot — это решётка посреди комнаты: и не защищает, и ходить мешает.
    > Конкретно UEFI'анство которое запихано в большинство мамок, с проприетарной фирмварой
    > и ключами майкрософта — пожалуй таки да.

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

     
     
  • 8.58, Аноним (-), 05:25, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так конкретно кернельная реализация в этом плане ничем особо не мешается И в... текст свёрнут, показать
     
     
  • 9.61, arisu (ok), 15:51, 06/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    мешает это официальная поддержка бесполезной вражеской технологии ... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру