LINUX.ORG.RU

SecureBoot инсталляции убунты.

 ,


1

1

Всем привет. Надо сделать секурный бут инсталляции убунты под tianocore uefi. на qemu. Ну несекурный бут там простой, а вот как делать секурный вообще не понятно. tianocore требует ключей и всяких там сертификатов, которые непонятно где брать. кто-то с этим вопросом сталкивался?

★★

Вам нужно установить на машину с включеным секюрбутом с заводскими ключами, или удалить майкрософтовские и прочие ключи и установить строго со своими?

Если первый вариант, то мейнстримные дистры искаропке подписаны ключами, которым доверяет большинство (все?) UEFI, и ничего особенного не нужно делать.

token_polyak ★★★ ()
Ответ на: комментарий от token_polyak

там пускается tianocore (это опенсорсная uefi) на qemu, а у него вообще никаких ключей похоже нет. есть возможность их ввести ручками. но где эти ключи - непонятно. если дистр убунты(я его просто 20.04 с их сайта взял) чем-то и подписан…то вопрос - чем? и где это взять… видимо если эти ключи дать этой uefi, то она и загрузит.

то есть - какие ключи - непринципиально, главное загрузить инсталлятор абы как.

то есть, видимо, надо понять, какими ключами подписан инсталлятор, откуда-то их взять,и ввести их этой tianocore… и видимо проблема будет решена.

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 2)
Ответ на: комментарий от token_polyak

так. очень похоже,… как это я сам не нашел… хотя перекопал кучу всего.. спасибо. читаю

alysnix ★★ ()
Ответ на: комментарий от NAY_GIGGER

Если это умеет в secureboot, то вопрос только в том как подсунуть ему эти 4 ключа (точнее хватит и 3-х: PK, KEK и db) и подписывать свой загрузчик и/или ОС этим db.{key,crt}

anonymous ()
Ответ на: комментарий от anonymous

Если это умеет в secureboot, то вопрос только в том как подсунуть ему эти 4 ключа (точнее хватит и 3-х: PK, KEK и db)

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

есть путь проще. когда билдится ovmf (это и есть сама uefi), там делается оказывается и файл памяти ключей(просто это не видно особенно их доков), как будто ты ввел их ручками, ну или их на фабрике записали. и если их подсунуть правильно вместе в самой ovmf в qemu, то вроде бы должно получиться что ты имеешь uefi, с уже зашитыми ключами. а поскольку линуховый дистрибутив уже ими подписан, то останется только перейти в секурный бут в этой уефи, и все должно пройти.

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

Сперва придумают проблему, и потом героически его решают, что «решение» не решает созданную проблему.

есть путь проще

Не использовать secure boot… с ключами от дяди…

Ну несекурный бут там просой

Воспользуйся этим советом. Умный человек писал.

anonymous ()
Ответ на: комментарий от anonymous

Но школота на арче написала краткий экскурс про secureboot

это они написали всю тряхомудь, как нагенерить свои ключи, и как подписывать все что надо, с нуля. для некоей абстрактной, насколько я понял, uefi… ну в конкретике своего ядра и модулей. это не наш путь сейчас.

alysnix ★★ ()
Ответ на: комментарий от anonymous

Не использовать secure boot… с ключами от дяди…

мне лично он даром не нужен. сказали сделать это и написать типа мануальчик.

alysnix ★★ ()
Ответ на: комментарий от alysnix

Там должна быть одна строка «Secureboot не нужен». Кому нужен сами найдут и сделают как надо

anonymous ()
cp /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd .

sudo qemu-system-x86_64 -machine q35,smm=on,accel=kvm -m 2048 -global driver=cfi.pflash01,property=secure,value=on -drive file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=OVMF_VARS.secboot.fd,if=pflash,format=raw,unit=1,readonly=off …
ValdikSS ★★★★★ ()
Ответ на: комментарий от alysnix

Ах вот откуда все эти бесполезные мануальчики.

t184256 ★★★★★ ()
Ответ на: комментарий от ValdikSS

Валдик, с помощью твоей командищи, удалось запустить секурный OVMF из убунтовой(20.04) поставки… там правда файл ключей называется OVMF_VARS.ms.fd, насколько я понимаю.

Но вопрос, - в морде OVMF входишь в Secure Boot Configuration, выбираешь Secure Boot Mode - Custom…. И типа все? Current Secure Boot Mode State - написано disabled… и как понять, что они будет грузить мое ISO в секурной моде?

запуск вообще без OVMF_VARS… дает такую же картину. то есть визуальных отличий нет и непонятно, этот ..vars.fd, ovmf видит вообще?

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

На Fedora OVMF_VARS.secboot.fd уже настроен, ничего дополнительно не нужно делать. Как в Ubuntu — не знаю, смотрите инструкции.

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

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

скрипт для запуска такой - run.sh (если кому понадобится)

opts="-machine q35,smm=on,accel=kvm -m 2048"

#это просто так, не обязательно
opts="$opts -smp 2"

opts="$opts -global driver=cfi.pflash01,property=secure,value=on"

#add two flashes
opts="$opts -drive file=OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on" 
opts="$opts -drive file=OVMF_VARS.ms.fd,if=pflash,format=raw,unit=1,readonly=off" 

##virtual fat disk - where to unstall Ubuntu
opts="$opts -hda fat:rw:hda_"

##virtual cdrom with ubuntu installation
#opts="$opts -boot d -cdrom ubuntu.iso"
#opts="$opts -drive file=ubuntu.iso,index=1,media=cdrom"
opts="$opts -drive file=ubuntu.iso,media=cdrom"

##disable net
opts="$opts -net none"

## to avoid warning that something is not supperted
opts="$opts -cpu host"

##would not run without it!!! if the build has smm support!!!
##at least for me
opts="$opts -global ICH9-LPC.disable_s3=1"

opts="$opts -boot menu=on"
############################  
qemu-system-x86_64 $opts

без этой ВАЖНОЙ опции QEMU не может нормально запустить стоковый ovmf, и просто ругается что графика не инициализирована. QEMU опять же стоковый.

opts="$opts -global ICH9-LPC.disable_s3=1"

нормально пускает секурный бут… правда в самой ovmf вообще непонятно, идет секурный бут или обычный. но ориентируюсь на флаг - secure boot enabled в морде ovmf.

alysnix ★★ ()
Последнее исправление: alysnix (всего исправлений: 3)
Ответ на: комментарий от alysnix

проблема решена. оказывается OVMF_VARS.fd от одного билда(в частности стокового), вовсе не обязана подходить к билду другой версии в частности, билду ручками с последней версии в их гите.

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

alysnix ★★ ()
Ответ на: комментарий от Legioner

В федоре уже всё вшито. Скопируй оттуда.

попробую, но там возможно та же история. они скорее берут какую-нить stable ветку ovmf, а там другой формат VARS, типа как стоковый в убунте

alysnix ★★ ()
Ответ на: комментарий от alysnix

Не очень понял. Там и _CODE и _VARS лежат. Зачем тебе другие форматы? Оба файла копируй и используй в своей виртуальной машине. У меня работает без проблем.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Вот мой скрипт, который запускает RHEL 8:

#!/bin/sh

cd "$(dirname "$0")"

qemu-system-x86_64 \
        -name "rhel8" \
        -uuid "7e2e5ca7-aea7-4f3d-add3-e625f24f6219" \
        -machine q35,accel=kvm \
        -cpu host \
        -smp sockets=1,dies=1,cores=2,threads=1,cpus=2,maxcpus=2 \
        -m 4g \
        -vga virtio \
        -display gtk,zoom-to-fit=off \
        -nic user,model=virtio-net-pci,mac="52:54:00:f8:86:7e",ipv4=on,hostfwd=:127.0.0.1:45022-:22 \
        -drive file="/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd",if=pflash,format=raw,readonly=on \
        -drive file="OVMF_VARS.secboot.fd",if=pflash,format=raw \
        -drive file=disk.qcow2,media=disk,if=virtio,cache=unsafe,discard=off \
        "$@"

Такая конфигурация и федору и убунту и винду запускает.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

ты берешь тут явно стоковую OVMF из дистрибутива - раз у тебя /usr/share… а там уже приготовленная ovmf_vars, с накаченными ключами.

я я билжу ovmf из ихнего гита, и там ovmf_vars без ключей. вот я и думал, что возьму code сбилженый, а vars стоковый. шиш. работает только с сбиженым VARS, со стоковым не работает. то есть ключи туда надо накатывать ручками. вот счаc разбираюсь как.

alysnix ★★ ()
Ответ на: комментарий от alysnix

Ну я тебе и говорю - бери и CODE и VARS из федоры, там ключи микрософтовские уже накачены. Или тебе принципиально последняя версия?

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

последняя принципиально. так попросили. просто бутить в секурной моде со стоковой ovmf, я уж научился. там все просто.

alysnix ★★ ()
Ответ на: комментарий от alysnix

Ну я бы попробовал srpm скачать (или аналог из другого дистрибутива), там по идее должны быть все скрипты, как они туда ключи засовывают при сборке.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

как пишут умные товарищи вот тут - https://github.com/rhuefi/qemu-ovmf-secureboot

To successfully generate a VARS file, we first need an X.509 certificate from a given Linux distribution vendor, so that we can supply it as an SMBIOS "OEM String" to QEMU (via ovmf-vars-generator). Each Linux distribution should provide an X.509 certificate, to be enrolled as Secure Boot Platform Key in OVMF virtual machines.

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

alysnix ★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.