診断割り込みAPIを実行してカーネルパニックをさせてみた

AWSのAPI経由でカーネルパニックを発生させることができますよ。
2021.06.10

いつもは守りたいカーネルをパニックさせたい。そんな時もある。

こんにちは、のんピ です。

皆さんは「このOS、カーネルパニックさせたいなぁ」と思ったことはありますか? 私はあります。

具体的には、OS構築時のクラッシュダンプ取得テスト時に「カーネルパニックさせたいなぁ」と思います。それ以外の場面では一切思いません。

従来、カーネルパニックを発生させるためには、OS内でコマンドや設定変更を行うことで発生させていました。
実はAWSのAPIを使えば、OSの外からでもカーネルパニックを発生させることができるのはご存知でしょうか。

今回はそのAWSのAPIである、診断割り込みを使ってカーネルパニックを発生させ、ついでにクラッシュダンプを分析してみようと思います。

いきなりまとめ

  • 診断割り込みAPIでLinuxをカーネルパニックをさせるには事前に設定が必要
  • カーネルパニックを意図的に発生させる前にはAMIなどを事前に作成して不測の事態に備える

カーネルパニックってなに??

カーネルパニックとは、OSの中核であるカーネルで致命的なエラーを検知して正常に動作しなくなる状態です。

Windowsマシンの場合はカーネルパニックが発生した時に、青い画面が表示されることから、「ブルースクリーン」と呼ばれることがあります。

動いていたマシンが正常に動作しなくなるので、基本的にはカーネルパニックが発生したら、超異常事態です。 ただ、USBメモリを挿すと30%ぐらいの確率でブルースクリーンになるマシンを見たこともあるので、マシンによっては超異常事態ではないかもしれないです。

クラッシュダンプってなに??

クラッシュダンプは、先ほど紹介したカーネルパニックなどでソフトウェアが異常終了した際に、出力するダンプファイルです。

クラッシュダンプは異常終了時のメモリの内容出力するので、「メモリダンプ」とも呼ばれます。

クラッシュダンプには異常終了時のメモリの内容が含まれているので、クラッシュダンプを分析することで、異常終了の原因を調べる助けにもなります。

診断割り込みAPIってなに??

診断割り込みAPIと呼ばれていますが、NMI(マスク不可能な割り込み: Non-maskable interrupt)を実行するAPIです。

NMIスイッチと聞けば、物理サーバーを扱ったことがあることはご存知かもしれません。

NMIスイッチを押した時の挙動としては、対象のマシンに対して、マスク不可能な割り込み(割り込み禁止にできない処理)を送信して、強制的にマシンを停止させるものです。

AWSの診断割り込みAPI実行時もイメージとしては、NMIスイッチを押された状態になります。
要するに、現在の処理に強制的に割り込んで、OSを異常終了させます。

なお、診断割り込みAPIを受け付けるEC2インスタンスは、以下、AWS公式ドキュメントの通り、インスタンスタイプの種類によります。

A1 を除き、診断割り込みはすべての Nitro ベースインスタンスタイプでサポートされます。詳細については、「Nitro System 上に構築されたインスタンス」を参照してください。

診断割り込みの送信 (上級ユーザーのみ) - サポートされるインスタンスタイプ

Windows Server 2019でやってみた

準備

まず、Windows Server 2019に対して、診断割り込みAPIを実行して、カーネルパニックを発生させ、クラッシュダンプを分析したいと思います。

Windowsマシンの準備は、後述するLinuxと比べて簡単です。

まず、出力するクラッシュダンプの種類を選択します。

OSログイン後、[コントロールパネル] - [システム] - [システムの詳細設定] - [システムのプロパティ] - [詳細設定] - [起動と回復] - [設定]をクリックします。

システムエラーセクションでクラッシュダンプの種類を変更します。今回は不要なページを除外した完全なメモリダンプを取得したいのでアクティブメモリダンプを選択して、OKをクリックします。
その他のクラッシュダンプの種類は、こちらのMicrosoftの公式ドキュメントをご確認ください。

Windowsマシンの場合はクラッシュダンプ作成時に、仮想メモリ(ページングファイル)を使用します。そのため、クラッシュダンプの種類と、EC2インスタンスのメモリー容量によっては仮想メモリの容量を変更する必要があります。

検証用のEC2インスタンスの仮想メモリを確認すると、以下の通り、1024MBしかありません。
しかし、検証用のEC2インスタンスの搭載メモリーが1GBで、クラッシュダンプの種類もアクティブメモリダンプであり、1024MBを丸々使うということは想定しづらいので、今回はデフォルトのままとします。

診断割り込みAPIの実行

それでは、診断割り込みAPIを実行して、カーネルパニックを発生させてみます。 AWS CLIで診断割り込みAPIの実行するコマンドは以下の通りです。

> aws ec2 send-diagnostic-interrupt --instance-id i-0b86aa6c515dcd32f 
>

コマンドを実行すると、ターミナル上に特にメッセージは出力されず、OSが再起動します。

クラッシュダンプの分析

診断割り込みAPI実行後、OSにログインしてクラッシュダンプを確認してみます。

デフォルトのクラッシュダンプの出力先である%SystemRoot%を確認すると、以下の通り、クラッシュダンプが出力されていることが確認できます。

それでは、出力されたクラッシュダンプの分析をしてみます。

分析をする際には、WinDbgというデバッガーを使用します。 WinDbgはこちらのMicrosoftの公式ドキュメントからダウンロードします。

ダウンロードしたWinDbgのインストーラーを実行します。

まず、インストール場所を指定します。今回はデフォルトのままとして、Nextをクリックします。

次に、使用状況と診断データの収集の設定です。送信は行わないようにしたいので、Noを選択して、Nextをクリックします。

次に、ライセンスの同意です。内容を確認して、Acceptをクリックします。

次に、インストールする機能の選択です。カーネルの分析に必要なDebugging Tools for Windowsのみにチェックを入れて、Installをクリックします。

しばらくすると、インストールが完了します。インストールが完了後にスタートを開いて、WinDbgがあることを確認します。今回は、x64マシンなのでWinDbg(X64)をクリックします。

起動すると以下のようなウィンドウが表示されます。

クラッシュダンプを分析する前に、シンボルというのデバッグに使う情報のパスを指定します。
シンボルの詳細については、こちらのMicrosoftの公式ドキュメントをご確認ください。

[File] - [Symbol file path…]をクリックして、シンボルパスを指定します。シンボルパスはsrv*C:\Windows*https://msdl.microsoft.com/download/symbolsとしました。

それでは、ダンプファイルを開いて分析していきます。

[File] - [Open Crash Dump…]をクリックして、クラッシュダンプを指定します。

クラッシュダンプを指定すると、以下のようなウィンドウが開きます。クラッシュダンプの分析を行うためには、!analyze -vをクリックします。

!analyze -vをクリックすると、分析が始まります。NMI_HARDWARE_FAILURE (80) ということから、NMIによってカーネルパニックが発生したことが分かります。

Amazon Linux 2でやってみた

準備

続いて、Amazon Linux 2に対して診断割り込みAPIを実行して、カーネルパニックを発生させ、クラッシュダンプを分析していみたいと思います。

まず、カーネルパニックの発生時にクラッシュダンプを出力するように設定をします。

クラッシュダンプを出力するサービスであるkdumpと、クラッシュダンプを解析するために、crashkernel-debuginfoパッケージをインストールします。 kdumpkexec-toolsというモジュールに含まれています。 実行するコマンドは以下の通りです。

$ sudo yum install -y kexec-tools crash
$ sudo debuginfo-install -y kernel

実行時のログは以下の通りです。

sh-4.2$ sudo yum install -y kexec-tools crash
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                                        | 3.7 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package crash.x86_64 0:7.2.9-1.amzn2.0.1 will be installed
--> Processing Dependency: libsnappy.so.1()(64bit) for package: crash-7.2.9-1.amzn2.0.1.x86_64
--> Processing Dependency: liblzo2.so.2()(64bit) for package: crash-7.2.9-1.amzn2.0.1.x86_64
---> Package kexec-tools.x86_64 0:2.0.19-3.amzn2.0.1 will be installed
--> Processing Dependency: dracut-network >= 033-522 for package: kexec-tools-2.0.19-3.amzn2.0.1.x86_64
--> Running transaction check
---> Package dracut-network.x86_64 0:033-535.amzn2.1.3 will be installed
---> Package lzo.x86_64 0:2.06-8.amzn2.0.4 will be installed
---> Package snappy.x86_64 0:1.1.0-3.amzn2.0.2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================
 Package                   Arch              Version                         Repository             Size
=========================================================================================================
Installing:
 crash                     x86_64            7.2.9-1.amzn2.0.1               amzn2-core            2.6 M
 kexec-tools               x86_64            2.0.19-3.amzn2.0.1              amzn2-core            348 k
Installing for dependencies:
 dracut-network            x86_64            033-535.amzn2.1.3               amzn2-core            100 k
 lzo                       x86_64            2.06-8.amzn2.0.4                amzn2-core             60 k
 snappy                    x86_64            1.1.0-3.amzn2.0.2               amzn2-core             40 k

Transaction Summary
=========================================================================================================
Install  2 Packages (+3 Dependent packages)

Total download size: 3.1 M
Installed size: 8.2 M
Downloading packages:
(1/5): dracut-network-033-535.amzn2.1.3.x86_64.rpm                                | 100 kB  00:00:00
(2/5): kexec-tools-2.0.19-3.amzn2.0.1.x86_64.rpm                                  | 348 kB  00:00:00
(3/5): crash-7.2.9-1.amzn2.0.1.x86_64.rpm                                         | 2.6 MB  00:00:00
(4/5): lzo-2.06-8.amzn2.0.4.x86_64.rpm                                            |  60 kB  00:00:00
(5/5): snappy-1.1.0-3.amzn2.0.2.x86_64.rpm                                        |  40 kB  00:00:00
---------------------------------------------------------------------------------------------------------
Total                                                                    9.3 MB/s | 3.1 MB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : snappy-1.1.0-3.amzn2.0.2.x86_64                                                       1/5
  Installing : lzo-2.06-8.amzn2.0.4.x86_64                                                           2/5
  Installing : dracut-network-033-535.amzn2.1.3.x86_64                                               3/5
  Installing : kexec-tools-2.0.19-3.amzn2.0.1.x86_64                                                 4/5
  Installing : crash-7.2.9-1.amzn2.0.1.x86_64                                                        5/5
  Verifying  : lzo-2.06-8.amzn2.0.4.x86_64                                                           1/5
  Verifying  : kexec-tools-2.0.19-3.amzn2.0.1.x86_64                                                 2/5
  Verifying  : dracut-network-033-535.amzn2.1.3.x86_64                                               3/5
  Verifying  : snappy-1.1.0-3.amzn2.0.2.x86_64                                                       4/5
  Verifying  : crash-7.2.9-1.amzn2.0.1.x86_64                                                        5/5

Installed:
  crash.x86_64 0:7.2.9-1.amzn2.0.1                kexec-tools.x86_64 0:2.0.19-3.amzn2.0.1

Dependency Installed:
  dracut-network.x86_64 0:033-535.amzn2.1.3                 lzo.x86_64 0:2.06-8.amzn2.0.4
  snappy.x86_64 0:1.1.0-3.amzn2.0.2

Complete!
sh-4.2$
sh-4.2$ sudo debuginfo-install -y kernel
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
enabling amzn2extra-docker-debuginfo
enabling amzn2-core-debuginfo
amzn2-core-debuginfo                                                              | 2.6 kB  00:00:00
amzn2extra-docker-debuginfo                                                       | 2.6 kB  00:00:00
(1/2): amzn2extra-docker-debuginfo/2/x86_64/primary_db                            |  11 kB  00:00:00
(2/2): amzn2-core-debuginfo/2/x86_64/primary_db                                   | 1.8 MB  00:00:00
--> Running transaction check
---> Package kernel-debuginfo.x86_64 0:4.14.232-176.381.amzn2 will be installed
--> Processing Dependency: kernel-debuginfo-common-x86_64 = 4.14.232-176.381.amzn2 for package: kernel-debuginfo-4.14.232-176.381.amzn2.x86_64
---> Package yum-plugin-auto-update-debug-info.noarch 0:1.1.31-46.amzn2.0.1 will be installed
--> Running transaction check
---> Package kernel-debuginfo-common-x86_64.x86_64 0:4.14.232-176.381.amzn2 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================
 Package                              Arch      Version                    Repository               Size
=========================================================================================================
Installing:
 kernel-debuginfo                     x86_64    4.14.232-176.381.amzn2     amzn2-core-debuginfo    207 M
 yum-plugin-auto-update-debug-info    noarch    1.1.31-46.amzn2.0.1        amzn2-core               27 k
Installing for dependencies:
 kernel-debuginfo-common-x86_64       x86_64    4.14.232-176.381.amzn2     amzn2-core-debuginfo     31 M

Transaction Summary
=========================================================================================================
Install  2 Packages (+1 Dependent package)

Total download size: 238 M
Installed size: 974 M
Downloading packages:
(1/3): yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch.rpm           |  27 kB  00:00:00
(2/3): kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64.rpm           |  31 MB  00:00:00
(3/3): kernel-debuginfo-4.14.232-176.381.amzn2.x86_64.rpm                         | 207 MB  00:00:07
---------------------------------------------------------------------------------------------------------
Total                                                                     33 MB/s | 238 MB  00:00:07
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64                          1/3
  Installing : kernel-debuginfo-4.14.232-176.381.amzn2.x86_64                                        2/3
  Installing : yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch                          3/3
  Verifying  : kernel-debuginfo-common-x86_64-4.14.232-176.381.amzn2.x86_64                          1/3
  Verifying  : kernel-debuginfo-4.14.232-176.381.amzn2.x86_64                                        2/3
  Verifying  : yum-plugin-auto-update-debug-info-1.1.31-46.amzn2.0.1.noarch                          3/3

Installed:
  kernel-debuginfo.x86_64 0:4.14.232-176.381.amzn2
  yum-plugin-auto-update-debug-info.noarch 0:1.1.31-46.amzn2.0.1

Dependency Installed:
  kernel-debuginfo-common-x86_64.x86_64 0:4.14.232-176.381.amzn2

Complete!
sh-4.2$

次に、セカンドカーネル(ダンプ取得用のカーネル)用に予約するメモリーを設定するために、GRUBを設定します。

Amazon Linux 2のデフォルトの/etc/default/grubは以下のようになっており、セカンドカーネル用の予約メモリーの設定項目である、crashkernelがありません。そのため、crashkernelを設定して、メモリーの予約をします。

sh-4.2$ sudo cat /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
GRUB_TIMEOUT=0
GRUB_DISABLE_RECOVERY="true"sh-4.2$

今回は、crashkernel= 161Mにして、161MB予約します。kdumpのメモリー要件については、こちらのRed Hatの公式ドキュメントをご確認ください。

なお、crashkernel=autoとすることで、自動的に割り当てることが可能ですが、以下の通り必要なメモリーの条件があります。

 一部のシステムでは、ブートローダーの設定ファイルで crashkernel=auto パラメーターを使用するか、グラフィカル設定ユーティリティーで自動割り当ての設定を有効にすると、kdump 用のメモリーを自動的に割り当てることができます。ただし、この自動予約が機能するには、合計メモリーの特定量のメモリーを利用できる必要があります。この容量はシステムのアーキテクチャーによって異なります。

7.8. サポートしている kdump の設定とダンプ出力先- 7.8.2. メモリー自動予約の最小しきい値

例えば、AMD64 と Intel 64 (x86_64)の場合の必要メモリーは2GBですので、2GB以下のメモリーしか搭載していない場合は、crashkernel=autoとすることができません。

仮に、1GBのメモリーしか搭載していないEC2インスタンスで、crashkernel=autoとすると、kdumpサービスの起動に失敗します。
以下の通り、journalctl -xeで起動に失敗した原因を確認してみると、セカンドカーネル用のメモリーが予約されていないからだということが分かります。

(中略)
-- Unit kdump.service has begun starting up.
Jun 10 08:22:21 ip-10-0-1-70.ec2.internal kdumpctl[2419]: No memory reserved for crash kernel
Jun 10 08:22:21 ip-10-0-1-70.ec2.internal kdumpctl[2419]: Starting kdump: [FAILED]
Jun 10 08:22:21 ip-10-0-1-70.ec2.internal systemd[1]: kdump.service: main process exited, code=exited, status=1/FAILURE
Jun 10 08:22:21 ip-10-0-1-70.ec2.internal systemd[1]: Failed to start Crash recovery kernel arming.
-- Subject: Unit kdump.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit kdump.service has failed.
--
-- The result is failed.
(中略)

実際の/etc/default/grub設定変更時のログは以下の通りです。

sh-4.2$ sudo cp -a /etc/default/grub /etc/default/grub.`date +"%Y%m%d"`
sh-4.2$
sh-4.2$ sudo vi /etc/default/grub
sh-4.2$
sh-4.2$
sh-4.2$ diff -u /etc/default/grub.`date +"%Y%m%d"` /etc/default/grub
--- /etc/default/grub.20210610	2021-06-03 20:20:56.519197651 +0000
+++ /etc/default/grub	2021-06-10 07:42:00.162460009 +0000
@@ -1,3 +1,3 @@
-GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
+GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=161M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
 GRUB_TIMEOUT=0
-GRUB_DISABLE_RECOVERY="true"
\ No newline at end of file
+GRUB_DISABLE_RECOVERY="true"
sh-4.2$

続いて、以下、Red Hatの公式ドキュメントの通り、/etc/default/grub の手動による変更を反映するにために、grub2-mkconfigを実行してgrub.cfg ファイルを再構築します。

/etc/default/grub ファイルは、インストールプロセスで grub.cfg を作成するときに anaconda によって使用される grub2-mkconfig ツールにより使用され、システム障害の発生時に使用できます (たとえば、ブートローダーの設定を再作成する必要がある場合)。一般的に、他の手段がない場合を除き、grub2-mkconfig を手動で実行して grub.cfg ファイルを置き換えることは推奨されません。/etc/default/grub への手動による変更を反映するには、grub.cfg ファイルを再構築する必要があります。

第26章 GRUB 2 での作業 - 26.1. GRUB 2 について

実行時のログは以下の通りです。

sh-4.2$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.14.232-176.381.amzn2.x86_64
Found initrd image: /boot/initramfs-4.14.232-176.381.amzn2.x86_64.img
done
sh-4.2$

最後に、Intel および AMD プロセッサをベースとしたインスタンスの場合は、NMI を受信した際にクラッシュするようにカーネルを設定しておく必要があります。 そのため、カーネルパラメータを設定するファイルである/etc/sysctl.confを修正します。修正内容としては、kernel.unknown_nmi_panic=1をファイルの末尾に追加します。

修正時のログは以下の通りです。

sh-4.2$ sudo cp -a /etc/sysctl.conf /etc/sysctl.conf.`date +"%Y%m%d"`
sh-4.2$
sh-4.2$ sudo vi /etc/sysctl.conf
sh-4.2$
sh-4.2$ diff -u /etc/sysctl.conf.`date +"%Y%m%d"` /etc/sysctl.conf
--- /etc/sysctl.conf.20210610	2019-10-02 00:25:17.000000000 +0000
+++ /etc/sysctl.conf	2021-06-10 08:09:01.118690221 +0000
@@ -8,3 +8,5 @@
 # name in /etc/sysctl.d/ and put new settings there.
 #
 # For more information, see sysctl.conf(5) and sysctl.d(5).
+
+kernel.unknown_nmi_panic=1
sh-4.2$

一通りの設定変更が完了したので、カーネルの設定変更を反映させるために一度OSを再起動をします。

sh-4.2$ sudo systemctl reboot
Terminated
sh-4.2$

OS再起動後、カーネルが意図した設定で起動しているのかを確認します。

確認時のログは以下の通りです。追加したcrashkernel=161Mが読み込まれているので、意図した設定で起動していそうですね。

sh-4.2$ grep crashkernel /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.14.232-176.381.amzn2.x86_64 root=UUID=f6646b81-f2a6-46ca-9f3d-c746cf015379 ro crashkernel=161M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0

最後に、kdumpサービスが起動しているかを確認します。

確認時のログは以下の通りです。自動起動が有効になっているので、正常に起動していますね。

sh-4.2$ systemctl status kdump
● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2021-06-10 08:47:27 UTC; 2min 30s ago
  Process: 2213 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 2213 (code=exited, status=0/SUCCESS)
sh-4.2$
sh-4.2$ systemctl is-enabled kdump
enabled
sh-4.2$

診断割り込みAPIの実行

それでは、診断割り込みAPIを実行して、カーネルパニックを発生させてみます。

実行時のコマンドは以下の通り、Windows Serverの時と同じです。

> aws ec2 send-diagnostic-interrupt --instance-id i-0a7eb4d925f14862e
>

クラッシュダンプの分析

診断割り込みAPI実行後、OSにログインしてクラッシュダンプを確認してみます。

デフォルトのクラッシュダンプの出力先は、/var/crashです。/var/crash配下を確認してみると、以下の通り、クラッシュダンプが出力されていました。

sh-4.2$ ls -l /var/crash/127.0.0.1-2021-06-10-08\:55\:30/vmcore
-rw------- 1 root root 28561064 Jun 10 08:55 /var/crash/127.0.0.1-2021-06-10-08:55:30/vmcore

それでは、出力されたクラッシュダンプの分析をしてみます。

分析をする際には、以下の通りcrashを使用します。

$ crash /usr/lib/debug/lib/modules/<kernel>/vmlinux \ /var/crash/<timestamp>/vmcore

実際のログは以下の通りです。PANIC: "Kernel panic - not syncing: NMI: Not continuing"の通り、NMIによってカーネルパニックが発生したことが分かります。

sh-4.2$ cd /var/crash/127.0.0.1-2021-06-10-08\:55\:30
sh-4.2$ sudo crash /usr/lib/debug/lib/modules/4.14.232-176.381.amzn2.x86_64/vmlinux /var/crash/127.0.0.1-2021-06-10-08\:55\:30/vmcore

crash 7.2.9-1.amzn2.0.1
Copyright (C) 2002-2020  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/4.14.232-176.381.amzn2.x86_64/vmlinux
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Thu Jun 10 08:55:24 UTC 2021
      UPTIME: 00:05:51
LOAD AVERAGE: 0.00, 0.03, 0.02
       TASKS: 119
    NODENAME: ip-10-0-1-70.ec2.internal
     RELEASE: 4.14.232-176.381.amzn2.x86_64
     VERSION: #1 SMP Wed May 19 00:31:54 UTC 2021
     MACHINE: x86_64  (2500 Mhz)
      MEMORY: 1 GB
       PANIC: "Kernel panic - not syncing: NMI: Not continuing"
         PID: 0
     COMMAND: "swapper/0"
        TASK: ffffffff82013480  (1 of 2)  [THREAD_INFO: ffffffff82013480]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash>

crashの実行後は各種コマンドを入力することで、クラッシュダンプに含まれる様々な情報を確認できます。
例えば、logコマンドを使うと、以下の通り、カーネルメッセージバッファーを表示します。

crash> log
(中略)
[  506.403395] Uhhuh. NMI received for unknown reason 21 on CPU 0.
[  506.403396] Do you have a strange power saving mode enabled?
[  506.403396] Kernel panic - not syncing: NMI: Not continuing
[  506.403397] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.232-176.381.amzn2.x86_64 #1
[  506.403397] Hardware name: Amazon EC2 t3.micro/, BIOS 1.0 10/16/2017
[  506.403398] Call Trace:
[  506.403398]  <NMI>
[  506.403398]  dump_stack+0x66/0x81
[  506.403398]  panic+0xe4/0x247
[  506.403398]  ? printk+0x52/0x6e
[  506.403399]  nmi_panic+0x35/0x40
[  506.403399]  unknown_nmi_error+0x6f/0x80
[  506.403399]  do_nmi+0xfb/0x150
[  506.403399]  end_repeat_nmi+0x16/0x50
[  506.403400] RIP: 0010:native_safe_halt+0xe/0x10
[  506.403400] RSP: 0018:ffffffff82003eb0 EFLAGS: 00000246
[  506.403401] RAX: ffffffff8162d8f0 RBX: ffffffff821df760 RCX: 0000000000000000
[  506.403401] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[  506.403402] RBP: 0000000000000000 R08: 00000094a11d5bf3 R09: ffff88803bc31300
[  506.403402] R10: 0000000000000000 R11: 000001431a3c3afb R12: 0000000000000000
[  506.403402] R13: ffff88803e3f9780 R14: 0000000000000000 R15: 0000000000000000
[  506.403403]  ? __cpuidle_text_start+0x8/0x8
[  506.403403]  ? native_safe_halt+0xe/0x10
[  506.403403]  ? native_safe_halt+0xe/0x10
[  506.403403]  </NMI>
[  506.403404]  default_idle+0x1a/0x100
[  506.403404]  do_idle+0x174/0x1a0
[  506.403404]  cpu_startup_entry+0x6f/0x80
[  506.403404]  start_kernel+0x4c8/0x4eb
[  506.403405]  secondary_startup_64+0xa5/0xb0

psコマンドを使うと、以下の通り、プロセスの状態を表示します。

   PID    PPID  CPU       TASK        ST  %MEM     VSZ    RSS  COMM
>     0      0   0  ffffffff82013480  RU   0.0       0      0  [swapper/0]
>     0      0   1  ffff88803df3c000  RU   0.0       0      0  [swapper/1]
      1      0   1  ffff88803dec0000  IN   0.5   43524   5288  systemd
      2      0   0  ffff88803ded4000  IN   0.0       0      0  [kthreadd]
      4      2   0  ffff88803dedc000  ID   0.0       0      0  [kworker/0:0H]
      5      2   0  ffff88803df00000  ID   0.0       0      0  [kworker/u4:0]
      6      2   0  ffff88803df24000  ID   0.0       0      0  [mm_percpu_wq]
      7      2   0  ffff88803df28000  IN   0.0       0      0  [ksoftirqd/0]
(中略)
   3424   2254   1  ffff88803ac14000  IN   3.4  729228  34284  ssm-agent-worke
   3425   2254   0  ffff88803ad0c000  IN   3.4  729228  34284  ssm-agent-worke
   3426   2254   1  ffff88803acf8000  IN   3.4  729228  34284  ssm-agent-worke
   3624   2254   1  ffff88803accc000  IN   3.4  729228  34284  ssm-agent-worke
   3633   2254   0  ffff88803ad5c000  IN   3.4  729228  34284  ssm-agent-worke
   3650   2254   0  ffff88803b208000  IN   3.4  729228  34284  ssm-agent-worke
   3651   2254   0  ffff88803b384000  IN   3.4  729228  34284  ssm-agent-worke
   3653   2254   1  ffff88803ada8000  IN   3.4  729228  34284  ssm-agent-worke
   8024   3633   0  ffff888039aa8000  IN   2.5  723196  25032  ssm-session-wor
   8025   2254   1  ffff88803adf8000  IN   3.4  729228  34284  ssm-agent-worke
   8026   3633   1  ffff88803b24c000  IN   2.5  723196  25032  ssm-session-wor
   8027   3633   1  ffff88803ad44000  IN   2.5  723196  25032  ssm-session-wor
   8028   3633   0  ffff88803ac84000  IN   2.5  723196  25032  ssm-session-wor
   8029   3633   0  ffff888039118000  IN   2.5  723196  25032  ssm-session-wor
   8030   3633   0  ffff88803b354000  IN   2.5  723196  25032  ssm-session-wor
   8035   8027   0  ffff888039a30000  IN   0.3  124188   3288  sh
   8047   2254   0  ffff88803b484000  IN   3.4  729228  34284  ssm-agent-worke
   8051      2   1  ffff88803ae6c000  ID   0.0       0      0  [kworker/1:0]

他にも、 仮想メモリーの情報を表示したり、オープンファイルの表示をしたりすることもできます。詳細については、こちらのRed Hatの公式ドキュメントをご確認ください。

簡単にカーネルパニックを発生させることが可能だからこそ、取扱は要注意

事前に簡単な設定をすれば、簡単にAPI経由でカーネルパニックを発生させることができることを確認しました。

最初にも記載しましたが、通常時に意図的にカーネルパニックを発生させることは非常に稀です。
APIを実行するCLIは、「本当に実行して良いですか?」といった確認もされないので、仮に実行する場合はインスタンスIDが間違っていないかなど、よく注意して実行するようにお願いします。

また、カーネルパニックがインスタンスに悪影響を及ぼす可能性もあるため、実行前にAMIなどを作成して、何かあってもリストアできるような状態にしておくことをお勧めします。

このブログが誰かの助けになれば幸いです。

以上、東京オフィスの のんピ(@non____97)でした!