Amazon Web Services での RHEL のデプロイと管理

手順

1. Python 3 と pip ツールをインストールします。

   # dnf install python3 python3-pip

2. pip を使用して AWS コマンドラインツール をインストールします。

   $ pip3 install awscli

3. AWS CLI 認証プロファイルを設定します。

   • 静的認証情報 (AWS アクセスキー) の設定: ターミナルで認証情報、リージョン、出力形式を入力するよう求められます。

     $ aws configure
     AWS Access Key ID [None]:
     AWS Secret Access Key [None]:
     Default region name [None]:
     Default output format [None]:

   • 動的認証情報の設定 (AWS SSO/IAM アイデンティティー Center): 組織で有効期限の短い動的認証情報を使用している場合は、別のプロファイルにログインしてください。リモートの SSH セッションで CLI を実行する場合は、--remote フラグを含めてください。

     $ aws login --region eu-central-1 --profile auth --remote

     ブラウザーで認証を行うには、表示されるリンクをクリックしてください。これにより、~/.aws/config ファイルにエントリーが作成されます。

     [profile auth]
     region = eu-central-1
     login_session = arn:aws:sts::12345678910:assumed-role/12345678910-admin/<username>

     重要

     image-builder は AWS SDK for Go v2 を使用していますが、これは動的な認証情報をネイティブにサポートしていません。上記のプロファイルのみを使用してアップロードしようとすると、認証情報は黙って無視され、次のエラーが発生します。取得中: 操作エラー S3: CreateMultipartUpload、アイデンティティーの取得: 認証情報の取得: キャッシュされた認証情報の更新に失敗しました、EC2 IMDS ロールが見つかりません…この制限を回避するには、[default] または別の指定プロファイルを設定して credential_process を使用します。これは、動的なセッショントークンを、image-builder が 読み取ることができる静的な認証情報にマッピングします。~/.aws/config ファイルに以下を追加してください。

     [default]
     region = eu-central-1
     credential_process = aws configure export-credentials --profile auth --format process

4. バケットの名前を定義し、バケットを作成します。

   $ BUCKET=<bucketname>

   $ aws s3 mb s3://$BUCKET

   <bucketname> を 実際のバケット名に置き換えてください。この名前は、グローバルで一意となるように指定する必要があります。

5. Simple Storage Service (S3) へのアクセス権限を付与するには、AWS Identity and Access Management (IAM) で vmimport ロールを作成します (まだ作成していない場合)。

   1. 信頼ポリシー設定を含む trust-policy.json ファイルを JSON 形式で作成します。以下に例を示します。

      {
          "Version": "2012-10-17",
          "Statement": [{
              "Effect": "Allow",
              "Principal": {
                  "Service": "vmie.amazonaws.com"
              },
              "Action": "sts:AssumeRole",
              "Condition": {
                  "StringEquals": {
                      "sts:Externalid": "vmimport"
                  }
              }
          }]
      }

   2. ロールポリシーの設定を JSON 形式で記述した role-policy.json ファイルを作成します。

      {
          "Version": "2012-10-17",
          "Statement": [{
              "Effect": "Allow",
              "Action": ["s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket"],
              "Resource": ["arn:aws:s3:::%s", "arn:aws:s3:::%s/"] }, { "Effect": "Allow", "Action": ["ec2:ModifySnapshotAttribute", "ec2:CopySnapshot", "ec2:RegisterImage", "ec2:Describe"],
              "Resource": "*"
          }]
      }

      $BUCKET $BUCKET

   3. trust-policy.json ファイルを使用して、Amazon Web Services アカウントのロールを作成します。

      $ aws iam create-role --role-name vmimport --assume-role-policy-document \file://trust-policy.json

   4. role-policy.json ファイルを使用して、インラインポリシードキュメントを埋め込みます。

      $ aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document \file://role-policy.json

手順

1. イメージをビルドします。

   $ sudo image-builder build ami \
     --blueprint <blueprint_name> \
     --aws-region us-east-1 \
     --aws-bucket <example_bucket> \
     --aws-ami-name <image_name>

2. イメージを AWS にアップロードしてください。単体の RAW イメージの場合は、以下のアップロードコマンドを使用してください。

   $ sudo image-builder upload rhel-10.1-ami-x86_64.raw \
   --to=aws --aws-region=eu-central-1 \
   --aws-bucket=<my_bucket> --aws-ami-name <image_name>

   デフォルトプロファイルの回避策を使用して動的認証情報を設定した場合、アップロード コマンドは設定済みの credential_process フローを自動的に使用します。

検証

1. AWS コンソールで利用可能な EC2 イメージを確認し、正しいリージョンを選択してください。
2. ダッシュボードでイメージを選択し、Launch をクリックします。

手順

1. RHEL Image Builder ダッシュボードの blueprint name でブループリントを選択します。Images タブを選択し、Create Image をクリックします。

2. Type ドロップダウンメニューのリストから Amazon Machine Image Disk (.raw) を選択し、Upload to AWS にチェックを入れて Next をクリックします。

   注記

   シークレットキー がわからない場合は、新しい アクセスキー ID を生成してください。

3. 対応するフィールドに AWS access key ID と AWS secret access key を入力します。Next をクリックします。
4. イメージ名、Amazon S3 バケット 名、AWS リージョン を入力し、[次へ] をクリックします。
5. 情報を確認し、Finish をクリックします。Image build complete ステータスになるまで待ちます。
6. AWS コンソールで Service→EC2 に移動し、正しいリージョンを選択して、イメージのステータスが Available になっていることを確認します。
7. イメージを選択して Launch をクリックし、インスタンスタイプを選択し、Review and Launch をクリックします。

8. インスタンスの詳細を確認して Launch をクリックし、キーペアを選択または作成します。

   • 新しいキーペアを作成するには、Create a new key pair を選択し、名前を入力して Download Key Pair をクリックします。
9. Launch Instance をクリックし、インスタンスのステータスが running になるまで待ちます。

10. Connect をクリックし、SSH を使用してインスタンスにアクセスします。

    $ chmod 400 <your_instance_name>.pem

    $ ssh -i <your-instance_name>.pem \\
    ec2-user@<your-instance-IP-address>

    1. yes と入力して接続を確認します。

手順

1. Red Hat Enterprise Linux (RHEL) 仮想マシンを設定します。詳細は、関連情報セクションを参照してください。

   1. CLI からインストールする場合は、仮想マシンの要件に応じて、デフォルトのメモリー、ネットワークインターフェイス、および CPU を設定してください。
   2. RHEL は Web コンソールからもインストールできます。

2. インストールが開始されたら、以下を実行します。

   1. root のパスワードを作成します。
   2. 管理者ユーザーアカウントを作成します。
3. インストールが完了してから、仮想マシンを再起動して root アカウントにログインします。
4. root としてログインすると、イメージを設定できます。

5. 仮想マシンを登録し、RHEL リポジトリーを有効にします。

   # subscription-manager register

6. AMD64 または Intel 64 (x86_64) 仮想マシンの場合は、nvme ドライバー、xen-netfront ドライバー、および xen-blkfront ドライバーをインストールします。

   # dracut -f --add-drivers "nvme xen-netfront xen-blkfront"

7. ARM 64 (aarch64) 仮想マシンの場合は、nvme ドライバーをインストールします。

   # dracut -f --add-drivers "nvme"

   これらのドライバーを含めると、dracut のタイムアウトが防止されます。

   ここでは、ドライバーを /etc/dracut.conf.d/ に追加し、dracut -f を入力して既存の initramfs ファイルを上書きできます。

8. cloud-init パッケージをインストールしてください。

   # dnf install cloud-init

9. cloud-init サービスを有効にして起動します。

   # systemctl enable --now cloud-init.service

10. 変更を適用するには、仮想マシンを再起動してください。

手順

1. AWS Red Hat Update Infrastructure (RHUI) クライアントを削除します。

   # dnf -y remove rh-amazon-rhui-client

2. 仮想マシンを Red Hat に登録します。

   # subscription-manager register

3. すべてのリポジトリーを無効にします。

   # subscription-manager repos --disable=

4. Red Hat Enterprise Linux (RHEL) 10 Server HA リポジトリーを有効にします。

   # subscription-manager repos --enable=rhel-10-for-x86_64-highavailability-rpms

5. RHEL AWS インスタンスを更新します。

   # dnf update -y

6. High Availability チャネルから、Red Hat High Availability Add-On ソフトウェアパッケージと AWS フェンスエージェントをインストールします。

   # dnf install pcs pacemaker fence-agents-aws

7. 前のステップで pcs および pacemaker をインストールした際に、ユーザー hacluster が作成されます。すべてのクラスターノードに hacluster のパスワードを作成します。すべてのノードに同じパスワードを使用します。

   # passwd hacluster

8. firewalld.service がインストールされている場合は、RHEL ファイアウォールに high availability サービスを追加します。

   # firewall-cmd --permanent --add-service=high-availability

   # firewall-cmd --reload

9. pcs サービスを開始し、起動時に自動的に開始されるように設定してください。

   # systemctl enable --now pcsd.service

10. /etc/hosts ファイルを編集し、RHEL のホスト名と内部 IP アドレスを追加してください。詳細は、RHEL クラスターノードに /etc/hosts ファイルを設定する を参照してください。

手順

1. pcs を実行するノードでクラスター内の各ノードの pcs ユーザー hacluster を認証します。

   [root@z1 ~]# pcs host auth z1.example.com z2.example.com

   Username: hacluster
   Password:
   z1.example.com: Authorized
   z2.example.com: Authorized

   このコマンドは、z1.example.com と z2.example.com で設定される 2 ノードクラスターの両方のノードに対して、z1.example.com 上でユーザー hacluster を 認証します。

2. z1.example.com ノードから以下のコマンドを実行して、z1.example.com と z2.example.com の 2 つのノードからなるクラスター my_cluster を作成します。

   [root@z1 ~]# pcs cluster setup my_cluster --start z1.example.com z2.example.com

   これにより、クラスター設定ファイルが、クラスターの両ノードに伝搬されます。このコマンドには --start オプションが含まれます。このオプションを使用すると、クラスターの両ノードでクラスターサービスが起動します。

3. ノード起動時に、クラスター内の各ノードでクラスターサービスが実行されるように設定してください。

   注記

   特定の環境要件がある場合は、クラスターサービスを無効のままにすることで、この手順を省略できます。有効の場合にノードがダウンすると、ノードがクラスターに再参加する前に、クラスターまたはリソースに関する問題は解決されます。クラスターサービスを無効にしたままにする場合は、ノードを再起動する際に、そのノードで pcs cluster start コマンドを実行して、サービスを手動で起動してください。

   [root@z1 ~]# pcs cluster enable --all

手順

1. us-east-1a アベイラビリティーゾーンに共有ブロックボリュームを作成します。

   $ aws ec2 create-volume --availability-zone <us_east_1a> --no-encrypted --size <1024> --volume-type <io1> --iops <51200> --multi-attach-enabled
   
   {
       "AvailabilityZone": "us-east-1a",
       "CreateTime": "2020-08-27T19:16:42.000Z",
       "Encrypted": false,
       "Size": 1024,
       "SnapshotId": "",
       "State": "creating",
       "VolumeId": "vol-042a5652867304f09",
       "Iops": 51200,
       "Tags": [ ],
       "VolumeType": "io1"
   }

2. クラスター内のインスタンスごとに、共有ブロックボリュームをアタッチします。実際の <instance_id> と <volume_id> を使用してください。たとえば、vol-042a5652867304f09 や instance i-0eb803361c2c887f2 などです。

   $ aws ec2 attach-volume --device /dev/xvdd --instance-id i-0eb803361c2c887f2 --volume-id vol-042a5652867304f09
   
   {
       "AttachTime": "2020-08-27T19:26:16.086Z",
       "Device": "/dev/xvdd",
       "InstanceId": "i-0eb803361c2c887f2",
       "State": "attaching",
       "VolumeId": "vol-042a5652867304f09"
   }

検証

1. クラスター内の各インスタンスに対して、インスタンス IP 198.51.100.3 を指定し、ssh コマンドを使用してブロックデバイスが使用可能であることを確認します。

   # ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T '"
   
   node a
   nvme2n1 259:1    0   1T  0 disk

2. ssh コマンドを使用して、クラスター内の各インスタンスが同じ共有ディスクを使用していることを確認します。

   # ssh 198.51.100.3 "hostname ; lsblk -d | grep ' 1T ' | awk '{print \$1}' | xargs -i udevadm info --query=all --name=/dev/{} | grep '^E: ID_SERIAL='"
   
   nodea
   E: ID_SERIAL=Amazon Elastic Block Store_vol0fa5342e7aedf09f7

1. 初期化: RHEL インスタンスが起動すると、クラウドでホストされているファームウェアが最初に起動し、セキュアブートメカニズムを実装します。
2. 変数ストアの初期化: ファームウェアは、変数ストアから UEFI 変数を初期化します。これは、ファームウェアが起動プロセスと実行時操作を管理するために必要な情報を格納するための専用領域です。RHEL インスタンスが初めて起動すると、ストアは仮想マシンイメージに関連付けられたデフォルト値によって初期化されます。

3. ブートローダー: ブート時に、ファームウェアは第 1 段階のブートローダーをロードします。x86 UEFI 環境の RHEL インスタンスの場合、第 1 段階のブートローダーは shim です。シムブートローダーは認証を行い、ブートプロセスの次の段階をロードします。これは UEFI と GRUB の間の橋渡し役を果たします。

   1. RHEL に含まれる shim x86 バイナリーは、Microsoft Corporation の UEFI CA 2011 証明書によって署名されています。
   2. RHEL インスタンスは、shim バイナリーを使用して、さまざまなハードウェアおよび仮想化プラットフォーム上でセキュアブート有効モードで起動します。
   3. プラットフォームの許可された署名データベース (db) にデフォルトの Microsoft 証明書があることを確認してください。
   4. shim バイナリーは、Red Hat Secure Boot CA と、必要に応じて Machine Owner Key (MOK) を使用して、信頼済み証明書のリストを拡張します。

4. UKI: shim バイナリーは、RHEL UKI (kernel-uki-virt パッケージ) をロードします。対応する証明書 (x86_64 アーキテクチャーでは Red Hat Secure Boot Signing 504) が UKI に署名します。

   1. この証明書は redhat-sb-certs パッケージにあります。この証明書は Red Hat Secure Boot CA によって署名されているため、チェックは成功します。
5. UKI アドオン:RHEL カーネルは、UKI コマンドライン 拡張機能を使用する場合、db、MOK、および shim 証明書に対して署名を検証します。このプロセスにより、オペレーティングシステムベンダー、RHEL、またはユーザーのいずれかが拡張機能に署名していることが保証されます。

手順

1. カスタム証明書 custom_db.cer を生成します。

   $ openssl req -quiet \
   -newkey rsa:3072 \
   -nodes -keyout custom_db.key \
   -new -x509 -sha256 \
   -days 3650 \
   -subj "/CN=Signature Database key/" \
   --outform DER -out custom_db.cer

2. virt-fw-vars ユーティリティーを使用して UEFI 変数ファイルを生成します。

   $ virt-fw-vars --enroll-redhat \
   --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
   --set-dbx /usr/share/edk2/ovmf/DBX* \
   --output-auth

   詳細は、システム上の virt-fw-vars(1) man ページを参照してください。

3. UEFI 変数を Extensible Firmware Interface (EFI) Signature List (ESL) 形式に変換します。

   $ for f in PK KEK db dbx; do tail -c +41 $f.auth > $f.esl; done

   注記

   各 GUID は割り当てられた値であり、EFI パラメーターを表します。

   • 8be4df61-93ca-11d2-aa0d-00e098032b8c: EFI_GLOBAL_VARIABLE_GUID
   • d719b2cb-3d3a-4596-a3bc-dad00e67656f: EFI_IMAGE_SECURITY_DATABASE_GUID

   EFI_GLOBAL_VARIABLE_GUID パラメーターは、ブート可能なデバイスとブートマネージャーの設定を保持します。一方、EFI_IMAGE_SECURITY_DATABASE_GUID パラメーターは、セキュアブート変数である db、dbx、および必要な鍵と証明書を保存するためのイメージセキュリティーデータベースを表します。

4. データベース証明書をターゲットインスタンスに転送し、efivar ユーティリティーを使用して UEFI 環境変数を管理します。

   1. PK.esl を転送するには、次のように入力します。

      $ sudo efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK -f PK.esl

   2. KEK.esl を転送するには、次のように入力します。

      $ sudo efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK -f KEK.esl

   3. db.esl を転送するには、次のように入力します。

      $ sudo efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-db -f db.esl

   4. x64 アーキテクチャー用の dbx.esl UEFI 失効リストファイルを転送するには、次のように入力します。

      $ sudo efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -f dbx.esl

5. AWS コンソールからインスタンスを再起動します。

手順

1. カスタム証明書 custom_db.cer を生成します。

   $ openssl req -quiet \
   -newkey rsa:3072 \
   -nodes -keyout custom_db.key \
   -new -x509 -sha256 \
   -days 3650 -subj "/CN=Signature Database key/" \
   --outform DER -out custom_db.cer

2. virt-fw-vars ユーティリティーを使用して、キー、データベース証明書、および UEFI 変数ストアから aws_blob.bin バイナリーファイルを生成します。

   $ virt-fw-vars --enroll-redhat \
   --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
   --set-dbx /usr/share/edk2/ovmf/DBX* \
   --output-aws aws_blob.bin

   カスタマイズされた Blob は次のもので構成されます。

   • edk2-ovmf パッケージに含まれる PK.cer、KEK.cer、db、および dbx
   • custom_db.cer 生成された証明書

3. awscli2 ユーティリティーを使用して、必要なセキュアブート変数を含むディスクスナップショットから AMI を作成し、登録します。

   $ aws ec2 register-image \
   --name rhel-10.0-secure-boot \
   --architecture x86_64 \
   --virtualization-type hvm \
   --root-device-name "/dev/sda1" \
   --block-device-mappings "{\"DeviceName\": \"/dev/sda1\",\"Ebs\": {\"SnapshotId\": \"<snap-02d4db3813ff9b98e>\"}}" \
   --ena-support --boot-mode uefi \
   --region eu-central-1 \
   --uefi-data $(cat aws_blob.bin)
   --output json

   {
       "ImageId": "example-ami-id"
   }

4. AWS コンソールからインスタンスを再起動します。

1. 初期化と測定: SEV-SNP 対応ハイパーバイザーが、仮想マシンの初期状態を設定します。

   1. このハイパーバイザーは、ファームウェアバイナリーを仮想マシンメモリーにロードし、初期レジスター状態を設定します。
   2. AMD Secure Processor (SP) が仮想マシンの初期状態を測定し、仮想マシンの初期状態を検証するための詳細を提供します。

2. ファームウェア: 仮想マシンが UEFI ファームウェアを初期化します。ファームウェアには、ステートフルまたはステートレスな Virtual Trusted Platform Module (vTPM) 実装が含まれる場合があります。

   1. ステートフル vTPM は、仮想マシンの再起動や移行後も永続的な暗号化状態を維持します。
   2. ステートレス vTPM は、永続性なしに、仮想マシンセッションごとに新しい暗号化状態を生成します。
   3. vTPM は、Virtual Machine Privilege Levels (VMPL) テクノロジーによってゲストから隔離されます。
   4. VMPL は、各仮想マシンコンポーネントとハイパーバイザー間のハードウェアによる特権分離を提供します。

3. vTPM: ステートフルな vTPM 実装の場合、UEFI ファームウェアがリモートアテステーションを実行する可能性があります。

   1. これは、ご利用のクラウドサービスプロバイダーによって異なります。アテステーションは、vTPM の永続状態を復号化します。

   2. vTPM はブートプロセスに関する情報も測定します

      • セキュアブート状態
      • ブート署名に使用される証明書アーティファクト
      • UEFI バイナリーハッシュ

4. Shim: UEFI ファームウェアは、初期化プロセスを完了すると、拡張ファームウェアインターフェイス (EFI) システムパーティションを検索します。

   1. UEFI ファームウェアは、そこから最初のステージのブートローダーを検証して実行します。
   2. RHEL の場合、これは shim です。shim プログラムは、Microsoft 以外のオペレーティングシステムが、EFI システムパーティションから第 2 段階のブートローダーを読み込むことを可能にします。
   3. shim は Red Hat の証明書を使用して、第 2 段階のブートローダー (grub) または Red Hat Unified Kernel Image (UKI) を検証します。
   4. grub または UKI は、Linux カーネルと初期 RAM ファイルシステム (initramfs)、およびカーネルコマンドラインを展開、検証、実行します。
   5. このプロセスにより、Linux カーネルが信頼できる安全な環境でロードされることが保証されます。

5. Initramfs: initramfs の処理中、フルディスク暗号化テクノロジーが使用されている場合、暗号化されたルートパーティションのロックが vTPM の情報によって自動的に解除されます。

   1. ルートボリュームが使用可能になると、initramfs は実行フローをルートボリュームへ移行します。

6. アテステーション: 仮想マシンテナントはシステムへのアクセス権を取得します。彼らはリモートでアテステーションを実行して、VM が改ざんされていない機密仮想マシン (CVM) であることを確認できます。

   1. アテステーションは、AMD SP および vTPM からの情報に基づいて実行されます。
   2. このプロセスにより、RHEL インスタンスおよび AMD プロセッサーの初期 CPU とメモリーの状態の真正性と信頼性が確認されます。
7. TEE: このプロセスでは、仮想マシンが信頼できるセキュアな環境で起動されるように、Trusted Execution Environment (TEE) を構築します。

手順

1. SEV-SNP が有効になっていない場合に、RHEL AMI の ID を取得する:

   $ aws ec2 describe-images \
   --owners 309956199498 \
   --query 'sort_by(Images, &Name)[*].[CreationDate,Name,ImageId]' \
   --filters "Name=name,Values=RHEL-10*" \
   --region us-east-1

   ...
   "RHEL-10.0_HVM-amd64-..",
   "ami-0a1b2c3d4e5f67890"
   ...

   警告

   コマンドオプション --owners 309956199498 は変更しないでください。これは、Red Hat イメージを表示するためのアカウント ID です。AWS GovCloud のイメージをリスト表示する必要がある場合は、--region us-gov-west-1 と --owners 219670896067 を使用します。

2. AMD SEV-SNP を有効にした RHEL インスタンスを起動します。

   $ aws ec2 run-instances \
   --image-id <example-rhel-10-ami-id> \
   --instance-type m6a.4xlarge \
   --key-name <example_key_pair_name> \
   --subnet-id <example_subnet_id> \
   --cpu-options AmdSevSnp=enabled

1. UEFI ファームウェア: ブートプロセスは、UEFI (Unified Extensible Firmware Interface) ファームウェアから始まります。

   1. 従来の basic input/output system (BIOS) ファームウェアはサポートされていないため、Red Hat Enterprise Linux (RHEL) UKI の起動には UEFI ファームウェアが必要です。

2. Shim ブートローダー:UEFI ファームウェアから UKI (PE バイナリー) を直接起動するのではなく、shim ブートローダーを使用して起動します。

   1. shim には、Machine Owner Key (MOK) やセキュアブートアドバンストターゲティング (SBAT) などの追加のセキュリティーメカニズムが含まれています。

3. 署名検証 (セキュアブート UEFI メカニズム): ブート中に、shim は UKI バイナリーを読み取り、セキュアブート UEFI メカニズムが UKI の署名を検証します。

   1. この署名検証は、システムのセキュアブート許可署名データベース (db)、MOK データベース、および shim バイナリーの組み込みデータベースに保存されている信頼できる鍵に対して行われます。
   2. 署名キーが有効であれば、検証は成功します。

4. SBAT 検証: 署名検証の直後、shim ブートローダーは起動時に SBAT ルールを検証します。

   1. SBAT 検証中、システムは、.sbat セクションを使用して、UKI に組み込まれている systemd.rhel や linux.rhel などのコンポーネントの世代番号を、shim ブートローダーの値と比較します。

   2. shim 内のコンポーネントの世代番号が UKI の世代番号よりも大きい場合、信頼できる鍵で署名されていても、バイナリーは自動的に破棄されます。

      世代番号は、shim や grub などの UEFI アプリケーションのバージョン識別子であることに注意してください。

5. 展開と実行: 検証が成功すると、制御は shim から UKI 内の systemd-stub コードに渡され、ブートプロセスが続行されます。

6. systemd-stub アドオン: 実行時に、systemd-stub は、.cmdline セクション (プレーンテキストのカーネルコマンドライン) と .initrd セクション (一時的なルートファイルシステム) の内容を展開して、ブートプロセスに使用します。

   systemd-stub は、PE バイナリーでもある UKI アドオンを読み込み、その署名を検証し、アドオンの .cmdline コンテンツを追加して UKI のカーネルコマンドラインを安全に拡張することに注意してください。systemd-stub は、アドオンを 2 つの場所から読み込みます。

   • Extensible Firmware Interface (EFI) システムパーティション (ESP) 上の /loader/addons/ ディレクトリーにあるグローバル (UKI 非依存) アドオン。
   • ESP 上の /EFI/Linux/<UKI-name>.extra.d/ ディレクトリーからの UKI ごとのアドオン。

7. 制御は systemd-stub から Linux カーネルに渡され、オペレーティングシステムの起動プロセスが続行されます。

   ここから先は、UKI メカニズムを使用したセキュアブートは、標準的なカーネルブートプロセスに従います。