Как Shim проверяет двоичные файлы в безопасной загрузке?

Question 1

Xournal позволяет рисовать в полноэкранном режиме, имеет настройки чувствительности к давлению и может экспортировать в pdf (только, кажется). Я не использовал его для заметок, только для того, чтобы комментировать статьи в формате pdf. Кажется, что автоматическое ручное письмо для преобразования текста отсутствует.

Question 2

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

Question 3

Question 4

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

Question 5

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

Question 6

ответ Каз Вулф довольно хорошо, но я хочу подчеркнуть и развернуть на пару пунктов....

в последний раз я проверил, ШИМ в основном обеспечило своего рода параллельный безопасной проверки загрузки. Это предназначается, чтобы использоваться жратвы, которая предназначена для запуска ядра Linux, которые не являются программами, ели. Таким образом, ШИМ регистрирует себя с ЭФИ таким образом, что позволяет следить за программы для вызова прокладку, чтобы убедиться, что подписанные двоичные файлы. ШИМ делает это одним из двух способов:

ШИМ, встроенный в ключ-самый ШИМ двоичные файлы, в том числе, предоставляемых в рамках убунту, включают встроенный ключей безопасной загрузки. Прокладку под Ubuntu включает в себя открытый ключ канонической, который проверяет Ubuntu в grub и ядра Linux. Этот ключ таким образом, хранящимся в оперативной памяти, и является скорее временным, так как эти вещи идут. Суть ШИМ для обеспечения его последующей программой (жратву) для выполнения безопасной загрузки Тип контроля-но жратву не проверки безопасной загрузки как таковой, как описано в ближайшее время. Без ШИМ, канонические придется полагаться на Майкрософт для входа выхода каждой новой жратвы и каждое новое ядро Linux, которое будет где-то между непрактично и невозможно. Владелец ключей машина (Мокс) -- Мокс, по сути, является продолжением ШИМ встроенный в ключ, но они предназначены для обычных пользователей, чтобы манипулировать. Вы можете использовать Мокс если вы хотите запускать исполняемые файлы не подписаны ключом канонические. Мокс, как прошивку встроенных ключей безопасной загрузки, хранятся в nvram; но они легко добавляются в nvram, через программу под названием MokManager. Получение Мокс в nvram по-прежнему утомительно настолько, что большинство людей не беспокоить, и много людей, которые имеют проблемы с ним, но это проще, чем брать полный контроль над вашим безопасная загрузка подсистемы, как описано в моей странице, которую ты упомянула (управляющий ели Загрузчики для Linux: контроль безопасной загрузки).

в большинстве случаев, Мокс не используются; если вы хотите двойная загрузка Windows и Ubuntu, ты справишься со встроенной прошивки ключи, а ключ, встроенный в оболочку бинарных убунту,. Вы бы использовать Мокс если вы хотите добавить еще один дистрибутив Linux, компиляции собственного ядра, использовать загрузчик, кроме жратвы, использования сторонних модулей ядра, и т. д.

в дополнение к этим двум источникам, есть также ключи безопасной загрузки, встроенный в прошивку. Я не помню, если ШИМ использует эти ключи. Это будет неявно использовать их, если он использует ели [Ф1] и [Ф2] называет (что он делает, но я не рассмотрел контексте этого ответа). Я помню, что ее собственный код проверки не использует ключей безопасной загрузки прошивки, когда жратвы перезванивает, чтобы увидеть, если подписал ядра, но может быть я не правильно помню.

о том, как оболочка интегрируется в безопасной загрузки системы, насколько мне известно, этого не произошло. Если не ошибаюсь, для запуска последующей по программе (жратвы), ШИМ реализующая собственные двоичного кода загрузки, который напоминает урезанную версию кода в образце Tianocore UEFI для реализации. Этот код вызывает прокладку собственного безопасной загрузки проверочный код, который проверяет бинарный против его встроенный ключ и местных МОК списка, чтобы запустить двоичный файл. (Он может также использовать собственные безопасные клавиши прошивки загрузки, но я не уверен в этом.) После жратвы загружается, он вызывает двоично-проверка ШИМ функция для проверки ядра Linux, которая запускает жратвы по-своему (не так, как ели запускает программы, ели). Таким образом, ШИМ не интегрировать себя очень глубоко в прошивку; он просто делает один или два из его функций, доступных для последующей программы, оставив [Ф3] и [F4] для функций ели неизменной.

, что говорит, ели не предусматривает возможности заменить или дополнить обычную систему ели звонки, и некоторые инструменты использовать эти методы. Например, Прелоадер программа, которая является инструментом, чтобы сделать что-то похожее на то, что сим делает, интегрированные себе поглубже в прошивку; раньше ели системные вызовы предназначены для исправления сломанных или устаревших функций для изменения [ф5], так что он хотел проверить косвенно обычных ключей безопасной загрузки UEFI и МОК. Прелоадер очень хорошо упал на обочину, ее разработчики и разработчики сим сотрудничали, чтобы сосредоточиться на прокладку, а не Прелоадер как стандартный инструмент безопасной загрузки Linux. Насколько мне известно, ШИМ не приняло более глубокой интеграции загрузчика установки; однако, это было время, так как я посмотрел на код очень тесно, так что я, может быть устаревшей на этом. Что сказал....

мой собственный изысканный диспетчер загрузки использует код, который я взял из программы Прелоадер для того, чтобы "клей" сим двоичный код в обычный подсистемы проверки в UEFI по. Таким образом, с изысканный на картинке, любая попытка запустить программу с помощью ЭФИ [ф6] и [ф7] называет аутентификации ШИМ код первого и, если это не удается, звонков стандарта UEFI безопасной проверки загрузки второго. В gummiboot/systemd в-загрузки диспетчере загрузки делает что-то подобное. Обе программы делают это потому, что запуска ядра Linux и его загрузчик заглушки ели, что означает, что они полагаются на ЭФИ [F8] и [F9] и звонки. Это контрастирует со жратвой, которая представляет собой полноценный загрузчик, который запускает ядро Linux на свой лад, так что харчи не нужны эти системы ЭФИ призывы признать ключевых оболочки или локальный список МОК.

[dиода d17]я надеюсь, что это помогает прояснить вещи, но я не уверен, что это будет. Подробности о том, как все это работает довольно грязным, и это было время, так как я общался с ними во всех подробностях, так что мои собственные мысли не так организованы, как они могли бы быть.[!dиода d17]

Kaz Wolfe · Accepted Answer · 22 May 2018 в 18:56

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

", только если он не работает, SHIM попытается загрузить stage2 со своим собственным внутренним сертификатом. " Правильно ли сказать тогда, что проворные дураки UEFI, предоставив свой сертификат от имени другого двоичного кода? Однако, хотя UEFI был обманут, SHIM выполнит собственную проверку ключа. Другими словами, есть две проверки (1) проверка ключа UFEI (первая), когда это не удается (2) SHIM предоставляет свой собственный сертификат UEFI и выполняет свою собственную проверку ключа, не используя ключи UEFI, вместо этого ключи, встроенные в SHIM статически , — direprobs, 29 August 2017 в 23:33
Я, честно говоря, не в состоянии понять, что делает SHIM. Насколько я могу судить, SHIM действительно обманывает UEFI, используя свой собственный сертификат, а затем просто произвольно выполняет все, что находит (что подписано). Или, по крайней мере, так я понимаю это сейчас. — Kaz Wolfe, 29 August 2017 в 23:35

Kaz Wolfe · Accepted Answer · 18 July 2018 в 07:43

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

Kaz Wolfe · Accepted Answer · 24 July 2018 в 18:51

Как вы правильно вывели, SHIM попытается сначала загрузить с LoadImage() и StartImage(). Затем EFI проверяет соответствие подписи (используя внутренний механизм SecureBoot). Если LoadImage() возвращает EFI_SECURITY_VIOLATION, система попытается выполнить резервный этап загрузки2 (в данном случае GRUB2) из внутреннего сертификата.

Этот сертификат выпекается в систему во время компиляции, что было сделано Canonical в этом случае. LoadImage() можно извлечь из SHIM с помощью binwalk или аналогичной утилиты.

Эффективно это позволяет SecureBoot иметь проверенную подпись shim, хранящуюся в кеше, которая затем, в свою очередь, разрешает shim проверять, что GRUB был подписан с вышеупомянутым сертификатом. Если это так, GRUB успешно загружается.

SHIM будет использовать системные ключи там, где это возможно - вот почему LoadImage() и StartImage() используются в первую очередь. Только если он не работает, SHIM попытается загрузить stage2 со своим внутренним сертификатом. Вы можете увидеть этот код здесь (часть verify_buffer), который вызывается в цепочке handle_image.

Вся цепочка проверки выглядит так:

Проверить систему хэшей и списком MOK. Убедитесь, что двоичный файл не внесен в черный список. Попытка проверить двоичный файл через белый список MOK / BIOS. Проверяйте внутренние подписи как определено ключом сборки и внутренними ключами SHIM.

Также важно, чтобы MOK Manager не являлся самой базой данных MOK. Последнее поддерживается программным обеспечением EFI, которое принимает команды для добавления / удаления от производителя во время мигания, а также операционной системы (или, в данном случае, shim). shim хранит только очень короткий список вышеупомянутых скомпилированных ключей для загрузки - все остальное должно быть обработано прошивкой EFI.

Rod Smith · Answer 4 · 22 May 2018 в 18:56