サンキングが必要な理由

カーネル モード ドライバーは、ユーザー モード アプリケーションから渡されるすべての I/O バッファーのサイズを検証する必要があります。 32 ビット アプリケーションがポインター精度データ型を含むバッファーを 64 ビット ドライバーに渡し、サンキングが行われなかった場合、ドライバーはバッファーが実際よりも大きいと想定します。 これは、ポインターの精度が 32 ビットの Microsoft Windows では 32 ビット、64 ビット Windows では 64 ビットであるためです。 たとえば、次のようなプロジェクト構造定義を考えてみます。

typedef struct _DRIVER_DATA
{
    HANDLE           Event;
    UNICODE_STRING   ObjectName;
} DRIVER_DATA;

32 ビット Windows では、DRIVER_DATA 構造体のサイズは 12 バイトです。 次の表は、DRIVER_DATA構造体の Event メンバーと ObjectName メンバーのサイズを示しています。

64 ビット Windows では、DRIVER_DATA 構造体のサイズは 24 バイトです。 (構造体のパディングの 4 バイトが必要です。 バッファー メンバーは、8 バイトの境界に配置できます)。

64 ビット ドライバーが 24 バイトと予想し、12 バイトの DRIVER_DATA を受け取った場合、サイズの検証は失敗します。 これを回避するには、ドライバーは、DRIVER_DATA 構造体が 32 ビット アプリケーションによって送信されたかどうかを検出する必要があり、送信された場合は、検証を実行する前に適切にサンクする必要があります。

たとえば、上記の DRIVER_DATA 構造体のサンクされたバージョンは、次のように定義できます。

typedef struct _DRIVER_DATA32
{
    VOID *POINTER_32   Event;
    UNICODE_STRING32   ObjectName;
} DRIVER_DATA32;

固定精度データ型のみが含まれるため、この新しい構造体は 32 ビット Windows と 64 ビット Windows で同じサイズになります。