[過去ﾛｸﾞ] システムバックアップソフト徹底比較30 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
654(1): 2025/04/01(火)03:26 ID:44P2ofaM0(8/15) AAS
外部ﾘﾝｸ:github.com
MOKとは何ですか?
MOK(Machine Owner Key)は、UEFIブートローダーに署名してセキュアブートの準備をするために使用できるキーです。
あなたは実際のところ何もわかっていないようですね
655: 2025/04/01(火)04:15 ID:44P2ofaM0(9/15) AAS
>マイクロソフトは今までのshimを無効化したので2024年夏以降linuxで問題になっている
何故マイクロソフトが関係あるのでしょうか？
UEFIファームへとマイクロソフトがWindowsUpdateで書き替えたとは書いてあるけれども本当なのでしょうかね？
だったらLinuxオンリーの人達には全く関係ないことですよね
656: 2025/04/01(火)04:49 ID:44P2ofaM0(10/15) AAS
外部ﾘﾝｸ[html]:docs.oracle.com
フェーズ1: Shimソフトウェアがロードされます。UEFIは、Shimの署名に使用された署名を最初に検証します。署名が有効な場合は、Shimのロードを続行できます。それ以外の場合、Shimをロードできません。その後、ロードされたShimによってすべてのコードが検証されます。Shimによって独自のMOKデータベースが維持され、そこには検証のための他のキーが格納されます。
こう言う事でこの説明がブートローダーであるbootx64.efiでしょ
WindowsのユーザーもそうだけどLinuxの方だってわかっていないバカだらけだよな
657(1): 2025/04/01(火)04:53 ID:9PPCzRTB0(1/2) AAS
なんのスレだよ
658(2): 2025/04/01(火)05:18 ID:44P2ofaM0(11/15) AAS
外部ﾘﾝｸ:docs.redhat.com
4.マシンを再起動します。
shim ブートローダーは、保留中の MOK キー登録要求を認識し、MokManager.efi を起動して、UEFI コンソールから登録を完了できるようにします。
\EFI\BOOT\MokManager.efi
Ventroyにも確かにあるわ
659: 2025/04/01(火)05:25 ID:44P2ofaM0(12/15) AAS
>>657
バックアップソフトのPEも含めたブートスレだろうよ
最近ではSecure Bootも考慮する必要があるからLinuxユーザーは知っていないとならないぞ
バカはどうせわからないんだから変なネタを上げない方がいいぞw
660: 2025/04/01(火)05:26 ID:9PPCzRTB0(2/2) AAS
シーザーを読むのにシーザーである必要はない
661: 2025/04/01(火)12:10 ID:7MBhBCFc0(5/7) AAS
>UEFIファームへとマイクロソフトがWindowsUpdateで書き替えたとは書いてあるけれども本当なのでしょうかね？
そこまで調べておいて本当なのでしょうかねとか、認知的不協和だな。
>だったらLinuxオンリーの人達には全く関係ないことですよね
あるカテゴリーに関係ない人がいることはどうでもよくて、
関係ある人がいることが問題なんだが。
LinuxオンリーであってもMBメーカーのUEFIアップデートでその部分を更新しているものがあれば
それを当てれば問題が起きる。
バックアップソフトはLiveメディアをLinuxベースのツールで使うこともあるので、
Windowsユーザーであってもかかわる問題。
662(1): 2025/04/01(火)15:49 ID:44P2ofaM0(13/15) AAS
「Verfication failed:(0x1A)Security Violation」
\EFI\BOOT\MokManager.efi がある場合には、bootx64.efiやgrub.efiにUEFIの有効な署名がないとこのエラーメッセージが表示されるって事なんだろうと思う
そしてLinuxのgrub.efiだとUEFIファームウェア側に有効な署名が登録されていないのでMokManager.efi経由で署名の登録を実行するって事になっているんだと思う
Ventoyの場合には、別なマシン上でSecure Bootを実行すると再び署名の再登録を要求されるようになるので各マシンのUEFIファームウェア内のテーブルに登録されているはずだと思う
外部ﾘﾝｸ[html]:docs.oracle.com
UEFI Secure Bootデータベース・キー(DB)
多くの場合、このキーは、ブート・ローダー、ブート・マネージャ、シェル、ドライバなど、実行するバイナリの署名または検証に使用されるため、セキュア・ブートに関連付けられています。ほとんどのハードウェアには2つのMicrosoftキーがインストールされています。1つはMicrosoftが使用するためのキーで、もう1つはShimなどのサードパーティ製のソフトウェアに署名するためのキーです。一部のハードウェアには、コンピュータの製造業者または他のパーティが作成したキーも付属しています。データベースには様々な目的に応じて複数のキーを保持できることに注意してください。また、データベースには、秘密キー(複数のバイナリの署名に使用できる)と照合される公開キーとハッシュ(個々のバイナリを記述する)の両方を含めることができます。
Machine Owner Key (MOK)
DBXと同等で、このキー・タイプはブート・ローダーや他のEFI実行可能ファイルを署名し、個々のプログラムに対応するハッシュを格納するためにも使用できます。MOKはセキュア・ブートの標準部分ではありません。ただし、ShimおよびPreLoaderプログラムでは、キーとハッシュを格納するために使用されます。MOK機能は、新しく生成されたキー・ペアと、それらで署名されているカーネル・モジュールをテストするための理想的な方法です。MOKキーはMOKデータベースに格納されます。MOKデータベースについてを参照してください。
663: 2025/04/01(火)16:08 ID:44P2ofaM0(14/15) AAS
仕様を理解する事は重要だが、実際にはそれを実行しているものの側面から解析してみないと中々実体までは把握出来ないものであるw
664(2): 2025/04/01(火)16:46 ID:44P2ofaM0(15/15) AAS
>MOK リストの鍵がプラットフォームキーリング (.platform) に追加されます。
このような記載があるが、じゃあ(.platform)ってのはどこにあるんだよって話しになる
詳しくはネット上にも書かれていないようだ
665: 2025/04/01(火)20:23 ID:7MBhBCFc0(6/7) AAS
>>654
何のためにMOKがあると思ってるんだ？
それさえわかってない
あれだけ連投してなにもわかってないんだからなあ…
666(4): 2025/04/01(火)23:41 ID:7MBhBCFc0(7/7) AAS
まとめ
VentoyはSecure Boot時において
・shim（Secure Bootの仲介プログラム）をまず起動し
・GRUB 2(Bootloader)を起動、実行できない場合はMokManagerを起動
大まかにこの流れをたどり
MokManagerでMOKを登録するの手順の解説が
>637の貼ったURLであるが
>632の内容は
Rescuezillaは最初に起動するべきshimのバージョンが古いことによる問題で起動しないので、
shimが起動してからMokManagerが起動することが前提の>637のURLの話は
一切関係のない話だし参考にならない。
実際は本人が何もわかっていなかった案件。
Ventoy自体も同じ問題があった過去がありその際はあたらしいshimを組み込んで対策をした。
外部ﾘﾝｸ:github.com
667(3): 2025/04/02(水)01:09 ID:Ep/yh/Gl0(1/22) AAS
>>664 答えはなんじゃろなってのがひとつ
>UEFI Secure Bootデータベース・キー(DB)
>ほとんどのハードウェアには2つのMicrosoftキーがインストールされています。1つはMicrosoftが使用するためのキーで、もう1つはShimなどのサードパーティ製のソフトウェアに署名するためのキーです。
早速その説明だと矛盾していますよw
他人の土俵で知ったような説明をするのは止めて下さいねw
668: 2025/04/02(水)01:29 ID:Ep/yh/Gl0(2/22) AAS
チャーテル
on Nov 6, 2024 ·tschertelによって編集されました
Redditで機能する良い解決策を見つけました:
Ubuntuの代わりにFedora41を使用しました。
最新のUbuntuデスクトップISOをダウンロードします。
ISOとVentoyEFIパーティションをマウントします(ディスク/ディスクマネージャーを使用)。
BOOTX64.efiとmmx64.efiをISO からVentoyEFIの/EFI/BOOTにコピーします。
VentoyEFIの/EFI/BOOTにあるgrub.efiの名前をgrubx64.efiに変更します。
再起動すると、機能するはずです。
すでに投稿されているソリューションに加えて、リストされているfedoraパッケージではなく、UbuntuISOからファイルをコピーできます(情報については、この投稿に感謝します)
この投稿を参考にするとあなたがその偉そうに書いているshimの実体はBOOTX64.efとmmx64.efiとgrubx64.efiだと思いませんか？
それとgithub.comにいる一部の人は信用出来ますが、外野の人間はこのスレと同等で書かれている内容は信用出来ませんよねw
669(1): 2025/04/02(水)02:08 ID:Ep/yh/Gl0(3/22) AAS
>Rescuezillaは最初に起動するべきshimのバージョンが古いことによる問題で起動しないので、
これって、まず最初にgrubx64.efiなどが実際にエラーになっていて物理的に起動しない場合と、
デジタル署名問題でUEFI側から起動を拒否されている2点を考慮しなければならないはずですよ
何か言っている事がいつも矛盾しているんですよねw
670(1): 2025/04/02(水)04:04 ID:Ep/yh/Gl0(4/22) AAS
rescuezilla-2.5.1-64bit.noble.iso の中身になります
\EFI\BOOT
BOOTIA32.EFI
BOOTx64.EFI
grubx64.efi
仮想環境でブートしてみましたがこの最新バージョンはSecure Bootでも普通に起動しますね
671(1): 2025/04/02(水)04:19 ID:Ep/yh/Gl0(5/22) AAS
そもそも疑問なんだが 1,414,330,368バイト
この程度の容量のものをRufus経由でブートする必要があるのか？
Ventoyに.isoのままぶっ込んでみたがちゃんとSecure Bootで起動したぞ
672(1): 2025/04/02(水)04:25 ID:Ep/yh/Gl0(6/22) AAS
>>632 >>638
明らかにおま環要素が強いものをさぞ一般的な不具合のようにそれらのリンクを偉そうに貼り付けるってのはどうなのよ？
自分では全く未検証なのに単純にググって来たとしか思えないぞ
673: 2025/04/02(水)04:36 ID:Ep/yh/Gl0(7/22) AAS
まあいいからもう現れるんじゃないぞw
674(2): 2025/04/02(水)06:43 ID:Ep/yh/Gl0(8/22) AAS
現行のrufus-4.6.exeとrescuezilla-2.5.1-64bit.noble.isoの組み合わせでUSBメモリを作成しました
別に何のエラーメッセージも表示されずに普通に生成されましたね
面倒なので仮想環境上からブートしてみましたが、Secure Bootとして正常に起動しました
ただ黒画面のままrescuezillaは、しばらくの間起動が止まったままになっているようです
遅過ぎるので障害と言えば言えるでしょうかね
675: 2025/04/02(水)08:02 ID:OyddWEwR0(1/7) AAS
>>667
それのどこが矛盾してるのか
一つはマイクロソフトがWindows側のローダーなどで使っている
もう片方をマイクロソフトがshimに使っているだけの話
>>669
>>672
実際にとある起動するするしないのはなしではなく
shimが古いことによる問題があるから原理的に起動しない（SBATが更新されていれば）といっている
矛盾しないよ
理解力ないね
>>670
SBATが更新されていなければ起動するわなｗ
>>671
外部ﾘﾝｸ:github.com
Ventoyの作者自身が書いているが
VentoyをつかってイメージをブートするとSecure Bootがバイパスされる
なので起動するのは当たり前
問題はVentoyを使っていればバイパスされるのでセキュリティ的に意味がない
676(2): 2025/04/02(水)08:04 ID:OyddWEwR0(2/7) AAS
>>674
SBATが更新されない環境で起動してもいみがないよ。
やっぱり意味わかってないなｗｗ
677: 2025/04/02(水)08:38 ID:Ep/yh/Gl0(9/22) AAS
>>674 もちゃんと見なよ
偉そうにしていないで >>664 の答えはなんじゃろなってのがひとつ
678(4): 2025/04/02(水)09:17 ID:Ep/yh/Gl0(10/22) AAS
第444回
Ubuntuにおけるセキュアブートの仕組み
外部ﾘﾝｸ:gihyo.jp
そこでUbuntu（やFedora）は、GRUBより一段前にMicrosoftの鍵で署名されたshimブートローダーをはさむ方法を採用しました。もともとMicrosoftはdb用に2つの鍵を持っています。
Microsoft Windows Production PCA 2011（PCAファイルへのリンク）
Microsoft Corporation UEFI CA 2011（UEFI CAファイルへのリンク）
はい ここから読んでね
内容をわかっている人が結構と詳しく書いています
ここで言っている後者のは、PCR7 バインド不可になるものと関係していますよね
あなたは以前どこかのスレでこの内容に関わっていてデタラメ放題でしたねw
679: 2025/04/02(水)09:40 ID:OQadtBv/0(1) AAS
こりゃきつい
こりゃきついわ
680(1): 2025/04/02(水)10:37 ID:Ep/yh/Gl0(11/22) AAS
外部ﾘﾝｸ:github.com
ヴェントイ on Jan 9, 2021 ·Ventoyによって編集されました
全くそういうわけではありません。
Ventoyは、ISOファイル(例:Ubuntu.iso)内にカーネルを直接ロードしません。
Ventoyは、ISOファイルに基づいて仮想cdromデバイスを作成し、ISOファイル内のbootx64.efi/shim.efiにチェーンロードするだけです。
したがって、前述のように、セキュアブートソリューションはその場しのぎであり、それがVentoyがまだ1.0.XXである理由です。
比較的完璧なセキュアブートソリューションになるまで、1.1.0をリリースしません。
読んでは見たがそもそも日付が古過ぎ
それとデタラメを書き過ぎ
このスレと一緒だわw
現バージョンはこれ
Ventoy2Disk.exe 2025年2月24日、20:21:26
681(3): 2025/04/02(水)12:17 ID:OyddWEwR0(3/7) AAS
>>678
誰かと勘違いしてるね
恥ずかしいｗｗ
その二つの鍵の話は
>667への回答で論破済み
>>680
直接ロードをしないといっているだけでSecureBootのチェーンが切れていないことにならないよ
そして古さは何も否定しないよ
君が否定したいなら
Ventoyのアップデートのどこで○○がどう変わっているから今は違うと指摘すればいいだけ
それができないから古いってレッテル張りしてるんでしょ
実際に変わってないから指摘できない
ひどい奴だな
そもそもそのisue、Openだから未解決
そんなことも知らないでレッテル張りしてるのかｗｗ
682(1): 2025/04/02(水)15:26 ID:Ep/yh/Gl0(12/22) AAS
ダメだこいつは 何も理解しやしない
もう来んなよ バカが
683(1): 2025/04/02(水)15:32 ID:Ep/yh/Gl0(13/22) AAS
もう嫌なので誰かこのバカに意見してやってくれ
流石にバカだよな
684(1): 2025/04/02(水)17:17 ID:Ep/yh/Gl0(14/22) AAS
Ubuntuの起動時に SBAT self-check failed:Security Policy Vioration のエラーが出てしまう際の解決策
外部ﾘﾝｸ:qiita.com
>>676
>SBATが更新されない環境で起動してもいみがないよ。
これへの反論です
仮想環境含めてWindowsUpdateは最新となっているWindows 11ですよ
全然わかっていないのはあなたの方でしょうw
それと単語だけ出すのは止めなさいよ
関連しているものの連携を理解していない証拠です
それとあなたが得意気煮出して来るshimですが >>678 のリンク先に書いてあるshimブートローダーの事だと考えていいですか？
だったら既に認識が間違っているのに気付いているはずですよねw
685(1): 2025/04/02(水)17:23 ID:Ep/yh/Gl0(15/22) AAS
>>681
>667への回答で論破済み
何を論破しているのか さっぱりわからないので詳しく説明してくれよ
686: 2025/04/02(水)17:55 ID:Ep/yh/Gl0(16/22) AAS
そもそも >>632 の書き込みはgithubからのパクリネタだろうし、
偉振って書きたかっただけではないのか？
687(1): 2025/04/02(水)18:01 ID:Ep/yh/Gl0(17/22) AAS
>>676
なに？VMware環境とかだとSBATがWindowsUpdateで更新されないのか？
実環境のWin11でもブートしてみたが同じ結果だってけどなw
688(2): 2025/04/02(水)20:15 ID:Ep/yh/Gl0(18/22) AAS
>>678
そこでUbuntu（やFedora）は、GRUBより一段前にMicrosoftの鍵で署名されたshimブートローダーをはさむ方法を採用しました。
Microsoft Corporation UEFI CA 2011（UEFI CAファイルへのリンク）
これでひとつ思い出した
shimブートローダーへの署名はマイクロソフトへと要求して発行されたものじゃないとなりません
私が書いたそれらのソフトには警告も出ませんでしたのでUEFI CA 2011で署名済みのものであると思います
RufusとRescuezilla共にね
もうひとつはVentoyでやっているUEFI署名方法はまた別な方式であるって事です
区別して下さい
689(1): 2025/04/02(水)20:58 ID:Ep/yh/Gl0(19/22) AAS
>>681
>直接ロードをしないといっているだけでSecureBootのチェーンが切れていないことにならないよ
これを検証するにはVentoyの現バージョンへと署名のないshimブートローダーを持つISOをぶち込んで起動したらわかるよ
拒否されずにブートするのであったらVentoy経由ではSecure Boot時にも現バージョンでもまだ無視されるって事だな
690: 2025/04/02(水)22:26 ID:3r8RPv1e0(1) AAS
ひとりでいつまでやるんだ？
691: 2025/04/02(水)22:29 ID:OyddWEwR0(4/7) AAS
>>682,683
負け惜しみしかいえないｗ
>>684
何の説明にもなってないなｗｗ
現に君がはっているＵＲＬで起きてる事象だよ
それがventoyuserにもおきてフォーラムで報告があり
それの対策にshimを修正したとある
いい加減にしろよ
>>685
>何が矛盾してるのかさえ説明できない○○に言っても仕方がないな
692: 2025/04/02(水)22:29 ID:OyddWEwR0(5/7) AAS
>>687
SBAT確認してみｗｗ
おま環
>>688
Ｖｅｎｔｏyのshimブートローダーへの署名も同じ方法
まだ理解できてないのかよｗｗ
>>689
だから君が否定する条件書いたでしょ
>681
693: 2025/04/02(水)23:08 ID:Ep/yh/Gl0(20/22) AAS
何台か確認した結果、BIOSのUEFIにおま環があるようだな
セキュアブートの項目内に「MS UEFI CAキーの有効化」ってのがあるものがある
Intel CPUでAMI BIOSのものにはあった
Linux系だとこいつが有効化されていないとブートしないよな
これを知らないおま環の人がLinux系でブートしないと言っているのではないのかな？
現バージョンのRescuezillaのISOを展開してUSBメモリのFAT32領域へとそのままコピーしてブートしてみましたが
問題なくSecure Bootで起動しましたのでMicrosoft Corporation UEFI CA 2011でshimブートローダーに署名が入っているようです
ブートしないって言う人はSecure Bootの項目を見直して下さい
現バージョンのVentoyで最初のエラー画面が表示されないで拒否画面になってしまう人もおま環ですね
694(1): 2025/04/02(水)23:14 ID:Ep/yh/Gl0(21/22) AAS
もう一度書くよ
おまえは何もわかっていないのがよく分かったのでもう相手にしないよw
695: 2025/04/02(水)23:29 ID:OyddWEwR0(6/7) AAS
>Linux系だとこいつが有効化されていないとブートしないよな
○○まるだし
それが原因ならSBAT適用を削除して動くようになるわけないだろｗｗ
それにエラーメッセージがそもそも違うしな
>>694
どうわかってないのかを書けよｗｗおまえがわかってないだけだろ
Ventoyのshimはマイクロソフトのキーを使って署名してないって言うぐらいだからなｗｗ
696: 2025/04/02(水)23:33 ID:Ep/yh/Gl0(22/22) AAS
短文のバカw
697: 2025/04/02(水)23:34 ID:OyddWEwR0(7/7) AAS
自己紹介乙
698: 2025/04/03(木)00:01 ID:LmfDFyXp0(1/20) AAS
その項目があって無効になっているとRufusもSecure Boot時にはエラーメッセージが発生してストップしますね
699: 2025/04/03(木)00:05 ID:neDPEm+v0(1/7) AAS
そうSBATの環境関係ないんだよね
それなのに混ぜる○○
700: 2025/04/03(木)01:26 ID:LmfDFyXp0(2/20) AAS
セキュアブートの項目内に「MS UEFI CAキーの有効化」ってのがあるUEFIファームだと
デフォルト設定にBIOSをリセットした場合にはこれが無効になるようですので、
Microsoft Windows Production PCA 2011のみの署名が有効化されます
つまりは、マイクロソフトのOS、マイクロソフトのインストールメディアにある
\efi\boot\bootx64.efi 以外からはSecure Bootが出来なくなります
調べたらこんな事になっていますね
701: 2025/04/03(木)01:52 ID:LmfDFyXp0(3/20) AAS
Windows Server で PCR7 の構成が "バインド不可" と表示される
外部ﾘﾝｸ:learn.microsoft.com
OS上での話しとなりますがこれとの関連項目です
702(5): 2025/04/03(木)02:55 ID:LmfDFyXp0(4/20) AAS
2024 年 8 月のセキュリティ更新プログラムは、デュアルブート セットアップ デバイスでの Linux ブートに影響する可能性があります
外部ﾘﾝｸ:learn.microsoft.com
大事な： この既知の問題は、2024 年 8 月のセキュリティ更新プログラムとプレビュー更新プログラムのインストールでのみ発生します。 2024 年 9 月のセキュリティ更新プログラム (KB5043076) 以降の更新プログラムには、この問題の原因となった設定は含まれていません。 2024 年 9 月の更新プログラムをインストールする場合は、以下の回避策を適用する必要はありません。
だとよw
703(1): 2025/04/03(木)03:13 ID:LmfDFyXp0(5/20) AAS
Ventoyの場合にはUEFIの署名がUEFIファームのテーブル内に存在していない場合に、
>>658 の処理が実行可能な画面を表示するって事になるな
どの部分になるかはその先生が解説してくれると思うw
別マシン上だとまた表示されるんだからな・・・
704(2): 2025/04/03(木)04:50 ID:neDPEm+v0(2/7) AAS
>>702
意味わかってる？
SBAT確認してみｗｗ
が正しかったという事だな
705: 2025/04/03(木)05:04 ID:neDPEm+v0(3/7) AAS
>>703
>658で自身で書いた意味がまだ分かっていなさそう
そこに書いてあるように、MokManager.efiを起動させるのはshimが行っているので
shimがロードされている前提なんだよ
つまりshimの署名検証がすんではじかれなかったらそうなる
>666のまとめ通り
706: 2025/04/03(木)11:30 ID:3aF++OwQ0(1) AAS
え？なにこれ、まだやんの？
707: 2025/04/03(木)12:25 ID:frc+gUG20(1) AAS
レスバが気になって夜も寝られないんだろう
708: 2025/04/03(木)14:37 ID:4DQhGyO70(1) AAS
ID真っ赤になるまで書いてるのはただのガキだろ
相手が間違ってるの解ってるんだったらほっときゃいいのに
それで不利益被ろうが自分のは関係ない話だろ
709(1): 2025/04/03(木)15:12 ID:LmfDFyXp0(6/20) AAS
Linux関連のSecure Bo704otに疑問を持たれた方は、この一連の流れを読んでくれたら解決すると思います
>>704
それとおまえはまたどこかのスレにBitLockerで暗号化されているストレージはSector By Sectorでコピーしたらバックアップ出来るよなんて適当な事を書いているよな
まず、復号が可能であったらmanage-bde経由で復号してからバックアップするのが鉄則
Sector By Sectorでコピーしたものが回復キーで復号されるかは博打事案だぞ
おまえが一度だけ成功していたとしても複数の環境で確認しないとそれが正しいとは言えないよな
おまえはいつもそうだからダメなんだよ
結局のところ理屈がわかっていないググりバカだ
710: 2025/04/03(木)15:13 ID:LmfDFyXp0(7/20) AAS
Linux関連のSecure Bootに疑問を持たれた方は、この一連の流れを読んでくれたら解決すると思います
>>704
それとおまえはまたどこかのスレにBitLockerで暗号化されているストレージはSector By Sectorでコピーしたらバックアップ出来るよなんて適当な事を書いているよな
まず、復号が可能であったらmanage-bde経由で復号してからバックアップするのが鉄則
Sector By Sectorでコピーしたものが回復キーで復号されるかは博打事案だぞ
おまえが一度だけ成功していたとしても複数の環境で確認しないとそれが正しいとは言えないよな
おまえはいつもそうだからダメなんだよ
結局のところ理屈がわかっていないググりバカだ
711: 2025/04/03(木)17:11 ID:LmfDFyXp0(8/20) AAS
Secure Boot Advanced Targeting (SBAT)
そのあんたが書く(SBAT)の単語がどうにも気に食わない
こいつ自身もよく分かっていないようなので以下を追記します
外部ﾘﾝｸ[html]:docs.oracle.com
SBATステータスの検証
Oracle Linux 8およびOracle Linux 9のshimパッケージのバージョン15.3以降、OracleではUEFI Secure Boot Advanced Targeting (SBAT)が使用されています。SBATは、UEFIバイナリの.sbatセクションに生成番号を設定することで、grub2やshimなどの古いバージョンのコア・ブート・コンポーネントを取り消すメカニズムです。UEFIバイナリに設定されている生成番号は、その失効レベルを定義します。
712: 2025/04/03(木)17:29 ID:GKPIib6q0(1) AAS
スレチなのにたまたま自分の知識が披露できる場所を見つけたから止められないんだろ
もう誰も見ていないのにw
713: 2025/04/03(木)17:34 ID:LmfDFyXp0(9/20) AAS
後から来た人が見て興味を持ったらそれだけでいいので書いている
誰かの役に立つかもしれないしな
おまえとは違うよw
714: 2025/04/03(木)17:42 ID:LmfDFyXp0(10/20) AAS
>>666
まとめ
これと照らし合わせて読んだらこのまとめの内容ってどうなんだろうな？
あんたは偉そうだけどね
715(1): 2025/04/03(木)20:02 ID:LmfDFyXp0(11/20) AAS
要は事の発端を遡ってみると >>632 が間違った認識で書き込んだって事だな
2025/03/10(月) 書き込んだ日付がこのようになっているので、
俺がSecure Bootを確認したrescuezilla-2.5.1-64bit.noble.iso
このバーションの日付は以下のようになっている
\casper\filesystem.squashfs 1.2GB 2024/09/09 4:04:01
これに対してマイクロソフトの公式見解が >>702 なので俺も確認して見たが、
クリーンインストールをしている24H2などでは何の問題もなかった
古いWindows環境でこのパッチを当てた場合にはその後のWindowsUpdateで修正されるかどうかまでは俺にはわからないな
716(1): 2025/04/03(木)20:18 ID:LmfDFyXp0(12/20) AAS
そもそもが >>702 のパッチってLinuxとデュアルブートにしている場合にはマイクロソフト側では適用していないって書いてあるんだよな
その上で苦情を言っているのが現れている
WindowsオンリーでLive CDなどからブートしているって事ならそもそもセキュアブートを無効にしろよって事でいいのではないのか？
717(1): 2025/04/03(木)20:40 ID:neDPEm+v0(4/7) AAS
>>709
また他人と勘違いしてる
妄想が過ぎるね
>>715
間違っていない
まーだわかってないのか
検証するならSBAT当てて検証しなきゃ意味がないでしょ
>>716
windowsオンリーのシステムでも
サルベージ関係のツールはlinuxベースの物を使う場合があるぐらいわかるよね
SecureBoot切ったらいいというのは事実だがSecureBootが何のためにあるか考えれば
userによっては切りたくないという心理も当然
ventoyのshimの署名がマイクロソフトの署名だってわかったのなら
ちゃんとごめんなさいしろよ
718(1): 2025/04/03(木)20:48 ID:LmfDFyXp0(13/20) AAS
ば〜か
そんな問題に対して解析した結果じゃないだろうよ
ずっと経緯を読んで来て見ろよ
頭こっ足らないじゃねーのか？
719(1): 2025/04/03(木)20:59 ID:LmfDFyXp0(14/20) AAS
>ventoyのshimの署名がマイクロソフトの署名だってわかったのなら
>ちゃんとごめんなさいしろよ
なんでだよ？
最初から >>678 を貼ってあるよな
Microsoft Corporation UEFI CA 2011の署名は、マイクロソフト側がサードパーティの要求に対して発行したセキュリティ証明書だ
これはドライバーとか全てが対象だ
shimローダーに対してもな
おまえは相当にノータリンのようだなw
720(1): 2025/04/03(木)21:08 ID:LmfDFyXp0(15/20) AAS
それともうひとつ
事細かく内容を説明してくれているのであれば感謝もあるだろうけども、
短文煽りの説明内容では誰も感謝などしないわな
頭おかしいのではないのか？ いつも同じ手法のバカ煽りくん
他のスレでも同じような事をやっているようだけれども、
無知のバカ煽りは誰にも相手にされていないようだけどなww
721: 2025/04/03(木)21:16 ID:LmfDFyXp0(16/20) AAS
>>717
おまえの文体と文脈には特徴があるからいつものやつなのは大体想像出来るよw
722: 2025/04/03(木)21:45 ID:neDPEm+v0(5/7) AAS
>>718
発狂してるから日本語になってないよ
日本語でたのむ
>>719
貼ってあっても君が理解をしてないからごめんなさいしろよ
だって
>688
>もうひとつはVentoyでやっているUEFI署名方法はまた別な方式であるって事です
>区別して下さい
理解してないってことだ
>>720
義務教育やないんやからね
そのうえ君のようなしょっぱなから間違っているのに
わかってる人間に
>おわかりになられていないようで
>知った風にしない方がいいですよ
とかいう人間が感謝なんてしないし、
妄想はげしいし
そんな人間に感謝してもらおうって気にもならんよねえ
723(1): 2025/04/03(木)21:53 ID:LmfDFyXp0(17/20) AAS
本当にバカな人間つてのはどうしようもないんだなw
いつもワンパターンな煽り方w
724(1): 2025/04/03(木)21:59 ID:LmfDFyXp0(18/20) AAS
まあWindows板も含めてだがこんな過疎スレに速攻で書き込みに来るやつなんておまえしかいないだうよ
Win板で過疎り始めるとXPスレを上げ始めるのはもう止めたのか？
バカを特定するのなんて簡単だろうよw
725: 2025/04/03(木)22:10 ID:LmfDFyXp0(19/20) AAS
Window板での布教活動は粗方済んだので、後は知識を引き継いだ次世代の者へと引き渡せばもういいかな
ただおまえは邪魔だからWindows板へは常駐するなよ
もう少し外野の知識が底上げされるといいんだけどな
726: 2025/04/03(木)22:25 ID:neDPEm+v0(6/7) AAS
>>723
なにも反論になってないな
ごめんなさいは？
>724
反論できなきゃレッテル張り
どうしようもないカ○だな
727: 2025/04/03(木)22:28 ID:LmfDFyXp0(20/20) AAS
今後はいつも通りに無視w
728(1): 2025/04/03(木)22:31 ID:neDPEm+v0(7/7) AAS
反論できないからしょうがないね
ごめんなさいもできない人間だからね
729: 2025/04/04(金)20:05 ID:bwH2rAWe0(1/3) AAS
Ventoy2Disk.exe Ventoy 製品バージョン 1.1.0.3
更新日時: 2025年2月24日
これがSecure Boot時にバイバスされてしまうのか？って疑問をWindows 7のISOで検証しました
UEFIのみのパソコンでまず確認しましたが、「Press any key to boot from CD or DVD」で停止したままになります
Windows 7のインストールにはレガシーサポートも必要です
このパソコンだとUEFIファームのみしかなくてSecure Bootを無効にしても意味がありませんので
次にVmware上で確認して見ました
結果的に、Secure Boot時にはWindows 7のISOからはブートしません
Vmware上でSecure Bootを無効にするとレガシーサポートも有効化されますので
この条件でWindows 7のISOからはブートしました
結果的にはVentoyの現バージョンを利用するとSecure Boot条件はスルーされません
まあ、BIOS上での制限なのでVentoyが仮想DVDへとマウントしたからって昔のバージョンでもスルーされないとは思いますね
githubの書き込みがそもそもおかしいですよね
730(1): 2025/04/04(金)22:31 ID:bwH2rAWe0(2/3) AAS
外部ﾘﾝｸ:github.com
ヴァルディクSS
on Jun 17, 2020
GRUB(少なくともv2.04以前のバージョン、Fedoraパッチでパッチが適用されている場合)は、すでに説明どおりに機能していると思います。
ただし、シムのチェーンロードが許可されているかどうか、たとえばFedoraのシムがロードされているときにUbuntuをロードしようとするとどのように機能するかはわかりません。Super GRUB2 Diskの作者がそれを処理しようとしたことは承知していますので、彼にコメントを求めます。
Super UEFIinSecureBoot Disk ファイルを使用して UEFI ファイルポリシーを無効にしましたが、これは最も簡単な方法ですが、「適切な」方法ではありません。実際のユースケースでは、いくつかのLinuxディストリビューション(そのすべてがセキュアブートをサポートしているわけではありません)、いくつかの署名されていないUEFIユーティリティがある場合、SUISBDメソッドを使用してセキュアブートを一時的に無効にする方が簡単です。
しかし、最初のブート時(ユーザーが私のENROLL_THIS_CERT_INTO_MOKMANAGER.crtを登録するとき)にgrubモジュールからshimに必要なすべてのキーを自動的に登録し、署名されていないefiバイナリを特別なケースとして処理するか、単にユーザーが生成したキーでそれらに署名する必要があると思いますか?
考えて、ventoyに加えてみます。
>Super UEFIinSecureBoot Disk
これに関してだが、Secure Boot条件をバイパスするローダーファイルを設定したいという内容で
VentoyがSecure Boot条件を無視してバイバスしてしまうとは何処にも書かれていないぞ
突っかかって来ているあんたは思いっきり勘違いしているわ！
731: 2025/04/04(金)22:34 ID:bwH2rAWe0(3/3) AAS
どうせただググってヒットしたものを貼り付けただけのマヌケでしょうね
732(1): 2025/04/05(土)00:10 ID:zlM1zcp70(1/13) AAS
>>666
何がまとめだw
俺が読んでみたらデタラメだらけだ
>Ventoy自体も同じ問題があった過去がありその際はあたらしいshimを組み込んで対策をした。
外部ﾘﾝｸ:github.com
こいつに関しては >>702 にあるように2024 年 8 月のセキュリティ更新プログラムだけに問題があったと読み取れる
9 月のセキュリティ更新プログラム以降のものが適用されたら問題ないと受け取れるぞ
733(4): 2025/04/05(土)00:58 ID:zlM1zcp70(2/13) AAS
これはその内容を確認しておかなきゃならないだろうとこのバージョンでSecure Bootした
Ventoy2Disk.exe 製品バージョン 1.0.0.3 更新日時 2024/06/08
何の問題もなく起動するのでやはり9 月以降のセキュリティ更新プログラムに不具合が訂正されたSBAT更新プログラムが含まれていると思われる
734(1): 2025/04/05(土)01:15 ID:zlM1zcp70(3/13) AAS
>>728
墓穴を掘っているおまえの方が大々的に謝罪すべきではないか？
735(3): 2025/04/05(土)10:38 ID:zlM1zcp70(4/13) AAS
外部ﾘﾝｸ:learn.microsoft.com
2024 年 8 月
2024 年 8 月のセキュリティ更新プログラムは、デュアルブート セットアップ デバイスでの Linux ブートに影響する可能性があります次の手順: 今後の Windows 更新プログラムで利用できる最終的な解決に取り組んでいます。 この問題を回避するには、2024 年 9 月以降の Windows 更新プログラムをインストールすることをお勧めします。
影響を受けるプラットフォーム:
クライアント: Windows 11バージョン 23H2;Windows 11バージョン 22H2;Windows 11バージョン 21H2;Windows 10バージョン 22H2;Windows 10バージョン 21H2;Windows 10 Enterprise 2015 LTSB
サーバー: Windows Server 2022; Windows Server 2019; Windows Server 2016; Windows Server 2012 R2; Windows Server 2012
なるほどな この時点ではまだ24H2は正式にリリースしていない
確かに9 月以降の Windows 更新プログラムで修正されている意味合いで受け取れるな
736: 2025/04/05(土)11:16 ID:zlM1zcp70(5/13) AAS
Ventoyを含めて >>662 の動作を分析したい人は、VMware上にWin11の環境を複数作成すれば一度デバイス環境として有効設定してしまってもからでも、別な仮想BIOS上からブートすれば何度でも確認出来ます
その際に設定を開いてセキュアブートのチェックを入れるのを忘れずにね
外部ﾘﾝｸ[html]:docs.oracle.com
UEFI Secure Bootデータベース・キー(DB)
737: 2025/04/05(土)11:37 ID:zlM1zcp70(6/13) AAS
外部ﾘﾝｸ[html]:docs.oracle.com
MOKデータベースについて
外部ﾘﾝｸ[html]:docs.oracle.com
mokutilユーティリティについて
理屈を理解するには難しいなw
738: 2025/04/05(土)11:57 ID:NDDw7/9W0(1) AAS
外部ﾘﾝｸ[html]:docs.oracle.com
3 セキュア・ブートで使用するためのカーネル・イメージおよびカーネル・モジュールの署名
これも読んだ方がいいな
739: 2025/04/05(土)18:33 ID:zlM1zcp70(7/13) AAS
全ての経緯が検証出来る形でリンクを貼って来ました
このバカが書いた >>666 の内容をみなさんはどう思われますか？
740: 2025/04/05(土)18:43 ID:KSd4HvXb0(1) AAS
どっちもどっち
同じレベルの争いをしている時点でw
741: 2025/04/05(土)19:06 ID:zlM1zcp70(8/13) AAS
Ventoyでやってるmokutilユーティリティ手法は非常に興味深いものになりました
こんな方法もあるのですね
742: 2025/04/05(土)19:21 ID:vM+WAd4e0(1) AAS
Hasleo Backup Suite
外部ﾘﾝｸ[html]:www.easyuefi.com
いいぞ～これ
743: 2025/04/05(土)19:30 ID:dp/AMNBW0(1/4) AAS
>>730
また理解不足の間違い
しょっぱなに書いてあるでしょ
またValdikSS の@pbatardへのコメントでも明らか
○○すれば署名されたファイルのみが飲み込まれるとある
.>>732
はい曲解
更に理解不足
>こいつに関しては >>702 にあるように2024 年 8 月のセキュリティ更新プログラムだけに問題があったと読み取れる
>9 月のセキュリティ更新プログラム以降のものが適用されたら問題ないと受け取れるぞ
>733も含めて間違い
ちゃんと調べてこい
9/11以降のセキュリティ更新は今のところ、SBATを適用しないだけ
君は理解不足で間違って他人に迷惑かけすぎ
>8 月の更新プログラムを適用しておらず、この問題からの保護を希望されるお客様は、
>2024 年 8 月 14 日の更新プログラムを適用するか、2024 年 9 月 11 日の更新プログラムを適用して、
>管理者のコマンド プロンプトから次のレジストリ キーを設定できます。
>734
自己紹介乙
744: 2025/04/05(土)20:08 ID:zlM1zcp70(9/13) AAS
おまえのようにググって調べたんじゃなくて実環境上で確認しなから検証しました
何を書こうがおまえには信頼性がないよw
745: 2025/04/05(土)20:20 ID:dp/AMNBW0(2/4) AAS
君が理解力不足で曲解してるのは十分わかったから
実環境上で検証したといっても
検証したことにならないんだよなあ
すぐ上でも
SBATが適用されてると勘違いしてるんだから
746(1): 2025/04/05(土)20:27 ID:zlM1zcp70(10/13) AAS
残念ながら >>733 には反論出来まいなww
747: 2025/04/05(土)20:35 ID:zlM1zcp70(11/13) AAS
外部ﾘﾝｸ:sourceforge.net
ほら 思う存分古いバージョンでも好きなだけ確認して見な
748: 2025/04/05(土)21:56 ID:zlM1zcp70(12/13) AAS
KB5043076はアップデートカタログからダウンロード出来るようなので、
これをインストール後に >>733 にあるバージョンのVentoyをSecure Bootしてみるといいよ
その後に9 月以降のセキュリティ更新プログラムをインストールしてからもう一度確認する
これが検証でしょうねw
749(2): 2025/04/05(土)21:59 ID:zlM1zcp70(13/13) AAS
間違った
(KB5041585) はアップデートカタログからダウンロード出来るようなので、
これをインストール後に >>733 にあるバージョンのVentoyをSecure Bootしてみるといいよ
その後に9 月以降のセキュリティ更新プログラムをインストールしてからもう一度確認する
750: 2025/04/05(土)22:49 ID:dp/AMNBW0(3/4) AAS
>>746
いやだから反論してるだろ
理解力ないな
>すぐ上でもSBATが適用されてると勘違いしてるんだから
751: 2025/04/05(土)22:53 ID:dp/AMNBW0(4/4) AAS
>>749
何をしてもいいが
SBATの内容を確認しないと全く意味がない
752: 2025/04/06(日)01:16 ID:2vv8NDYT0(1) AAS
4kアライメントしたらOS再起不能になったわ
753(1): 2025/04/07(月)01:33 ID:CzN/2PbI0(1/2) AAS
>>749 だがまだ詳細に検証中なのでもう少し時間を頂きたい
ただ今言えるのは(KB5041585)は地雷パッチであって、>>735 に書かれているように2024 年 9 月以降の Windows 更新プログラムをインストールした所で、無効に設定されてしまった.sbatセクションからこれらが取り消される事はもうない
誤解釈なのかも知れないがマイクロソフトが書いている内容は嘘です
それと同時にこの内容に関しては正式に謝罪いたします
>SBATは、UEFIバイナリの.sbatセクションに生成番号を設定することで、grub2やshimなどの古いバージョンのコア・ブート・コンポーネントを取り消すメカニズムです。UEFIバイナリに設定されている生成番号は、その失効レベルを定義します。
754: 2025/04/07(月)20:28 ID:CzN/2PbI0(2/2) AAS
続きの検証内容です
VMware上へと新規作成した環境上へと素のままのWin11_23H2_Japanese_x64v2.isoをインストールした 2023/12/04
rescuezilla-2.5-64bit.noble.iso 外部ﾘﾝｸ[iso]:github.com
rescuezillaにはターミナルがあるのでこれにて確認した結果
外部ﾘﾝｸ:imgur.com
次はKB5041585をインストール後の結果です
このパッチの日付を考慮してrescuezilla-2.5-64bitのバージョンにて確認 2024/05/13
Secure Boot時にこのrescuezillaは起動せずに以下のエラーメッセージとなる
現行バージョンのRufusはSecure Bootが可能でした
外部ﾘﾝｸ:imgur.com
外部ﾘﾝｸ:imgur.com
その後に現状のWindowsUpdateを全て適用した
rescuezilla-2.5-64bitは上記と同じエラーのままです
rescuezilla-2.5.1-64bitはSecure Bootが可能でした
外部ﾘﾝｸ:imgur.com
rescuezillaはUSBメモリへと展開したISOイメージをそのままコピーしてブート可能にしました
755: 2025/04/08(火)02:43 ID:TZKKRCui0(1/3) AAS
そして最後がSecure Bootを無効として一旦rescuezilla-2.5-64bitを起動した
外部ﾘﾝｸ:imgur.com
ターミナルで実行しても何も変わっていないように見えるが
rescuezilla-2.5-64bitはSecure Boo時にも起動するようになった
756: 2025/04/08(火)03:34 ID:TZKKRCui0(2/3) AAS
VMwareでのUSBメモリからのセキュアブート方法を書いておきます
仮想マシン -----> 設定 -----> オプション -----> 詳細 -----> ファーウェアタイプ -----> UEFI -----> 「セキュアブートを有効にする」の項目があります
仮想マシン -----> パワー -----> ファームウェアへのパワーオン
これで仮想BIOSのブートマネージャーが表示されます
仮想マシン -----> 取り外し可能デバイス -----> ブートする目的のUSBメモリを接続にします
この状態から「Reset the system」を選択し実行後にF2キーを直ぐに押します
機種によっては、Fn + F2キー の場合もあります
「EFI USB Device」 このブート項目を選択してEnterを押します
これで目的のUSBメモリからブートします
757: 2025/04/08(火)05:31 ID:TZKKRCui0(3/3) AAS
つまりSecure Boot設定でブート出来なくなったLinux系のOSとユーティリティアプリは、
一旦無効としてブートしてからターミナルでsudo mokutil --set-sbat-policy delete を実行すれば、
無効に設定されてしまった.sbatセクションが解除されると私は解釈しました
758: 2025/04/08(火)23:55 ID:0ljo0Res0(1) AAS
>>753
いや普通にマイクロソフトが書いていることそのままだね
>735のURLの回避策をするだけ
回避策には9月の更新をいれたら直るとは書いてない
そもそもそのシステムにSBATの更新がかかっていることがわかっても
SBATを意図的に更新した人かどうかわからないから
9月の更新を当てたシステムすべてのSBATの更新を戻すのはやらない
>2024 年 9 月以降の Windows 更新プログラムをインストールすることをお勧めします。
これは単純に8月を入れないで9月以降を入れることをすすめているだけ
759: 2025/04/09(水)02:50 ID:7CHUkbmB0(1/5) AAS
>> 758
>この問題を回避するには、2024 年 9 月以降の Windows 更新プログラムをインストールすることをお勧めします。
そのように解釈させるためには、「この問題を回避するには、この更新プログラムは適用せずに2024 年 9 月以降の Windows 更新プログラムをインストールすることをお勧めします。」
このように書くべきだよ
760(1): 2025/04/09(水)03:10 ID:7CHUkbmB0(2/5) AAS
外部ﾘﾝｸ:imgur.com
外部ﾘﾝｸ:imgur.com
外部ﾘﾝｸ:imgur.com
これらの違った累積更新パッチを適用する過程でターミナルが mokutil --list-sbat-revocations で表示しているsbatのバージョン番号が違ったものへと推移しています
しかし、rescuezilla-2.5-64bitは相変わらずSecure Boot状態では起動しなかった経緯からもこのsbatのバージョンだけでは判断に結び付きません
761: 2025/04/09(水)04:08 ID:7CHUkbmB0(3/5) AAS
rescuezilla-2.5-64bitのもの
外部ﾘﾝｸ:imgur.com
rescuezilla-2.5.1-64bitのもの
外部ﾘﾝｸ:imgur.com
これで表示されている失効レベルとはこの日付だろうかね？
これ以前のものの署名は失効扱いにしますって意味だろうかね？
外部ﾘﾝｸ:imgur.com
sbat,1,20240109
762(3): 2025/04/09(水)06:17 ID:7CHUkbmB0(4/5) AAS
外部ﾘﾝｸ:imgur.com
これが実環境にクリーンインストールしてある24H2からSecure Bootしたバージョンが古いrescuezilla-2.5-64bitのものです
2台のパソコンで確認したものの表示はこれと同じでした
(KB5041585)がインストール済みである 外部ﾘﾝｸ:imgur.com と対比して考えた場合には如何なものでしょうか？
単純にマイクロソフトが何か余計なものを仕込んでやらかしちまったものを、ひた隠しに説明した内容とも受け取れるんだよね
763: 2025/04/09(水)13:53 ID:o9ml9hlY0(1) AAS
>>762
KB5041585をあてるだけじゃSBATの更新がかからない
そこからさらにwindowsの起動を二回行う必要があるようだ
(他の条件もある可能性も)
1st:Boot:デュアルブート環境か確認
2nd Boot 実際に更新
かもしれない
外部ﾘﾝｸ:infosec.exchange
764: 2025/04/09(水)23:44 ID:7CHUkbmB0(5/5) AAS
累積更新なのだから再起動しろって要求されるよ
やってみな
765: 2025/04/10(木)02:17 ID:X6yD3sLI0(1/6) AAS
ちゃんと読んでね
再起動しても起動は一回でしょ
766: 2025/04/10(木)02:21 ID:X6yD3sLI0(2/6) AAS
>762
のKB5041585インストール済の画像を見る限り
SBATの更新がかかっていないから言ってるんだけど
更新されているなら
2024010900
表記になる
767: 2025/04/10(木)04:13 ID:6UVjlkg50(1/10) AAS
外部ﾘﾝｸ:imgur.com
なっていないって言われたって、この状態でrescuezilla-2.5-64bitはSecure Bootが無理だったし、
rescuezilla-2.5.1-64bitは起動した
左下に表示されているrescuezillaのバージョンが2.5.1になっているだろうよ
768: 2025/04/10(木)04:19 ID:X6yD3sLI0(3/6) AAS
その状態は
shim grubともに表記がないので制限がされていないので2.5のSecure Bootが無理というのがおかしい
769: 2025/04/10(木)04:20 ID:6UVjlkg50(2/10) AAS
そんなに文句を言うのであれば後程再確認してみるよ
770: 2025/04/10(木)04:36 ID:6UVjlkg50(3/10) AAS
>>760 を説明するね
外部ﾘﾝｸ:imgur.com
これは、Win11_23H2_Japanese_x64v2.isoをインストール直後で確認した状態
この状態でrescuezilla-2.5-64bitがSecure Boot状態でも起動するのを確認しています
外部ﾘﾝｸ:imgur.com
これが、KB5041585をインストール後の状態で再起動要求は済ませてあります
rescuezilla-2.5.1-64bitの方であれば、Secure Boot状態でも起動しました
外部ﾘﾝｸ:imgur.com
そしてこれが、現状のWindowsUpdateを全て済ませた後で確認した状態です
rescuezilla-2.5-64bitはSecure Boot状態では起動しませんでした
771: 2025/04/10(木)04:40 ID:6UVjlkg50(4/10) AAS
俺も相当慎重に検証作業をしたのでイージーミスはないはずだよ
772: 2025/04/10(木)04:46 ID:X6yD3sLI0(4/6) AAS
結局2番目画像は2.5確認してないんじゃないの？
で更新してからwindows2回起動していないのでSBAT更新されていない
更新されれば本来3番目画像になっている
外部ﾘﾝｸ:infosec.exchange
773: 2025/04/10(木)04:50 ID:6UVjlkg50(5/10) AAS
ああ、ひとつ言いたい事はある
VMware上にインストールして確認した訳だがストレージはもとより、仮想BIOS環境もリセットされる事を考えて新規に作成した
現状のものを流用すると仮想BIOS環境はそのまま引き継がれてしまうよ
また、実機上からだとBIOS設定を一旦リセットしてからやってみる必要があると思う
774: 2025/04/10(木)05:21 ID:X6yD3sLI0(5/6) AAS
KB5041585で更新されるSBATのタイムスタンプは2024010900と
外部ﾘﾝｸ:github.com
や
外部ﾘﾝｸ[html]:www.heise.de
にも記載されている
775: 2025/04/10(木)05:26 ID:6UVjlkg50(6/10) AAS
じゃあもう一度VMware環境上から再確認してみるよ
書かれているだけでは証明にもならないからさ
776: 2025/04/10(木)05:46 ID:X6yD3sLI0(6/6) AAS
証明にならないっていったって
一個目はrufusの作者の書き込み
二個目はニュースサイト
対して5ちゃんの誰かの検証とどっちが信用できると普通の人に聞けばわかるよね
777: 2025/04/10(木)08:21 ID:6UVjlkg50(7/10) AAS
ひとつ判明した事がある
間違ってやらかしたんだが、
セキュアブートが有効としてある環境と無効としてある環境へとKB5041585をインストールすると、
mokutil --list-sbat-revocationsで表示したsbatのバージョンも違うしgrub2が表示されるようになった
おまけにrescuezilla-2.5-64bitがセキュアブートを有効としても起動するようになるんだ
どおりでマイクロソフトが >>735 の説明を曖昧にして誤魔化している筈だ
完全に原因を究明していないんだろうよ
>2024 年 8 月の Windows セキュリティ更新プログラム (KB5041585) または 2024 年 8 月のプレビュー更新プログラムをインストールした後、デバイスで Windows と Linux のデュアルブートセットアップを有効にした場合、Linux の起動に関する問題が発生する可能性があります。
どうもこのパッチはSecure Bootが無効になっている状態でインストールすると.sbatセクションへと無効設定をしないのではないのかな？
ほぼ間違いがない結果が出たので、後程対比したスクショを上げるつもりです
778: 2025/04/10(木)09:33 ID:6UVjlkg50(8/10) AAS
セキュアブートが有効としてある環境へとKB5041585をインストール
セキュアブートを「無効」としてrescuezilla-2.5-64bitで確認した内容 外部ﾘﾝｸ:imgur.com
セキュアブートを「無効」としてrescuezilla-2.5.1-64bitで確認した内容 外部ﾘﾝｸ:imgur.com
セキュアブートを「有効」としてrescuezilla-2.5.1-64bitで確認した内容 外部ﾘﾝｸ:imgur.com
何故か表示される内容が変わるのです
嘘ではないので確認して下さい
途中経過ではありますが興味のある人へ・・・
779: 2025/04/10(木)14:19 ID:6UVjlkg50(9/10) AAS
>>762
>(KB5041585)がインストール済みである 外部ﾘﾝｸ:imgur.com と対比して考えた場合には如何なものでしょうか？
このスクショは間違っていますね 確認したら5箇所ほど間違って貼り付けてあるようです
セキュアブートを無効としてrescuezilla-2.5.1-64bitから確認したものです
セキュアブートを「有効」としてrescuezilla-2.5.1-64bitで確認した内容 外部ﾘﾝｸ:imgur.com
こちらのスクショが正しいです
780(1): 2025/04/10(木)15:18 ID:6UVjlkg50(10/10) AAS
これはもう深い闇を感じてやる気が失せました
セキュアブートが有効な状態でKB5041585を適用したらrescuezilla-2.5-64bitはセキュアブートが有効な状態では起動しない
セキュアブートが無効な状態でKB5041585を適用したら.sbatセクションへと登録されないのでrescuezilla-2.5-64bitはセキュアブートが有効な状態でも起動する
その後のパッチはセキュアブートが有効な状態で9月のKB5043076を含めて以降の累積更新を適用したら.sbatセクションへの登録は解除される
それぞれを対比したスクショを上げるのは止めて一旦これで打ち止めとしておきます
上下前次1-新書関写板覧索設栞歴
あと 222 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s