☰

シャーシ侵入検知に基づくアクションの実行

tag-icon • tag-icon linux security gnu bios
シャーシ侵入検知に基づくアクションの実行

一方：

  • GNU/Linux を実行するサーバーと

  • そのサーバーのシャーシ侵入検知スイッチ

  • 侵入検知状態を追跡してそれをfreeipmi読み取ることができるサーバーのBIOS（またはUEFI）

[サーバー]ボックスが開いている場合、そのサーバーに操作を実行させるにはどうすればよいですか（例：Eメールの送信または単に終了）。

ユーザー森security.stackexchangeについては、「」をポーリングすることをお勧めします。/dev/nvramストレージシャーシの侵入回数の値を取得するには、約0.5秒ごとに解析してください。。 （ライセンス：CC-SA 3.0.) これは非効率的なようです。確かにより良い方法がありますか？

答え1

以下は、ファームウェア.intel.com/blog/accessing-uefi-variables-linuxで引用されました。

投稿者：mfleming、日付：2014年1月3日

このドキュメントでは、UEFI ランタイム変数にアクセスするために Linux が提供する 2 つの方法と、長所と短所といくつかの履歴を要約します。

The Legacy efivars Interface

Matt Domschが作成したUEFI変数と対話するための元のインタフェースは、一般的なLinuxカーネルsysfsファイルシステムを介してエクスポートされます。インターフェイスはUEFI以前のEFI時代にItaniumコンピュータ用に作成されたため、いくつかの歴史的な荷物が付属しています。

従来のefivarsインターフェイスは、sysfsマウントポイントに基づいて「firmware / efi / vars /」パスを介してエクスポートされます。 sysfsが/sysにインストールされていると仮定すると、efivarsファイルを含むディレクトリは次のようになります。

    /sys/firmware/efi/vars/

new_var特別なファイルとを除いて、上記のマウントdel_varポイントの各エントリはそれ自体のディレクトリです。つまり、実行時にアクセスできる各UEFI変数のディレクトリです。

    Boot0000-12345678-abcd-abcd-abcd-123456789abc/
    Boot0001-12345678-abcd-abcd-abcd-123456789abc/
    BootCurrent-12345678-abcd-abcd-abcd-123456789abc/
    BootOrder-12345678-abcd-abcd-abcd-123456789abc/
    BootSetup-12345678-abcd-abcd-abcd-123456789abc/
    del_var
    Lang-12345678-abcd-abcd-abcd-123456789abc/
    LangCodes-12345678-abcd-abcd-abcd-123456789abc/
    new_var
    Setup-12345678-abcd-abcd-abcd-123456789abc/

UEFI変数のディレクトリ名は、変数名と変数のグローバルユニーク識別子（GUID）で構成されています。この例：

    Boot0000-12345678-abcd-abcd-abcd-123456789abc/

最初のUEFIブート変数のディレクトリにすることができます。各ディレクトリには次のファイルがあります。

    attributes
    data
    guid
    raw_var
    size

これらのファイルのほとんどの内容は人間が読み取ることができ、同じ名前のUEFI変数パラメータに対応します。バイナリデータを含む「raw_var」ファイルは例外です。たとえば、上記のブートエントリの「プロパティ」ファイルには、次のASCII文字列などの内容が含まれています。

    EFI_VARIABLE_NON_VOLATILE
    EFI_VARIABLE_BOOTSERVICE_ACCESS
    EFI_VARIABLE_RUNTIME_ACCESS

この変数は不揮発性であり、UEFIブートサービスExitBootServices（）呼び出しの前後にアクセスできることを示します。人間が読めるファイルに書き込むことはできません。唯一の目的は、ユーザーに変数の詳細を提供することです。

raw_varユーザー空間でカーネルに使用されるUEFI可変バイナリデータ構造への読み取り/書き込みを可能にし、レガシーインターフェイスの重要な部分です。既存の変数に対するすべての変更は、「struct efi_variable」オブジェクトを渡すことによってこのファイルを介して行われます。

struct efi_variable {

    efi_char16_t VariableName[1024/sizeof(efi_char16_t)];
    efi_guid_t VendorGuid;
    unsigned long DataSize;
    __u8 Data[1024];
    efi_status_t Status;
    __u32 Attributes;

} __attribute__((packed));

名前が示すように、最上位ディレクトリの特殊ファイル「new_var」および「del_var」は、UEFI変数を作成および削除するために使用されます。これらのファイルは、人間が読めるテキストを使用しません。代わりに、 "struct efi_variable"オブジェクトはカーネルとユーザースペースの間を通過し、渡されて新しい変数を作成するか、既存のUEFI変数を削除します。

Linuxカーネルでefivarsインターフェースを維持する主な理由は、このインターフェースのみを使用するいくつかのツールがまだあるからです。 efibootmgrツールはすべてのLinuxディストリビューションで利用可能で、UEFIシステムで起動順序を制御するために使用されますが、まだこのインターフェイスを使用します。レガシーツールインターフェース。

しかし、既存のefivarsインターフェースには、時間が経つにつれて迷惑になり始めたいくつかの制限がありました。

最も明白な欠点は、読み書き可能なUEFI変数データのサイズに上限があることです。カーネルデータ構造が設計されているため、1024バイト以上の変数データを読み書きすることは不可能であり、一部のユースケースではこの制限が問題になります。

さらに、efivarsインターフェイスには、「new_var」、「del_var」、および「raw_var」特殊ファイルを介してUEFI変数の重要な「struct efi_variable」データ構造の読み取り/書き込みコピーのみを処理するため、本質的にUEFI変数を操作するツールが必要です。 「struct efi_variable」オブジェクトをビルドして「del_var」ファイルに書き込まないと、UEFI変数を削除できません。

efivarfsファイルシステム

既存のefivarインターフェースの制限を克服するために、Matthew GarrettとJeremy Kerrは新しいLinuxファイルシステムを作成しました。この新しいファイルシステムの名前は「efivarfs」で、Linuxカーネルv3.10の一部です。

他のすべてのLinuxファイルシステムと同様に、efivarfsはファイルにアクセスするためにどこかにマウントする必要があり、次のコマンドを実行して実行できます。

    mount -t efivarfs none /sys/firmware/efi/efivars

efivarfs にはディレクトリは含まれていませんが、UEFI 変数名と GUID という名前のファイルが含まれています。

    Boot0000-12345678-abcd-abcd-abcd-123456789abc
    Boot0001-12345678-abcd-abcd-abcd-123456789abc
    BootCurrent-12345678-abcd-abcd-abcd-123456789abc
    BootOrder-12345678-abcd-abcd-abcd-123456789abc
    BootSetup-12345678-abcd-abcd-abcd-123456789abc

各ファイルにはバイナリデータ（レガシーインターフェイスのなどnew_var）del_varが含まれていますが、efivarfsのデータ構造はUEFI変数属性ビットマスクに対して4バイトしか含まれず、残りはUEFI変数データです。

struct new_efi_variable
{

   u32 attributes;
   u8 data[0];

};

他のすべての情報（変数名、GUID、サイズなど）は、読み書きするファイル名から推定されます。これにより、ファイルを作成または削除してUEFI変数を作成または削除することが簡単になりました。

たとえば、次のシェルコマンドは新しい変数を生成します。

    printf "\x07\x00\x00\x00\x00" > myvar-12345678-1234-1234-1234-123456789abc

myvarGUID と12345678-1234-1234-1234-123456789abcbitmask プロパティに設定されたビットと EFI_VARIABLE_NON_VOLATILE1 バイトのデータ（最後）を使用して名前が付けられます。EFI_VARIABLE_BOOTSERVICE_ACCESSEFI_VARIABLE_RUNTIME_ACCESS\x00

ファイルサイズを取得する一般的な方法を使用して、変数サイズと4バイトのプロパティデータを見つけることができます。たとえば、次のシェルコマンドを実行します。

    du -b myvar-12345678-1234-1234-1234-12345678abc

"5" - 変数属性ビットマスク4バイトとデータ1バイトを印刷します。

変数を削除するには、efivarfsファイルシステムから削除するだけです。

    rm myvar-12345678-1234-1234-1234-12345678abc

明らかに、これはコマンドラインとシェルスクリプトからUEFI変数にアクセスするためのより直感的なインターフェースです。とりわけ、既存のインターフェイスとは異なり、UEFI変数に読み書きできるデータ量に制限はありません。

もちろん、efivarfsで使用されるデータ構造は、従来のインターフェースよりもはるかに単純ですが、それでもバイナリデータとして読み書きすることができ、従来のインターフェースで提供されている人が読めるファイルよりも精神的な処理が必要です。

この記事では、実行時にUEFI変数にアクセスするためにLinuxが提供する2つのソリューションについて簡単に説明しました。新しいefivarfsファイルシステムは、シェルスクリプト（またはコマンドラインでも）でUEFI変数にアクセスするのに便利なインターフェースを提供しますが、一部のツールはまだ古いインターフェースを使用し、場合によっては人間が読めるファイルを使用します。純粋なバイナリインターフェイスよりも良いかもしれません。エピバルフの。

Matt Flemingは、Intelオープンソーステクノロジセンターのソフトウェアエンジニアであり、Linuxカーネル（U）EFIマネージャです。

関連情報