2013年の発売以来長年ハッキング不可能だと考えられてきた「Xbox One」に対するハッキング手法が、脆弱(ぜいじゃく)性研究カンファレンスの「RE//verse 2026」で公開されました。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
Xbox OneはMicrosoftのエンジニアから「これまでにMicrosoftが製造した中で最も安全な製品」といわれるほど堅牢な作りで、ハッキングが不可能だと見なされてきました。ところが、RE//verse 2026に参加したマーカス・ガースデレン氏が「Bliss」というハッキング手法を公開したことで、そのセキュリティが崩れ去ることとなったと伝えられています。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
BlissはCPUの電圧を変化させて誤作動を引き起こす「電圧グリッチ」を利用したハッキング手法です。ガースデレン氏はハードウェア解析ツールを自ら開発し、セキュリティプロセッサのブートROMに対して2つの電圧グリッチを利用。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
一度目でMPUの設定をバイパスし、次にヘッダー読み取り中に実行を乗っ取ることで、スーパーバイザーレベルの制御を可能にするとのことです。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
これはハードウェアに対する攻撃であるため、パッチによる修正は不可能とされています。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
⇧ ハッキング箇所が低レイヤー過ぎるんだが...
ただ、「ハッキング」の取っ掛かりは「ハードウェア」部分かもしれないのだが、制御を奪う部分は「ファームウェア」とか介したりする必要はないのだろうか？
つまり、
⇧ 上記で言うところの、「OSI参照モデル」で言うところの、
- データリンク層
- ネットワーク層
あたりが関わってこないのかが気になりますな...
ちなみに、「ハッキング」完了後は、「トランスポート層」あたりまで制御できるということなんですかね？
今回のハッキング手法により、ハイパーバイザーやOSを含むすべてのレイヤーで未署名コードの実行が可能となり、さらにセキュリティプロセッサにもアクセスできるため、ゲームやファームウェアの復号も可能になると伝えられています。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
ガースデレン氏は「ここ数年ゲームはやっていません。Xbox Oneをハッキングしてゲームをいくつか違法ダウンロードするためにここに戻ってきたわけではありません。ただ、他の人がこの研究を再現して何か役に立つことをできるかどうかには興味があります」と述べました。
「ハッキング不可能」と言われていたXbox Oneが「Bliss」と呼ばれる手法によってついに突破される - GIGAZINE
⇧ 今回の「Bliss」という「ハッキング」手法が適用可能な「ハードウェア」がどれだけ存在するのかが皆目見当が付かないのだが、もし、仮に、汎用的に利用できてしまうのだとするならば絶望的過ぎるのだが...
願わくば、「Xbox One」以外の「ハードウェア」に対して「Bliss」という「ハッキング」手法による「ハッキング」の「再現」が成功されないことを祈るばかりですな...
cloud-init とは？
公開されている「GitHub」上のドキュメントによりますと、
Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization. It is supported across all major public cloud providers, provisioning systems for private cloud infrastructure, and bare-metal installations.
Cloud instances are initialized from a disk image and instance data:
- Cloud metadata
- User data (optional)
- Vendor data (optional)
Cloud-init will identify the cloud it is running on during boot, read any provided metadata from the cloud and initialize the system accordingly. This may involve setting up network and storage devices to configuring SSH access key and many other aspects of a system. Later on cloud-init will also parse and process any optional user or vendor data that was passed to the instance.
The majority of clouds and Linux / Unix OSes are supported by and ship with cloud-init. If your distribution or cloud is not supported, please get in contact with that distribution and send them our way!
⇧ 上記によると、「クラウド」上の「リソース」の初期化で利用される「プログラム」で主要な「Linux ディストリビューション」に「同梱」されているものらしい。
で、残念ながら、「cloud-init」の「アーキテクチャ図」的なものは、「ドキュメント」としてネット上で検索にヒットしないのだが、
⇧ 動画は見つかった。
まさかの、「cloud instance initialization software」の略称で「cloud-init」らしい。
で、
⇧ 動画で紹介されていた図と「GitHub」の説明から推測するに、「Cloud instance」を構成する「要素」としては、
- disk image
- instance data
- Cloud metadata
- User data (optional)
- Vendor data (optional)
になると思われる。
で、
⇧ 上記が「cloud-init」の「起動プロセス」っぽいのだが、
⇧ 仮に、上記サイト様の図が一般的な「Linux」の「起動プロセス」とした場合に、対応が分からない...
「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
📌 Linuxブートプロセスと cloud-init の対応
| Linux ブートフェーズ | 説明 | cloud-init の動作/タイミング |
|---|---|---|
| 1. BIOS/UEFI | ハードウェア初期化、ブートローダー呼び出し | なし。cloud-init は OS が立ち上がるまで動かない |
| 2. ブートローダー（GRUB） | カーネルロード、initrd/initramfs 展開 | なし。cloud-init のバイナリは initramfs に含まれる場合もあるが、まだ実行されない |
| 3. カーネル初期化 | カーネルがデバイス初期化、プロセス管理開始 | なし。cloud-init は root 権限プロセスとしてまだ呼ばれない |
| 4. init / systemd の起動 | PID 1 が systemd を起動し、ターゲット（runlevel）に応じてサービス起動 | ここで cloud-init が systemd ユニットとして呼ばれる 例: cloud-init.service |
| 5. early boot services | ファイルシステムマウント、ネットワーク準備 | cloud-init は early boot で動き始める ユニット cloud-init-local.service が initramfs 後すぐに起動、ローカルメタデータにアクセス |
| 6. main boot services | ネットワーク、ログ、各種デーモン起動 | cloud-init の各モジュールが順次実行される
|
| 7. multi-user.target/reboot完了 | OS が利用可能な状態に到達 | cloud-init はこの時点で完了 ディスク初期化やパーティション作成も完了している |
📌 補足ポイント
✅ 1. ユニットの順序
systemctl list-units | grep cloud-init
で見ると、通常順番は：
cloud-init-local.service cloud-init.service cloud-config.service cloud-final.service
となっており、早期→メイン→最終設定という順序で動作します。
✅ 2. ディスク操作のタイミング
/dev/sdXの検出は cloud-init-local で行われることもある- パーティション作成やフォーマットは cloud-init main modules で実施
- つまり、Linux ブート完了前に fdisk で見たときに既に
/dev/sdc1ができていることがあります。
✅ 3. Azure上での特殊性
- Azure のメタデータサービスから情報取得
- Custom Data（user-data）に基づき early にディスク初期化
- OS 上では boot 完了とほぼ同時に自動的に作業済み
💡 まとめ
- cloud-init は Linux ブートプロセスの systemd フェーズで動作開始
- ディスク初期化やユーザー設定などは early→main→final の順で自動実行
- そのため VM作成直後の fdisk で「全領域使用済み」となる原因 になりやすい
⇧ まぁ、よく分からないが、「cloud-init」が良からぬ影響を与えているかもしれないことがありそうですと...
話を動画で紹介されている内容に戻すと、
⇧ 上図は「クラウドサービスプロバイダー」が異なる環境でも動作するということを言いたいのかしらね...
Azure 仮想マシン作成後のfdisk実行でパーティションの新規作成ができずcloud-initの洗礼を受けていそうな話
で、「Microsoft」の公式の「ドキュメント」で「cloud-init」についての説明があり、
cloud-init の概要
cloud-Init は、Linux VM を初回起動時にカスタマイズするために広く使用されている手法です。 cloud-init を使って、パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりすることができます。 cloud-init は初回起動プロセスの間に呼び出されるので、構成を適用するために追加の手順や必要なエージェントはありません。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/using-cloud-init
Microsoft は、動作保証済み Linux ディストリビューションのパートナーと協力して、cloud-init 対応のイメージを Azure Marketplace で利用できるようにする作業を行っています。 これらのイメージによって、cloud-init のデプロイと構成が、VM および仮想マシン スケール セット とシームレスに動作するようになります。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/using-cloud-init
まず、Microsoft では動作保証済み Linux ディストリビューションのパートナーおよび上流と共同作業を行い、Azure 上の OS で cloud-init が機能するようにします。次に、パッケージが更新され、ディストリビューションのパッケージ リポジトリで一般公開されます。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/using-cloud-init
⇧ 上記によると、
『Microsoft は、動作保証済み Linux ディストリビューションのパートナーと協力して、cloud-init 対応のイメージを Azure Marketplace で利用できるようにする作業を行っています。』
とあるので、「Microsoft」が「責任」を負うべきな気がするのだが、
⇧ 上記の「Microsoft」が公開している「共有責任モデル」だと、「Operation system」は「Customer」となっているという謎...
再掲するのだが、「Microsoft」の公式の「ドキュメント」では、
『まず、Microsoft では動作保証済み Linux ディストリビューションのパートナーおよび上流と共同作業を行い、Azure 上の OS で cloud-init が機能するようにします。』
⇧ と謳っている...
普通に考えたら、「責任」は「Microsoft」が負うべきだとは思うのだが...
で、
- Gen1 イメージと Gen2 イメージの両方を含む、RHEL 7 (バージョン 7.7) および RHEL 8 (バージョン 8.1) 以降の他のすべての RedHat SKU は、cloud-init を使用してプロビジョニングされます。 cloud-init は、RHEL 6 ではサポートされていません。
https://learn.microsoft.com/ja-jp/azure/virtual-machines/linux/using-cloud-init
⇧ とあり、「RHEL（Red Hat Enterprise Linux）」については、
- RHEL 7.7
- RHEL 8.1
以降のバージョンは須らく「cloud-init」を利用しているとある。
で、表題の件。
「ChatGPT」氏に、質問してみたところ、以下のような回答が返ってきた。
✅ 原因の全体像（RHEL 8.10 on Azure）
| 原因 | 説明 | 発生頻度 / コメント |
|---|---|---|
| 1. cloud-init による自動パーティション作成 | RHEL 8.10 Marketplace イメージは cloud-init が標準で有効化されている。起動時にディスクを検知して GPT パーティション /dev/sdc1 を作成する。fdisk で新規作成できなくなる最も多い原因。 |
★★★★★（ほぼ確定） |
| 2. ディスクアタッチのタイミング差 | VM 作成時のディスク追加タイミングによって cloud-init が検知するか否かが変わる。複数 VM でも「特定 VMだけ」再現する原因。 | ★★★★☆（環境依存） |
| 3. /dev/sdX 割り当て順差（LUN順序） | Azure では LUN の順番や物理ホストによってデバイス名が変わることがある。cloud-init は特定デバイスを基準に処理するため、VMごとに挙動が異なることがある。 | ★★★☆☆ |
| 4. GPT/MBR 残留情報 | 新規ディスクでもゼロ化されていない場合、以前の GPT ヘッダやパーティション情報が残ることがある。fdisk では全領域使用済みと認識。 | ★★☆☆☆（まれ） |
| 5. LVM 初期化済み / スナップショット由来 | ディスクが既に PV として初期化済み、あるいはスナップショット由来の場合。Marketplace 公式イメージでは通常なし。 | ★☆☆☆☆（稀） |
✅ 複数 VM で特定 VMだけ起きる理由
-
ディスクアタッチのタイミング差
-
VM作成時にディスクが既に存在 → cloud-init が処理
-
VM作成後にディスク追加 → cloud-init は既に完了 → 自動処理されない
-
-
デバイス名の割り当て順の違い
-
/dev/sdcがどの LUN に割り当てられるかで cloud-init の対象になるかが変わる
-
-
cloud-init の状態差
-
cloud-init は
/var/lib/cloud/に実行履歴を保存 -
初回扱いになるかどうかで処理が走るか変わる
-
💡 まとめ
- 最有力原因は cloud-init の自動パーティション作成
- 複数 VM で特定 VMだけ再現するのは cloud-init のタイミングや状態差による仕様上の副作用
- GPT/MBR 残留や LVM は稀だが、念のため確認可能
- Azure や RHEL のバグではなく、仕様上発生する現象
- 運用・IaC の観点では 冪等性がなく、問題として扱うことが妥当
いやはや、相も変わらず「Microsoft」は「ユーザー」を蔑ろにしてくれますよね...
まぁ、「生成AI」の「回答」が「幻覚（ハルシネーション）」を引き起こしているかもしれないのだが、そもそも、「Microsoft」が公式の「ドキュメント」に「仕様」として記載していないのが問題なのでありますからな...
再掲するが、
『Microsoft は、動作保証済み Linux ディストリビューションのパートナーと協力して、cloud-init 対応のイメージを Azure Marketplace で利用できるようにする作業を行っています。』
の「Linux ディストリビューション」は「動作検証済み」であるが、「cloud-init 対応のイメージ」はテストしていないということなんでしょうかね...
「Microsoft」は「品質保証（QA：Quality Assurance）」を全く行っていないということなのかしらね...
ちなみに、「ChatGPT」氏に、公式の「ドキュメント」で記載があるかについても質問してみたところ、以下のような回答が返ってきた。
📌 結論：Azure の公式ドキュメントに不具合に対する記載はない
Azure の公式ドキュメントには今回の原因・事象を直接説明する記述はありません。
- 公式は基本的な手順と cloud-init の概要までしか書かれておらず、
- 「cloud-init がデータディスクを自動的にパーティション化する可能性」や
- 「複数 VM でも結果が異なる理由」
などの細かい仕様上の挙動は説明されていません。
📌 結論：Red Hat の公式ドキュメントに不具合に対する記載はない
Red Hat の公式ドキュメントでも、今回のような現象（特定 VM で自動的にディスクがパーティションされてしまい fdisk で空きが見えない）についての説明はありません。
- cloud‑init の一般仕様は載っている
- cloud‑init のモジュール一覧は載っている
- だが その具体的挙動やデフォルト設定がどう影響するかは書かれていない
うむ、
- Microsoft
- Red Hat
ともに、万死に値するのだが...
とりあえず、「バグ」と言っても過言では無いと思うのだが...
もし、仮に、「ユーザー」が意識しないでも良いように「隠蔽」する意図があるのならば、「冪等性」は確実に維持して「ユーザー」が困らないようにして欲しいし、「隠蔽」することが難しいのであれば「ブラックボックス」な部分を無くすようにして欲しい...
今のところ、「冪等性」の無い挙動が許される風潮にあるのは、「幻覚（ハルシネーション）」の問題が根本的に解消できないと認識され始めた「生成AI」の振る舞いぐらいなものだとは思いますが...
仮にも、「Microsoft」は「ユーザー」から「お金」を請求している「サービス」として提供しているので、公式の「ドキュメント」に「仕様」を記載しておいて欲しいお気持ち...
一応、「ChatGPT」氏に、『Azureの仮想マシンの新規作成直後において、fdisk実行でパーティションの新規作成ができなくなるバグの解決方法』について質問してみたところ、以下のような回答が返ってきた。
📌 fdisk実行でパーティションの新規作成ができなくなるバグの解決方法
-
ディスク状況の確認
-
現在のディスクやパーティション、マウント状況を確認
-
cloud-init が触ったかどうかログを確認
-
-
マウント解除
-
ディスクや既存パーティションがマウントされていればアンマウント
-
マウント解除は wipefs/dd の前提条件
-
-
既存パーティション・ヘッダの削除
-
wipefs -aで GPT/MBR ヘッダを削除 -
ddでディスク先頭をゼロ化して fdisk が使える状態にする
-
-
cloud-init による自動初期化の無効化（再発防止）
-
disk_setup モジュールだけ無効化する方法が推奨
-
必要に応じて cloud-init を完全無効化するオプションもあり
-
-
fdisk で新規パーティション作成
-
fdisk で自由にパーティションを作成
-
「all space in use」のエラーは発生しない
-
-
ファイルシステム作成・マウント
-
mkfs で XFS 等のファイルシステムを作成
-
マウントして使用可能にする
-
永続マウントが必要なら /etc/fstab に追記
-
う～む...
兎にも角にも、「Microsoft」側の「設計」が完全に「ブラックボックス」であるからして、「トライアンドエラー」するしかない感じになりそうですな...
公式の「ドキュメント」に何某かの「情報」が記載されていれば、「対応方針」に迷わずに済んだのだろうが、「情報」が公開されていないからな...
故に、「生成AI」が「幻覚（ハルシネーション）」を引き起こしていようが引き起こしていまいが、他に「正解」に近付くための方法が無いに等しいので致し方ないのですな...
つまり、「不毛」な作業になるかもしれないと認識した上で、ひたすらに、「生成AI」との「壁打ち」を繰り返すしかないということですな...
まぁ、「生成AI」を利用できる利用できないに関係なく、「エンジニア」の「業務」は「燃え尽き症候群」になりがちな「リスク」を抱えている気がしますな...
ただただ、誠に遺憾である...
2026年3月20日（金）追記：↓ ここから
悲報...
Microsoftは機密性の高い情報を扱うユーザー向けのクラウドサービス群である「Government Community Cloud High(GCCH)」を、さまざまな政府機関や政府の請負業者に提供しています。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
しかし、アメリカ政府のクラウドサービス認証制度である米国連邦情報セキュリティ管理プログラム(FedRAMP)は繰り返しGCCHの問題を指摘していたにもかかわらず、政府内外の圧力を受けてGCCHを承認せざるを得なかったと、非営利報道機関のProPublicaが報じました。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
近年のアメリカ政府は政府が所有・運用するサーバーから、テクノロジー企業が管理するクラウドサーバーへの移行を進めてきました。2011年にはバラク・オバマ政権の下、クラウドサービスの導入を促進するためにFedRAMPが設立されました。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
FedRAMPはクラウドサービスのセキュリティが基準を満たしているかどうかを審査する機関であり、FedRAMPが認可したサービスはすべての政府機関で利用可能となる仕組みで、調達の効率化が進むと期待されていました。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
FedRAMPとの交渉でMicrosoft側の窓口となったジョン・バーギン氏は、やり取りが長引いた原因は明確な基準を提供しなかったFedRAMPにあると主張しています。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
しかし、連邦政府機関の顧客が利用するクラウドサービス構築に携わる2人の関係者によると、Microsoftのエンジニアでさえ自社製品のアーキテクチャを解明するのに苦労しているとのこと。問題となっていたのは、Microsoftがクラウドサービスの構築に使用した数十年前のレガシーソフトウェアのコードだったとされています。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
MicrosoftにとってFedRAMPとのやり取りを打ち切ることは、「GCCHにはセキュリティ上の懸念がある」というシグナルを市場に送ることを意味します。そこでMicrosoftのバーギン氏らは司法省関係者に働きかけて、GCCHがFedRAMPの承認を得られるように支援を求めたとのこと。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
この際に助力したのが、当時は司法省の最高情報責任者に昇進していたロジャース氏です。GCCHの導入によるIT化を高く評価されていたロジャース氏でしたが、FedRAMPがGCCHを承認しない限り、GCCHがハッキングを受けた際の責任を負わされるという立場にありました。また、司法省としてもすでに広く導入されているGCCHを撤回するには多額のコストと技術的困難が伴うため、GCCHの承認を押し進めるメリットがありました。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
⇧ 汚職やん...。腐敗しておりますな...
結局、多方面からの圧力を受けたFedRAMPは2024年の夏にGCCHを再審査することになりました。ProPublicaが入手した調査結果の概要によると、FedRAMPはGCCHに含まれる多くのサービスのうちExchange OnlineとTeamsの2つしか調査できなかったとのこと。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
しかし、この2つだけでもリスク管理の根本的な問題が特定され、依然としてMicrosoftから十分なセキュリティ文書が得られなかったとされています。あるチームメンバーはGCCHについて、「このパッケージはクソの山だ」と非難したそうです。
Microsoftのクラウドを連邦政府のサイバー専門家らは「クソの山」と非難していたが圧力を受けて承認していた - GIGAZINE
⇧ 何と言うか、「Microsoft」は内部の「ドキュメント」も崩壊しているっぽいですな...
そりゃあ、一般公開されている「ドキュメント」がゴミみたいなのも致し方ないということですかね...
2026年3月20日（金）追記：↑ ここまで
毎度モヤモヤ感が半端ない…
今回はこのへんで。
