☰

UEFI SHIM エラー "verify_buffer() 署名が見つかりません。"

tag-icon • tag-icon linux uefi secure-boot
UEFI SHIM エラー "verify_buffer() 署名が見つかりません。"

続けるMicrosoft署名オペレーティングシステムローダーからロードされたUEFI自己署名カーネル使ったhttps://github.com/rhboot/shim/releases/tag/15.4自分のローカルコンピュータでビルドします（Ubuntu 18.04 LTS）。

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=Your Name/"
openssl x509 -in MOK.crt -out MOK.cer -outform DER

SHIMキー（MOK.cer）を使用するためのソースコードのコンパイル

make VENDOR_CERT_FILE=MOK.cer

コンソールに「Hello World」を印刷するテストバイナリ（grubx64.efiに名前を変更）に署名しました。

sbsign --key MOK.key --cert MOK.crt --output grubx64.efi  test.efi

objdumpツールを使用すると、署名付きgrubx64.efiで有効なSecureDirセクションを表示できます。

objdump -x grubx64.efi

また、sbverifyを使用して署名を確認しました。

sbverify --list grubx64.efi

SecureBootでSHIMを実行すると、SHIMがSHIMキーで署名されたgrubx64.efiをロードしようとすると、次のエラーが発生します。

pe.c:857:handle_sbat() SBAT section data
pe.c:865:handle_sbat() sbat, 1, SBAT Version, sbat, 1, https://github.com/rhboot/shim/blob/main/SBAT.md
pe.c:865:handle_sbat() shim, 1, UEFI shim, shim, 1, https://github.com/rhboot/shim
sbat.c:121:verify_single_entry() component sbat has a matching SBAT variable entry, verifying
sbat.c:182:verify_sbat_helper() finished verifying SBAT data: Success
pe.c:574:generate_hash() sha1 authenticode hash:
pe.c:575:generate_hash() 00000000  XX XX XX XX XX XX XX XX  XX XX XX XX 09 aa c7 09  XXXXXXXXXXXX|....|
pe.c:575:generate_hash() 00000004  1e 6b c6 68 88 a9 e5 88  72 fd 81 08 32 15 2e 24  |.k.h....r...2..$|
pe.c:576:generate_hash() sha256 authenticode hash:
pe.c:577:generate_hash() 00000000  08 16 c3 bd 93 91 a5 0f  3a b4 24 a1 b1 97 5c ee  |........:.$...\.|
pe.c:577:generate_hash() 00000010  47 33 76 37 7f 71 cc b0  c9 82 e0 ac 50 49 0d 0e  |G3v7.q......PI..|
shim.c:630:verify_buffer() check_allowlist: Not Found
shim.c:644:verify_buffer() No signatures found
Verification failed: Security Policy Violation
Failed to load image: Security Policy Violation
shim.c:378 check_allowlist() check_db_hash(db, sha256hash) != DATA_FOUND
shim.c:386 check_allowlist() check_db_hash(db, sha1hash) != DATA_FOUND
shim.c:430 check_allowlist() check_db_hash(MokList, sha256hash) != DATA_FOUND
shim.c:629 verify_buffer() check_allowlist(): Not Found
shim.c:1188 start_image() Failed to load image: Security Policy Violation
start_image() returned Security Policy Violation
Exit status code: Security Violation

どんなアイデアがありますか？

答え1

診断には次のものが必要な場合があります。オペレーティングシステムレベルのmokutilツール。

これを実行すると、mokutil --list-enrolledMOK.cerの証明書情報を取得できますか（同様の出力openssl x509 -in MOK.crt -noout -text）？それ以外の場合は、MOKが正しく登録されていません。エラーリストの次の行は考えられる原因を示しています。

shim.c:630:verify_buffer() check_allowlist: Not Found

shim.c:430 check_allowlist() check_db_hash(MokList, sha256hash) != DATA_FOUND

つまり、UEFI NVRAMという変数がMokList存在しないか、MOK証明書が含まれていません。

MOKの場合、起動時にのみ直接アクセスできるように、MokList新しいUEFI NVRAM変数が作成および保護されます（shimx64.efiおよび/または経由）。これはまた、そのファイルが存在しないため、ファイルを介して直接確認mmx64.efiできないことを意味します。/sys/firmware/efi/efivars/MokList-605dab50-e046-4300-abb6-3dd810dd8b23

コンテンツの2番目のコピーは、MokListRT実行中のOS（/sys/firmware/efi/efivars/MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23Linuxなど）にアクセスできるUEFI変数に存在し、NVRAMに永続的に保存してはいけません。shimx64.efi起動するたびにコピーされるため、OSにMokListRTファームウェアや図のように正しい内容が含まれている場合は、mokutil --list-enrolledパッドにMOKが動作していることを確認できます。

MOKストレージにはUEFI NVRAM変数が含まれているため、残念ながらUEFIファームウェアのバグや実装の問題が発生する可能性があります。時にはNVRAM可変記憶装置を工場出荷時初期化することもできます（より正確にはUEFIファームウェア設定、しかし、古い名前がまだ存在しているようです）。

使用しているシステム/マザーボードの名前に言及できます。セキュアブートおよび/またはUEFI NVRAM変数に既知の問題があり、他の人が回避策を見つけた場合は、ヘルプを入手できます。

関連情報