クラウドネイティブコンテナセキュリティプラクティス

概要：

クラウド ネイティブは、一連の技術システムと方法論です。クラウド ネイティブは、クラウドとネイティブという 2 つの単語で構成されています。クラウドとは、アプリケーションが従来のデータセンターではなくクラウドに配置されることを意味します。ネイティブとは、アプリケーションが最初からクラウド環境を念頭に置いて設計され、クラウド向けに設計され、クラウド上で高品質で実行され、クラウド プラットフォームの弾力性と分散の利点を最大限に活用して発揮することを意味します。

[[317287]]

代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。

クラウド ネイティブの詳細については、この記事の最後にあるリンク 1 を参照してください。

クラウドネイティブ セキュリティ テクノロジー サンドボックス (セキュリティ ビュー)

著者は、上図に示すように、「クラウド ネイティブ セキュリティ」を技術的なサンドボックスに抽象化します。下から見ていくと、最下層はハードウェア セキュリティ (信頼できる環境) からホスト セキュリティまでの範囲になります。コンテナ オーケストレーション テクノロジー (Kubernetes など) は、自動展開、スケーリング、アプリケーション管理を担当するクラウド上の「オペレーティング システム」と考えてください。その上に、マイクロサービス、サービスメッシュ、コンテナ技術（Docker など）、コンテナイメージ（ウェアハウス）などで構成されています。これらは互いに補完し合い、クラウド ネイティブ セキュリティはこれらのテクノロジーに基づいて構築されます。

コンテナのセキュリティをさらに抽象化すると、ビルド時のセキュリティ (Build)、デプロイメント時のセキュリティ (Deployment)、ランタイム時のセキュリティ (Runtime) と考えることができます。

Meituan では、コンテナ イメージ分析プラットフォームによってイメージのセキュリティが確保されています。ルールエンジンの形でコンテナイメージを操作・監視します。デフォルトのルールは、イメージ内の Docker ファイル、疑わしいファイル、機密権限、機密ポート、基本ソフトウェアの脆弱性、ビジネス ソフトウェアの脆弱性、CIS および NIST のベスト プラクティスのチェックをサポートし、リスクの傾向を提供します。同時に、建設中の部分的なセキュリティも確保します。

クラウドネイティブ アーキテクチャでは、コンテナはコンテナ オーケストレーション テクノロジー (Kubernetes など) によってデプロイされます。デプロイメント セキュリティは、前述のコンテナ オーケストレーション セキュリティとも重複します。

運用上のセキュリティ制御は HIDS の責任です (記事の最後にあるリンク 2 の「分散 HIDS クラスター アーキテクチャ設計」を参照してください)。この記事で扱う範囲も運用セキュリティに属し、主にコンテナエスケープモデル上に構築されたリスクを扱います（この記事では、特に断りのない限り、コンテナはDockerを指します）。

安全実装ガイドラインは 3 つの段階に分かれています。

1. 攻撃前: 攻撃対象領域を整理し、外部に公開されている攻撃対象領域を減らします (この記事で取り上げるシナリオのキーワードは「分離」です)。

2. 攻撃時: 攻撃の成功率を下げる (この記事で取り上げるシナリオのキーワード: 強化)。

3. 攻撃後: 攻撃が成功した後に攻撃者が取得できる貴重な情報とデータを削減し、バックドアを残すことを困難にします。

近年、データセンターのインフラストラクチャは、従来の仮想化（KVM + Qemu アーキテクチャなど）からコンテナ化（Kubernetes + Docker アーキテクチャ）へと徐々に移行しています。しかし、エスケープは、これら 2 つのアーキテクチャの下で企業が直面する必要がある最も深刻なセキュリティ問題です。これはコンテナリスクにおける最も代表的なセキュリティ問題でもあります。著者はコンテナ エスケープを出発点として、コンテナのリスクを軽減するために、攻撃者の観点 (コンテナ エスケープ) から防御者の観点 (コンテナ エスケープの緩和) までコンテナ セキュリティの実践について説明します。

コンテナのリスク

コンテナーは、アプリケーションのコード、構成、依存関係を 1 つのオブジェクトにパッケージ化する標準的な方法を提供します。コンテナは、Linux Namespace と Linux Cgroups という 2 つの主要テクノロジーに基づいて構築されています。

名前空間は、ほぼ分離されたユーザー空間を作成し、アプリケーションにシステム リソース (ファイル システム、ネットワーク スタック、プロセス、ユーザー ID) を提供します。 cgroups は、CPU、メモリ、デバイス、ネットワークなどのハードウェア リソースに制限を適用します。

コンテナと VM の違いは、VM はハードウェア システムをエミュレートし、各 VM は独立した環境で OS を実行できることです。ハイパーバイザーは CPU、メモリ、ストレージ、ネットワーク リソースなどをエミュレートし、このハードウェアは複数の VM で何度も共有できます。

コンテナ攻撃対象領域

コンテナには、Linux カーネル、名前空間/Cgroups/Aufs、Seccomp-bpf、ライブラリ、言語 VM、ユーザー コード、コンテナ (Docker) エンジンの 7 つの攻撃対象領域があります。

著者はコンテナ エスケープをリスク モデルとして使用し、3 つの攻撃対象領域を抽出します。

1. Linuxカーネルの脆弱性

2. 容器自体

3. 安全でない展開（構成）

1. Linuxカーネルの脆弱性

コンテナ カーネルはホスト カーネルと共有され、コンテナ内のリソースをホストから分離するために Namespace と Cgroup が使用されます。したがって、Linux カーネルの脆弱性によりコンテナが逃げてしまう可能性があります。

カーネル権限昇格とコンテナエスケープ - 一般的な Linux カーネル権限昇格方法論

情報収集

エクスプロイトの作成に役立つすべての情報を収集します。たとえば、カーネルのバージョン: 攻撃しているカーネルのバージョンを特定する必要があります。このカーネル バージョンではどの強化構成が有効になっていますか?シェルコードを書くときにどのカーネル関数が呼び出されるかを知る必要もありますか?このとき、関数アドレスを取得するには、カーネル シンボル テーブルを照会する必要があります。アプリケーションの作成に役立つアドレス情報や構造情報などもカーネルから取得できます。

トリガーフェーズ

関連する脆弱性をトリガーし、RIP を制御し、カーネル コード パスをハイジャックして、簡単に言えば、カーネル内で任意のコードを実行する機能を取得します。

シェルコードのレイアウト

カーネルエクスプロイトコードを書くときは、シェルコードを格納するためのメモリを見つける必要があります。このメモリは少なくとも次の 2 つの条件を満たす必要があります。

まず、脆弱性をトリガーする場合、ハイジャックしたいコード パスが、シェルコードが格納されているメモリに到達できることを保証する必要があります。

2 番目: このメモリ ブロックは実行可能です。つまり、シェルコードが保存されているメモリには実行権限があります。

実行フェーズ

最初: 現在のユーザーよりも高い権限を取得します。一般的に、シェルコードを実行するには、Linux で最高の権限であるルート権限を直接取得します。

2番目: カーネルの安定性を確保します。権限を昇格する必要があるからといって、カーネルをクラッシュさせるのではなく、元のカーネル コード パス、カーネル構造、カーネル データなどを破壊しなければなりません。この場合、ルート権限を取得してもあまり意味がありません。

つまり、エクスプロイトの作成に役立つ情報を収集し、脆弱性をトリガーして特権コードを実行し、権限を昇格する効果を実現します。

コンテナ脱出モデル

コンテナ エスケープとカーネル権限昇格にはわずかな違いがあり、どちらも名前空間の制限を突破する必要があります。エクスプロイト プロセスの task_struct に高権限の名前空間を割り当てます。この部分の詳細な技術的詳細はこの記事の範囲外です。著者は、コンテナ エスケープに関する別の技術記事を執筆し、関連する技術的な詳細を詳しく説明する予定です。

クラシックダーティカウ

著者は、Dirty CoW の脆弱性を使用して、Linux の脆弱性によって引き起こされるコンテナ エスケープについて説明します。抜け穴は古いですが、あまりにも古典的です。これを書いていて、私はこう尋ねずにはいられません。何年も経った今、国内外の大手メーカーの Dirty Cow 脆弱性を持つ既存のマシンの修復率はどのくらいなのでしょうか?

Linux カーネルのメモリ サブシステムがプライベートな読み取り専用メモリ マッピングのコピー オン ライト (CoW) メカニズムを処理する方法に競合状態が見つかりました。権限のないローカル ユーザーがこの脆弱性を悪用して、本来は読み取り専用であるメモリ マッピングへの書き込みアクセス権を取得し、システム上の権限を増大させる可能性があります。この脆弱性は Dirty CoW と呼ばれます。

Dirty CoW 脆弱性エスケープ方法は上記の方法とは異なり、Overwrite vDSO テクノロジを採用しています。

vDSO (Virtual Dynamic Shared Object) は、カーネルとユーザー空間間の頻繁な切り替えを減らし、システム コールの効率を向上させるためにカーネルによって設計されたメカニズムです。これは、カーネル空間と、ルート権限で実行されているプロセスを含むすべてのプロセスの仮想メモリの両方にマップされます。このステップ (vDSO の検索) は、コンテキスト切り替えを必要としないシステム コールを呼び出すことによって高速化できます。 vDSO は、ユーザー空間では R/X、カーネル空間では R/W としてマップされます。これにより、カーネル空間で変更してから、ユーザー空間で実行できるようになります。また、コンテナはホストカーネルを共有するため、このテクノロジを直接使用してコンテナから脱出することができます。

使用手順は次のとおりです。

1. vDSO アドレスを取得します。 glibc の新しいバージョンでは、getauxval() 関数を直接呼び出して取得できます。

2. vDSO アドレスを通じて clock_gettime() 関数のアドレスを見つけ、ハイジャックされる可能性があるかどうかを確認します。

3. リスニングソケットを作成します。

4. 脆弱性を引き起こす Dirty CoW は、カーネル メモリ管理システムにおける CoW の実装によって発生する脆弱性です。条件付き競合と適切なタイミングを利用することで、CoW 機能を使用してファイルの読み取り専用状態を書き込み状態にマッピングできます。子プロセスは書き込みが成功したかどうかを継続的にチェックします。親プロセスは 2 つのスレッドを作成し、ptrace_thread スレッドは vDSO にシェルコードを書き込みます。

madvise_thread スレッドは vDSO マッピング スペースを解放し、ptrace_thread スレッド CoW プロセスに影響を与え、条件付き競合を生成します。条件がトリガーされると、書き込みは成功します。

5. シェルコードを実行し、ホストからルートシェルに戻るのを待ちます。成功した場合は、vDSO の元のデータを復元します。

2. 容器自体

Docker アーキテクチャ図を簡単に見てみましょう。

Docker アーキテクチャ図 (インターネットからの画像です。著作権侵害がある場合は削除するようご連絡ください)

Docker 自体は、docker (docker クライアント) と dockerd (docker デーモン) で構成されています。しかし、Docker 1.11 以降では、Docker は docker dameon を介して単純に起動されるのではなく、containerd、runc などを含む多くのコンポーネントが統合されています。

Docker クライアントは Docker のクライアント プログラムであり、ユーザー リクエストを dockerd に送信するために使用されます。 Dockerd は実際には containerd API インターフェースを呼び出します。 Containerd は、dockerd と runc 間の中間通信コンポーネントであり、主にコンテナの操作、イメージ管理などを担当します。Containerd は、dockerd 用の gRPC インターフェースを提供し、基盤となる構造の変更をシールドし、元のインターフェースの下位互換性を確保します。下方向には、containerd-shim が runc と組み合わされて、コンテナが作成および実行されます。さらに関連性の高いコンテンツについては、記事の最後にあるリンク 4、5、6 を参照してください。これらを明確に理解した後、私たち自身のセキュリティ経験を組み合わせて、これらのコンポーネント間の通信方法と依存関係から抜け出す可能性のある脆弱性を見つけることができます。

以下では、Docker の runc コンポーネントによって引き起こされる脆弱性を使用して、コンテナ自体の脆弱性によって引き起こされるエスケープについて説明します。

CVE-2019-5736: runc – コンテナブレイクアウトの脆弱性

runc のファイル システム記述子の使用には脆弱性があり、特権コンテナが悪用され、コンテナがホスト ファイル システムから脱出してアクセスする可能性があります。攻撃者は、悪意のあるイメージを使用したり、実行中のコンテナの構成を変更したりして、この脆弱性を悪用することもできます。

攻撃方法 1: (このアプローチでは特権コンテナが必要です) 実行中のコンテナが侵入され、システム ファイルが悪意を持って改ざんされます ==> ホストは docker exec コマンドを実行して、コンテナ内に新しいプロセスを作成します ==> ホストの runc は悪意のあるプログラムに置き換えられます ==> ホストは docker run/exec コマンドの実行時に悪意のあるプログラムの実行をトリガーします。

攻撃方法 2: (この方法では特権コンテナは必要ありません) docker run コマンドが悪意を持って変更されたイメージを起動 ==> ホストの runc が悪意のあるプログラムに置き換えられる ==> ホストが docker run/exec コマンドを実行して悪意のあるプログラムの実行をトリガーします。

runc がコンテナ内で新しいプログラムを実行すると、攻撃者はそれを騙して悪意のあるプログラムを実行させる可能性があります。 runc バイナリへのポイントバックは、コンテナー内のターゲット バイナリをカスタム バイナリに置き換えることによって実現されます。

たとえば、ターゲットバイナリが /bin/bash の場合、これをインタープリターを指定する実行可能スクリプトに置き換えることができます: #!/proc/self/exe;したがって、コンテナ内で /bin/bash が実行されると、/proc/self/exe のターゲットが実行され、ターゲットは runc バイナリに向けられます。

その後、攻撃者は /proc/self/exe ターゲットに書き込み、ホスト上の runc バイナリを上書きしようとします。ここでは、O_PATHフラグを使用して/proc/self/exeファイル記述子を開き、次に/proc/self/fd/を介してO_WRONLYフラグを使用する必要があります。バイナリ ファイルを再度開き、別のプロセスを使用して書き込みを続けます。書き込みが成功すると、runc は終了します。

3. 安全でない展開（構成）

実際には、さまざまなビジネスがそれぞれのビジネスニーズに基づいて独自の構成セットを持っており、この構成セットが効果的に管理および監査されていないため、内部環境が複雑かつ多様化し、目に見えない形で多くのリスクポイントが追加されているという状況によく遭遇します。たとえば、最も一般的なものは次のとおりです。

1. 特権コンテナまたはルート権限で実行中のコンテナ。

2. 無理な Capability 構成（権限が大きすぎる Capability）。

特権コンテナでは、コンテナ内でコマンドを実行するだけで、ホストマシンにバックドアが簡単に残される可能性があります。

特権コンテナ問題は Meituan 内で効果的に解決されました。

業界ではすでにこの側面に関するベスト プラクティスが提供されており、ホスト構成、Dockerd 構成、コンテナー イメージ、Dockerfile、コンテナー ランタイムなどの側面からセキュリティが確保されています。詳細については、記事末尾のリンク 10 を参照してください。同時に、Docker はこれを自動化ツールに正式に実装しました (記事末尾のリンク 11 を参照)。

安全対策

前のセクションで説明したコンテナ エスケープ問題を解決するために、次の説明では分離 (セキュア コンテナ) と強化 (セキュア カーネル) に焦点を当てます。

1. 安全なコンテナ

セキュア コンテナの技術的な本質は、実際には分離です。 gVisor と Kata Container はより代表的な実装方法です。もちろん、学術コミュニティでは現在、Intel SGX をベースにしたセキュア コンテナーを検討しています。

簡単に言うと、gVisor はユーザー モードとカーネル モードの間のレイヤーを抽象化し、それをユーザー モード カーネルに少し似た API にカプセル化して分離を実現します。 Kata Container は、従来の VM に似た軽量の仮想マシン分離を使用しますが、現在の Kubernetes と Docker のアーキテクチャとのシームレスな統合を実現します。次に、gVisor と Kata Container の類似点と相違点を見てみましょう。

ケース1: gVisor

gVisor は、Golang またはサンドボックス テクノロジで記述されたユーザー モード カーネルであり、主にほとんどのシステム コールを実装します。これはアプリケーションとカーネルの間で実行され、それらの間の分離を実現します。 gVisor は、Google Cloud Platform 上の App Engine、Cloud Functions、Cloud ML で使用されます。 gVisor が実行されると、複数のサンドボックスが構成され、それらが一緒に 1 つ以上のコンテナーをカバーします。 gVisor は、アプリケーションからホスト カーネルへのすべてのシステム コールをインターセプトし、ユーザー空間で Sentry を使用して処理することで、仮想化ハードウェア変換を経ずにゲスト カーネルの役割を果たします。これは、vmm とゲスト カーネルの組み合わせ、または seccomp の拡張バージョンと見なすことができます。

gVisor アーキテクチャ図 (インターネットからの画像です。著作権侵害がある場合はご連絡ください)

事例2: カタコンテナ

Kata Container の Container Runtime は、仮想マシンと同様に、ハードウェア仮想化を使用して実装されるハイパーバイザーを使用します。したがって、この Kata Container のような各 Pod は、完全な Linux カーネルを備えた軽量の仮想マシンです。そのため、Kata Container は VM のような強力な分離を提供しますが、最適化とパフォーマンス設計により、コンテナーに匹敵する俊敏性を備えています。

Kata コンテナ アーキテクチャ図 (インターネットからの画像です。著作権侵害がある場合は削除を依頼してください)

Kata Container には、新しいコンテナーを起動および構成するための kata-runtime がホスト上に存在します。 Kata VM 内のすべてのコンテナーには、ホスト上に対応する Kata Shim が存在します。 Kata Shim は、クライアント (docker や kubectl など) から API リクエストを受信し、VSock 経由で Kata VM 内のプロキシにリクエストを転送します。 Kata コンテナはさらに最適化され、VM の起動時間が短縮されます。 QEMU の軽量バージョンである NEMU を使用すると、デバイスとパッケージの約 80% が削除されます。 VM テンプレートは、実行中の Kata VM インスタンスのクローンを作成し、それを新しく作成された他の Kata VM と共有します。これにより、起動時間が短縮され、ゲスト VM のメモリ消費量が削減されます。ホットプラグ機能を使用すると、VM を最小限のリソース (CPU、メモリ、virtio ブロックなど) で起動し、後で要求されたときに追加のリソースを追加できます。

gVisor VS Kata コンテナ

Kata Container よりも軽量な設計なので、gVisor を好みます。しかし、gVisor のパフォーマンスは依然として克服できないハードルです。両者の長所と短所を考慮すると、現時点では Kata Container は企業内での内部使用に適しています。全体として、さまざまな企業が社内インフラストラクチャで直面している課題を解決するために、安全なコンテナ テクノロジーにはまだまだ多くの研究が必要です。

2. セキュリティカーネル

ご存知のとおり、さまざまな Android メーカーが独自の Android バージョンを維持しており、Android カーネル コードは Linux カーネル アップストリームから取得されるため、アップストリーム カーネルに脆弱性が発生すると、セキュリティ パッチが Google にプッシュされ、その後 Google から主要メーカーにプッシュされ、最終的にエンド ユーザーにプッシュされます。 Android エコシステムの断片化と非常に長いパッチ サイクルにより、このプロセス中、エンド ユーザーのセキュリティは常に「ウィンドウ期間」内にあります。同様の問題を抱えている Linux に再び注目してみましょう。

1. カーネルが直面する問題

脆弱性のライフサイクル

カーネルパッチ

セキュリティ上の脆弱性が公開されると、通常は脆弱性の発見者によって Redhat、OpenSuse、Debian などのコミュニティ フィードバックを通じて報告されるか、アップストリームの関連サブシステムのメンテナーに直接送信されます。企業内には複数の異なるカーネル バージョンとカーネルのカスタマイズが存在します。異なるバージョンでは、関連するパッチがアップストリーム コードからバックポートされ、関連するホット パッチが生成されます。カスタマイズされたカーネルでは、パッチの二次開発を実施し、その後、実稼働環境カーネルまたはホットフィックスカーネルをアップグレードする必要もあります。修復サイクルが長すぎるだけでなく、修復プロセス中に担当者間のコミュニケーションを促進するためのコストも発生し、脆弱性のリスク期間が長引くことになります。危険な期間中の脆弱性に対する保護はありません。

カーネルバージョンの断片化

カーネル バージョンの断片化は、一定規模の企業では避けられない問題です。テクノロジーは日々変化し、繰り返し進化し続けるため、インフラストラクチャ上のテクノロジー スタックにはカーネル機能の新しいバージョンのサポートが必要となり、時間の経過とともにカーネル バージョンの断片化が起こります。断片化が存在するため、セキュリティ パッチの適用が大きな課題となっています。パッチ自体も、カーネルのさまざまなバージョンを含めて特別に調整し、テストおよび検証する必要があります。断片化によりメンテナンスコストが非常に高くなります。最も重要なのは、メンテナンス作業が大量になるため、パッチのテストのタイムラインが必然的に長くなることです。つまり、攻撃者にさらされる危険な期間が長くなり、攻撃を受ける可能性が大幅に高まります。

カーネルバージョンのカスタマイズ

同様に、カスタマイズされたカーネルの問題は、さまざまな企業のさまざまなインフラストラクチャと要件によって発生します。カスタマイズされたカーネルの場合、アップストリームカーネルからのパッチを単純にマージすることはできません。パッチは、カスタマイズされたカーネルに適合するようにローカライズする必要があります。これにより危険な期間がさらに長引いた。

解決

セキュリティ機能を使用して、特定の種類の脆弱性や特定の種類のエクスプロイトを防御および検出します。たとえば、SLAB_FREELIST_HARDENED は、二重解放の脆弱性をリアルタイムで検出し、フリーリストの上書きを防止しますが、パフォーマンスの低下はわずか 0.07% です (upstrem カーネル ソース コード、コミット ID: 2482ddec を参照)。

すべてのセキュリティ機能が完成すると、脆弱性が報告される前やパッチが適時に本番環境にプッシュされる前に、脆弱性の詳細を心配することなく、脆弱性を防御できるようになります。もちろん、セキュリティ パッチを適用する必要があります。ここでは主に、セキュリティ パッチが最終的に実稼働環境に適用される「ウィンドウ期間」中に脆弱性やエクスプロイトに対する防御がないという問題を解決します。同時に、0day に対する一定の検出および防御機能も備えています。

実装戦略

1. Linux メインライン バージョンに統合されたセキュリティ機能については、会社のカーネルがこの機能をサポートしている場合は、構成を有効にすることを選択し、有効にする前と有効にした後にカーネルのパフォーマンス テストを実行し、セキュリティ機能の原理と業界データを分析し、実際の攻撃ケースを提供 (それを証明するために独自のエクスプロイトを作成) し、レポートの結論をカーネル チームにフィードバックします。その後、カーネル チームが評価を実施し、セキュリティ チームとカーネル チームの両方の意見に基づいて最終評価が実装されます。

2. Linux メインライン バージョンに統合されているが Redhat には統合されていないセキュリティ機能は、Linux カーネル メインライン バージョンから移植できます。このようにして、コードの品質が保証されます。同時に、コミュニティはパフォーマンス テストも実施し、それを会社のカーネルにマージして再テストします。

3. Linux カーネルのメインライン バージョンにマージされていないものは、Grsecurity/PaX から移植されています。 Grsecurity/PaX の多くのセキュリティ機能の中から、コード変更が少なく、優先移植のメリットが大きいものを評価して選択します。たとえば、コード変更が少ないカーネル コードは、特定の種類の脆弱性を効果的に解決できます。たとえば、Dirty cow の完全な修正には 1 ～ 2 年かかる場合がありますが、特定のセキュリティ機能を追加することで、修正されていない場合でも防御を提供できます。

カーネル追記

最後に、私が理想的な状況だと考えるものをお話ししたいと思います。もちろん、実際の状況に基づいて「現地の状況に適応」し、さまざまな段階でさまざまなトレードオフと選択を行う必要があります。

私たちはカーネル チームをコミュニティとみなし、コードを彼らに提出します。これは、Linux カーネル コミュニティが RFC (Request for Comment) やパッチ レビューなどを持ち、それが何の異議もなく会社のカーネルに統合されるのと同じです。

まず、コードが少ない実用的なセキュリティ機能を選択し、移植、実装して実装します。コードの量が少ないということは、カーネル コードへの変更が少なくなり、問題が発生する可能性が低くなり、安定性が高くなり、パフォーマンスの低下が少なくなることを意味します。

1 年間にいくつかのセキュリティ機能を完了する必要はなく、1 ～ 2 個で十分です。カーネル状態の強化のためには、慎重に、慎重に、そしてまた慎重にならなければなりません。例えば、外資系企業G社のデータセンターのカーネルは、リリース前にパフォーマンスと安定性のテストを行うのに約6〜7か月かかります。

特定のセキュリティ機能を強化した後、0day または Nday を使用して防御効果を検証し、カーネルに基づいて実行されるビジネスが安定し、パフォーマンスの低下が許容範囲内または制御可能であることを確認する必要があります。各安全機能には技術的なレビューが必要です。コードの品質を保証するために、高スループット、高同時実行性、低レイテンシの実際のサーバーで小規模なグレースケール テストを実施します。異議がなければ、カーネル チームにプッシュします。

最後に、セキュリティ機能コードを Linux カーネル コミュニティに直接送信することで、コードに欠陥がある場合にコミュニティと協力して問題を解決し、Linux カーネルのメインライン コードにマージして、間接的に実装を促進することができます。