Ubuntu 25.10 その19 - Ubuntu Desktop ARM64 とハードウェア構成の違い・stubble の導入とセキュアブートの対応

Ubuntu Desktop ARM64 とハードウェア構成の違い

Ubuntu 25.10 でも Qualcomm Snapdragon など ARM64 向け Ubuntu Desktop がリリースされます。



この Ubuntu Desktop ARM64 は、特定のデバイス（PC）に対応したものではなく、特定のデバイスに依存せず汎用的に利用可能な ARM64 向け Ubuntu Desktop です。

デバイスごとに固有の違いがある

ARM64 デバイスで汎用的に利用可能とはいっても、各デバイスごとにデバイス固有の違いがあります。
ユーザーに汎用的に利用可能な Ubuntu Desktop ARM64 を提供するなら、このデバイス固有の違いをうまく吸収する仕組みが必要になります。

違いを簡単に吸収できるプラットフォームではない

さて x86_64（amd64）のようにデバイスのハードウェア構成を Ubuntu 側から把握できるような標準的な仕組みがデバイス側に実装されていればよいのですが、残念ながらそうはなっていません。
言い換えるとハードウェアを抽象化する十分な仕組みがありません。

そのため汎用的にサポートするにはまずこの課題を乗り越えねばならず、Ubuntu にとって挑戦に類する取り組みになります。

ACPI

ACPI（Advanced Configuration and Power Interface）は Intel、Microsoft、そして東芝が策定し、1996年に登場した標準規格です。

x86 向けの仕組みとして登場

元々 ACPI は x86 向けの仕組みとして登場し、時代に合わせ拡張され今に至ります。

ちなみに 2011年12月にリリースされた ACPI 5.0 では、ARM アーキテクチャーのサポートが含まれるようになりました。

さらに 2025年5月にリリースされた ACPI 6.6 では、RISC-V アーキテクチャーのサポートが含まれるようになりました。

ARM64 でも支持が広がりつつある

ARM64 でも Base System Architecture（BSA）や Base Boot Requirements（BBR） の標準的な仕様の一部として、ACPI の採用支持が広がりつつあります。
とはいえ ACPI を採用していないデバイスも多いですし、採用していたとしても Linux から扱えないケースもあります。

ハードウェア構成の情報を含まれる

ACPI には OS がハードウェア構成の把握や管理、操作を行うための情報が含まれています。

ACPI テーブル

ACPI に対応したファームウェアは ACPI テーブルを生成し、カーネルが内部で実装しているインタープリターが解釈可能な AML（ACPI Machine Language）バイトコードを提供します。

この仕組みのおかげでデバイスを開発するメーカーは、デバイス固有の処理の大半をファームウェアで実装できるようになり、加えて OS とカーネルはハードウェア固有の事情を把握しなくてもハードウェア固有の処理をファームウェアを通じて処理できるようになります。

Device Tree

もう一つの仕組みが Device Tree です。

ハードウェア記述形式

Device Tree（DT/DTB）は、arm64 組み込みデバイスやスマートフォン、Chromebook、Apple ノート PC の標準的なハードウェア記述形式です。

ハードウェアレイアウトとロジックの実装

ACPI とは対照的に Device Tree はハードウェアのレイアウト（設定）を記述するものです。
つまり Device Tree にデバイス固有の実装は含まれていません。
デバイス固有の実装はカーネルドライバーに含まれています。

この手法による利点は、静的なハードウェア構成情報と実装ロジックを分離できる点です。
ファームウェアはほぼ変更されない静的なハードウェア構成情報を提供する一方で、実装ロジックはカーネルのアップデートにより実装ロジック自体を容易に変更できます。

この手法の欠点は、デバイスの開発ベンダーがまずアップストリームの Linux kernel にデバイスを制御する実装ロジックを提供し取り込んでもらう必要がありますが、一部のベンダーはこの作業自体が困難であると感じています。

Linux における Snapdragon X のサポート

Linux における Snapdragon X のサポート事情はちょっと複雑です。

ACPI に対応しているが

ファームウェアは ACPI を実装しているのですが、この実装は Windows 向けであり残念ながら Linux から利用できません。
言い換えると Linux と互換性のない実装になっています。

アップストリームの Linux kernel はどうしたのか

そこでアップストリームの Linux kernel はこのプラットフォームをサポートするために、Device Tree を使用することにしました。

しかしファームウェアは Device Tree を提供していません。
そのため EFI ブートチェーンの一部として Device Tree を読み込むようにしなければなりません。

Linux ディストリビューションはどうすればよいのか

これは Linux ディストリビューションにとって新たな課題です。
汎用的に利用可能な ARM64 向け Linux ディストリビューションを提供するためには、カーネルが読み込まれる前に、何らかの方法でデバイスを識別する仕組みと Device Tree を管理する仕組みを実装しなければなりません。

加えて Device Tree は Linux kernel のソースコードの一部になるため、継続的にアップデートや開発していかなければならならず、一度作成して終わりではありません。
つまり Device Tree を静的な情報として定義することはできません。

Ubuntu 25.04 ではどうしていたのか

Ubuntu 25.04 でも Ubuntu Desktop ARM64 をリリースしているため、当然同じ事情があります。

インストーラー

Ubuntu 25.04 ではまずインストーラーの GRUB に Device Tree の読み込みロジックを導入しました。

この実装では起動デバイスを識別するために smbios コマンドを利用し、必要に応じてその起動デバイスに対応した Device Tree を読み込むための devicetree コマンドを追加しています。
この組み合わせで Device Tree を読み込んでいます。
この処理自体は全体を通じて初回起動時にのみ行われます。

flash-kernel パッケージ

その後インストーラーは flash-kernel パッケージをインストールします。
このパッケージはカーネルアップデート時に実行される kernel update hook をインストールします。
この hook は新しいカーネルパッケージから起動デバイスに対応した Device Tree を探し出し、その Device Tree を /boot ディレクトリーにインストールします。

update-grub

GRUB には update-grub を実行するための hook があり、この hook で新しいカーネルや initrd、Device Tree を検索し、それぞれに対応する起動メニューエントリーを生成します。
一連の流れを図にすると、以下のようになります。

汎用イメージを作れるようになったが

これらの方法で様々な ARM64 ノート PC に対応した Ubuntu Desktop ARM64 を提供できるようになりましたが、いくつか制約が残りました。

新しいデバイスをサポートするためにデバイス固有のロジックを、複数のパッケージに追加する必要がありました。
加えてセキュアブートと互換性のない未署名の Device Tree を読み込むため、セキュアブートモードで利用できない GRUB の機能に依存することになりました。

他の Linux ディストリビューションはどうしているのか

他の Linux ディストリビューションでは、postmarketOS に使われている dtbloader を使用して課題に対応しています。

dtbloader

dtbloader は EFI ドライバーであり、Device Tree の検索と EFI Configuration Table へ Device Tree をインストールする機能を持っています。

• dtbloader

Hardware ID を利用

デバイスの識別にSMBIOS から取得した生の値を直接比較するのではなく、SMBIOS Table から生成される Hardware ID（UUID）を用いてデバイスを識別します。

• Specifying Hardware IDs for a computer