カーネルをパニックさせる「キル・スイッチ」を実行してみる（2）

想定外の操作で起こす「キル・スイッチ」

前回はSysRqの仕組みを使ってLinuxカーネルをパニックさせる方法を取り上げた。カーネルをパニックさせたものの、前回取り上げたのは、いわば正規の方法でカーネルをパニックさせる方法だ。今回は、それとは別の方法でカーネルをパニックさせる方法を紹介しよう。

カーネルパニックは正規の方法だけではなく、カーネルが提供している機能を本来想定されていない使い方をすることでも引き起こすことができる。ただし、その手の穴のようなものは、カーネルのバージョンが上がると塞がれる、つまり、操作できないように変更されることも多く、いつまでも使えるわけではない。

キル・スイッチ「パターン2」を実行

では早速、前回とは異なるパターンのキル・スイッチを実行してみよう。以下が作業手順だ。

cat /dev/port

うまくいくと、システムがフリーズして操作できなくなる。

• 実行直前の様子

場合によってはマシンがサスペンドする可能性がある。その場合、レジュームすると次のようなコンソールが表示されるかもしれない。

• レジュームしたあとのコンソール

その場合はもう1度同じコマンドを実行してみる。うまくいくとシステムがフリーズすると思う。

以前はほかにもカーネルをパニックさせる簡単な方法があったのだが、最近ではそれを可能にする穴はもう塞がれていてカーネルパニックが起きなくなっている。

FreeBSDでも実行可能

キル・スイッチはLinuxカーネルに特有の機能ではなく、ほかのUNIX系オペレーティングシステムにも存在している。FreeBSDなら、次のようにsysctlの値を変更するとカーネルがパニックする。

sysctl debug.kdb.panic=1

実行すると、次のようになる。

• FreeBSDでキル・スイッチ実行直前の状態

• 実行してカーネルパニックを発動

この機能はカーネルのデバッグを行ったり、パニック発生時の設定がちゃんと機能しているか確かめたりする時に使う。

頻繁に実行しないほうがよい

前回も書いたが、あらかじめ用意された正規の方法であれ、想定されていないところからのカーネルパニックの発生であれ、システムの終了や再起動を想定した処理ではないので、そう頻繁に実行するものではない。機能としてこういうものがあることを確認するために試してみるのはよいと思うが、ファイルシステムに不整合が発生するといった問題も起こりかねないので、毎日使うようなことはしないほうがよいと思う。