Comments 27
Спасибо за инструкцию.
Если Вам не трудно, попробуйте пройти её на реальном железе. Если будут какие-то проблемы, или я что-то забыл добавить в руководство, то я это исправлю.
Ок, я попробую подписать загрузчик на своем ноуте.
Получилось?
Пока не пробовал. Занять немного другой проблемой: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291935
apt-get update && apt-get install mokutil --yes
А из сорцов оно на фре не соберётся?
Не смог найти в портах и через `pkg search` :-(
Что-то мне подсказывает, что эта штука пока существует только под Linux. Дело в том, что эта утилита для управления MOK устанавливает переменной EFI какое-то значение, которое при следующей загрузке приводит к загрузке не shimx64.efi, а mmx64.efi. (посмотрите у себя в /boot/efi/EFI/debian/). В конце своей работы этот загрузчик (если его можно так назвать) сбрасывает значение переменной, и загрузка снова проходит нормально.
Я пробовал собрать mokutil под FreeBSD,там есть ависимость от libkeyutils который под FreeBSD не собирается из-за каких-то специфических зависимостей (заголовочных файлов) от Linux ядра.
Спасибо за статью.
Но хотелось бы прояснить момент. Если я правильно понял, результат поиска доступных загрузчиков из п.2 определяет содержимое boot menu. Собственно вопрос: можно ли настроить так чтобы при обнаружении загрузчика для винды, он не пытался его проверит MOK ключами, и наоборот использовать только MOK для остальных. Почему спрашиваю - все мы люди и после работы иногда играем. А так как работаем ("мы, николай вторый...)))))") в линухе, а играем в батлу на винде возникает проблема дуалбута и переключения профиля ключей в материнке при перезагрузках. Если этого не делать, то или винда не запустит античит или линух продинамит само-сборный (но подписанный MOK) нужный для работы модуль.
Не очень понятен контекст. Расскажу свою ситуацию. У меня три ОС:
Windows 11
Debian Trixie
FreeBSD 15
Загрузчик Windows 11 подписан ключом, который и так есть в UEFI материнской платы (ASUS ROG Strix Z370G), его проверка по умолчанию проходит успешно.
Debian Trixie использует shim-loader, который тоже подписан ключом Microsoft. Не знаю, тем же самым что и загрузчик Windows, или другим, но суть одна: с ним тоже проблем нет.
Драйверы NVIDIA и VirtualBox для Linux подписаны MOK'ом. Им же подписан загрузчик FreeBSD. Благодаря этому я просто включил Secure Boot в режим "Windows OS" и никаких проблем не знаю. Во время загрузки нажал F8, выбрал нужную ОС, нажал Enter, всё (GRUB не видит FreeBSD, но видит Windows). Т. е. если подписать что нужно и поместить ключ в UEFI, то не надо больше теребонькать Secure Boot в настройках материнской платы. Один раз включили и забыли.
Хм, а вот теперь стало интересно. Все тоже самое, только проприетарный модуль для радеон и вмварь. MOK собирал не сам, доверившись установочному скрипту. Подписанные модули так и не завелись с профилем Windows UEFI mode, а при переключение на Other OS уже винда считает загрузку не безопасной.
Весь этот движ для меня начался после того как игры стали требовать безопасную загрузку.
Постараюсь в ближайшее время еще раз проверить.
согласно доке винда все одобрит только если не будет посторонних ключей. Что вполне логично: что мне мешает подписать MOK чит/вирус и загрузить его в винде?
Установочный скрипт обычно работает так:
Создаём приватный ключ, MOK и сертификат.
Подписываем что нужно приватным ключом.
Удаляем приватный ключ.
Заметили чего не хватает? Правильно! Не хватает шага импорта MOK в UEFI. Например, установщик NVIDIA сохраняет MOK по пути /usr/share/nvidia/ в файл с расширением .der. Это наш MOK и есть. Но в какой момент установщик его раскатывает в UEFI? А ни в какой, это надо делать самому.
что мне мешает подписать MOK чит/вирус и загрузить его в винде
Система безопасности Windows, для которой что-то, работающее на уровне ядра, но не имеющее подписи Microsoft, считается угрозой?
Глупый вопрос: вы ведь проверяете в винде состояние безопасной загрузки по выводу msinfo32, а не просто по факту загрузки?
В моём случае я проверяю состояние Secure Boot по состоянию настроек в UEFI.
А можете проверить вывод msinfo32 ? Жаль, но в противном случае это умножает ценность статьи на 0.
В общем в выходные переставил трикси и все собрал аккуратно руками. Все завелось и работает нормально. Атору благодарность за статью. Подробности опишу ниже в ответе тов. @dartraiden
что мне мешает подписать MOK чит/вирус и загрузить его в винде?
Windows проверяет подпись драйверов независимо от того, что там у вас в хранилище, и включён ли Secure Boot вообще.
Если вы хотите загрузить ядерный драйвер Windows, не имеющий подписи MS WHQL, вам придётся, во-первых, отключить Secure Boot (иначе Windows не позволит включить тестовый режим), во-вторых, включить тестовый режим и подписать этот драйвер своим ключом, в-третьих, добавить ключ в доверенные корневые в самой Windows.
(чтобы не усложнять, я специально не упоминаю про такую экзотику как полное отключение проверки подписей (потому что этот режим нужно включать перед каждой загрузкой и для повседневного использования он не предназначен) и известную дыру с кросс-подписями, позволяющую подписывать драйверы утекшими сертификатами в обход WHQL (их осталось мало живых, да и они давно в чёрных списках у популярных античитов)
Подписанные модули так и не завелись с профилем Windows UEFI mode, а при переключение на Other OS уже винда считает загрузку не безопасной.
У майков есть два ключа. Одним они подписывают собственные загрузчики (Windows), вторым - всякое линуксовое добро типа shim, GRUB и т.д.
"Windows UEFI mode" означает "доверять только ключу, которым подписывают винду", что позволяет грузить только Windows.
"Other OS" позволяет грузить то, что подписано не предыдущим ключом
Почему у вас Windows считает Other OS чем-то недостаточно надёжным, я не знаю.
(опять же, я специально упрощаю, говоря про "два ключа", на самом деле, сейчас их уже пять: поскольку те самые "два ключа" в следующем году протухнут, майки выпустили ещё три: пара на замену описанным выше, а третий отдельный для подписи прошивок внешних устройств типа видеокарт).
В винде, в принципе, мне ничего не нужно. Это просто прошивка компа для игр. Собственно моя задача это обеспечить вывод msinfo32 о безопасной загрузке (для работы античита) и нормальную работу самообороных модулей ядра в линуксе без манипуляций с биосом при перезагрузке. Попытка решить это в режиме домохозяйки и стандартными установочными скриптами не увенчались успехом. Работало что-то одно. Судя по тому, что при включённом секъюр буте нормально загружались модули в линуксе при выборе профиля otherOS, МОК таки прописался в материнку. В выходные ещё раз накачу трикси руками и проверю.
Почему у вас Windows считает Other OS чем-то недостаточно надёжным, я не знаю.
Об чем и спич!!! Я так понял это не только у меня, а вообще поведение винды. Я понимаю это, и не против. У меня больше вопрос к производителям материнок: прикрутите возможность привязки профиля ключей к бут меню.
Судя по документации, у асуса Other OS это отключение SB вообще.
https://www.asus.com/ru/support/faq/1049829/
А вам для дуалбута нужно скрафтить свои ключи и добавить к ним ключи Microsoft, как описано в этой статье. Затем в настройках биоса стереть предустановленные и загнать то, что у вас получилось. Таким образом, вы сможете грузить загрузчики Windows, сторонние загрузчики, подписанные Microsoft, а также загрузчики и модули ядра Linux, подписанные лично вами.
В общем, я посмотрел, биос асуса, там Other OS, похоже, означает "выключить Secure Boot", так что выше мои рассуждения про это можно смело пропускать.
Асусу минус в репутацию за то, что не назвал опцию просто и понятно - "Enable Secure Boot"
Да, вы совершенно правы. В моей матринке сработал выбор режима Winodws UEFI и Custom (а не Standart для key management). Моей главной ошибкой была спешка. При импорте ключа и ввода пароля после перезагрузки просто жмякал continue boot. На самом деле надо было пройти квест вроде "чувак, ты уверен?... точно-точно???... ну ок, я предупреждал". т.е. факт ввода пароля вовсе не значил что ключ импортнулся. В итоге после этого все заработало: винда отчиталась что загрузка безопасна и античит в батле заработал нормально, а в линухе модули успешно загружены.
Для себя отметил следующее:
1. делать бэкап - чтобы не плодить ключи, а подписывать одним (в моем случае собрал модули для vmware и virtualbox)
2. если что-то не работает в первую очередь проверить вывод `mokutil --list-enrolled`
3. выбрать какой-то один способ выбора загрузки: F8 boot menu или GRUB - линуху пофигу, а вот в винде слетает Windows Hello и нужно заново авторизовать все учетки
и Custom (а не Standart для key management).
Не скажу, как у асусов, а у гигабайта тут зарыта проверка на внимательность. И я её когда-то не прошёл :)
Во-первых, в режиме Standard блокируется ручное управление ключами. Из-под ОС (известными командлетами PowerShell) их тоже поменять не удаётся.
Во-вторых, после перевода в Custom и приведения ключей в желаемое состояние можно вернуть обратно Standard (например, чтобы какая-то малварь, получившая в ОС права суперпользователя, не воткнула свои ключи). Но при этом прошивка спрашивает "желаете заодно вернуть дефолтные ключи?". И если по запарке ответить "Да", то все сделанные изменения будут уничтожены и ключи примут состояние "как из коробки". Тут я потратил немало времени, пытаясь понять, куда деваются изменения, прежде, чем, наконец, вчитался в то, об чём меня спрашивает прошивка.
mokutil --import MOK.der
А что мешает вирусу сделать то же самое?
После выполнения этой команды нужно ввести пароль. Ну, допустим, инвертированный кейлоггер это сделал. На следующем этапе нужно:
Перезагрузить компьютер. Окей, не сложно.
Загрузить отдельную операционную систему, подписанную уже установленным в UEFI ключом (в Debian Linux это
/boot/efi/EFI/debian/mmx64.efi).В загруженной ОС как-то пронажимать клавиши, чтобы раскатать свой ключ.
Ну, ок, удачи.
FreeBSD, Debian и Secure Boot