Linuxカーネル月報について
Linuxリーディングフィールド
Linuxカーネルの月次レポートの列は、その月のLinuxカーネルコミュニティの最も重要な最前線の開発トレンドの要約であり、読者がLinuxカーネルの最先端の開発トレンドを追跡しやすくします。
スペースに限りがあるため、最新のテクノロジーの概要のみを説明します。技術的な詳細については、フォローアップ記事をお楽しみください。読者は、リーディングコードフィールドコミュニティへの貢献も歓迎します。
この月次報告書の主な寄稿者：
Zhang Jian、Liao Weixiong、Chenwei、Xia
以前のリンク：
Linuxリーディングフィールド-Linuxカーネル月報（2020年6月）
Linuxリーディングフィールド-Linuxカーネル月報（2020年7月）
Linuxリーディングフィールド-Linuxカーネル月報（2020年8月）
Linuxリーディングフィールド-Linuxカーネル月報（2020年9月）
阅码场征稿Linux阅码场征集Linux工程师一线研发心得；工程师、高校学生老师、科研院所研研究人员对Linux某一技术要点深入分析的稿件。您的文章将获得近十万一线Linux工程师的广泛受众。投稿要求：原创且从未在任何媒体、博客、公众号发表过的文章。高屋建瓴、深刻全面地论述一个技术点或者面。投稿请微信联系小月：linuxer2016录取的稿件，我们也会奉上微薄的稿酬聊表寸心，稿费标准为300-500元/篇。
1つは、アーキテクチャ関連
1.1 ARM / arm64 set_fs
补丁集1：ARM：set_fsの呼び出し元と実装を削除します
パッチセット2：arm64：set_fs（）とその仲間を削除します
カーネルコードにfsが含まれている場合、どう思いますか？ファイルシステム？ただし、図は壊れています。今日お話しするfsは、実際にはx86のfsレジスタです[1]。カーネルの0.1バージョンでは、ユーザースペース（ `set_fs（USER_DS）`）とカーネルスペース（ `set_fs（KERNEL_DS）`）のアドレス範囲を設定するためにset_fsが導入されました。元々、set_fsはx86 fsレジスタのみを設定し、他のアーキテクチャもset_fsという名前に従いました。名前だけが混乱していても大丈夫です。問題は、set_fsが保護しているように見えることです。同じです。
攻撃ポイントです。カーネルからユーザースペースに戻るときに、対応する制限 `set_fs（USER_DS）`が設定されていない場合、ユーザースペースには無制限のメモリスペースの機能があります。2010年（CVE-2010-4258）と2016年にも同様の報告がありました。
set_fs [2]に基づく強化は方法のように見えましたが、カーネルシステム呼び出しのパフォーマンスに影響を与えるため、拒否されました。したがって、オプションは1つだけです。set_fsを削除します。えーと、3年前、これは3年前のコミュニティの議論の結果でした。今年、Christoph Hellwigは当初の提案を続けました。現在、カーネルのコアコード部分は完了しており、残りのアーキテクチャを変更する必要があります。今月、ARMおよびARM64アーキテクチャパッチがレビューのために提出されます。
ARM64の場合、クリーンアップコードに加えて、カーネルとユーザースペースの切り替えを含むコードを処理する必要があります。これには、主にSDEI、PAN、UAOの3つの部分が含まれます。ARMの場合、set_fsコードの削除に加えて、oabiのいくつかのシステム呼び出しを処理する必要があります。
参考资料
[1]https://lwn.net/Articles/722267/
[2]https://lwn.net/Articles/721305/1.2 KASan for ARM
Kernel Address SANitizer（KASAN）は、主に範囲外および解放後の使用をチェックする動的メモリエラー検出器です。現在、X86、ARM64、RISC-V、PowerPCおよびその他のアーキテクチャがサポートされています。
Linus Walleijは、今月、KASan for Armの第14版パッチを送信しました。これは、ARMアーキテクチャによるKASanのサポートです。先月のパッチと比較して、LinusはQualcommAPQ8060プラットフォームでのクラッシュを修復しました。 FlorianとArdによって報告された問題を修正できます。
ARM64のKASanは、ハードウェアタグに基づくメモリエラー検出を追加しています。この一連のパッチは、メモリタグ付け拡張機能（MTE）の機能をKASanに適用し、メモリが割り当てられるたびにランダムタグを生成し、MTEがメモリにアクセスするたびに自動的にチェックします。一致しない場合、タグフォールトが生成され、KASanがエラーを報告します。
（パッチ名：kasan：arm64のハードウェアタグベースモードを追加）
1.3ARM64のkexecでIMA測定ログを繰り越す
カーネルの各アーキテクチャの実装には共通点と特徴の両方があり、後発者は以前のアーキテクチャの実装をより一般的に変更することを検討することがよくあります。カーネル月次レポートで紹介したRISC-VNUMAの作業は、ARM64に基づいています。今日のパッチセットも同様です。
IMA（Integrity Measurement Architecture）は、コア整合性の2つの主要コンポーネントの1つです。IMAは、ファイルが実行または開かれたときに、ファイルの整合性をチェックできます。kexecの場合（kexecは現在のカーネルからの新しいカーネルの開始をサポートします）：IMAは、カーネル、initramfs、およびコマンドラインをチェックできます。Lakshmiの4つのパッチは、現在ARM64でサポートされていないこの機能を補完するものです。
1.4上記のパッチに加えて、10月には注目に値するパッチがたくさんあります。例えば
TDPMMUを紹介します
目的は、TBレベルのメモリ仮想マシンのホットマイグレーションパフォーマンスを向上させることです。TDPの意味は次のとおりです。2次元ページング。現在、TDP MMUは、必要なホットマイグレーションパフォーマンスを提供するために、416個のvCPUを備えたGoogleの12TiB m2-ultramem-416VMで使用されています。
この作業の動機は、非常に大規模な仮想マシンでページ障害を並行して処理することです。VMに数百のvCPUとTBのメモリがある場合、KVMのMMUロックは極端な競合に悩まされ、ゲストOSでのページ障害処理のソフトロックアップまたは大幅な遅延が発生します。
非対称AArch32システムのサポートを追加
目的は、arm64CPUの一部のみがaarch32EL0動作環境をサポートしている場合に、ユーザースペースでaarch32アプリケーションを使用することです。備考：arm64 CPUは、aarch64とaarch32の2つの動作環境（EE：実行環境）を持つことができます。
PKS：保護キースーパーバイザー（PKS）サポートの追加
これはPKU（User Space Memory Protection Keys）と同様のカーネル作業であり、予想される使用シナリオは信頼できるキーとPMEMです。
2.コアカーネル関連
2.1スリープ可能なトレースポイント
現在のトレーサーはページ障害を処理できないため、ユーザーモードデータにアクセスできませんが、これが必要になる場合があります。
この一連のパッチは、トレーサーがトレースポイントフレームワークでページ障害を処理できるようにするフレームワークを実装しており、さまざまなトレーサーが将来対応する変更を加えます。
2.2コアスケジューリングv8
コアスケジューリングは、信頼できるプロセスを共有リソースcpusで同時に実行できるようにする機能です。主な目的は、SMT機能を無効にすることなくコアレベルのサイドチャネル攻撃を排除することです。
デフォルトでは、この機能は現在のスケジューリング動作を変更しません。ユーザーは、同じコアで同時に実行できるタスクを決定する必要があります。たとえば、プロセスAが実行されている場合、同じコアのハイパースレッドはアイドル状態であるか、プロセスAによって信頼されているプロセスのみを実行できます。
2.3 KFENCE v5：低サンプリングメモリエラー検出ツール
KFENCEの主な特徴は、パフォーマンスの犠牲を最小限に抑えて、回線上のさまざまなメモリエラーをサンプリングすることです。KASANと比較すると、KFENCEの精度はそれほど高くありませんが、KFENCEはパフォーマンスにほとんど影響を与えず、多数の実稼働環境に展開できます。メモリのバグも検出できます。
この一連のパッチは、armアーキテクチャとx86アーキテクチャの両方にKFENCEサポートを追加します。
3、ファイルシステムとブロックレイヤー
3.1ブロックリクエストフィルタリングとブロックデバイススナップショットモジュール
*パッチ：https：//lwn.net/Articles/834867/
* veeamsnap：
https://github.com/veeam/veeamsnap/
パッチの作成者は、Linuxバックアップソリューションを提供する企業であるveeamの出身です。長い間、ブロックデバイスバックアップサービスはカーネルツリーモジュール（veeamsnap）の形式で提供されてきました。この提出は、そのメイン汎用モジュールをメインブランチにマージする試みです。
このパッチは、blk-filterとblk-snapの2つの機能を実装しています。
blk-filterは、ブロックデバイスのBIO要求のインターセプトを実装し、要求処理キューにまったく影響を与えることなく、BIO要求を非常に早期にインターセプトします。ストレージメディア全体をインターセプトするだけでなく、パーティション単位で特定のブロックデバイスのインターセプトもサポートします。フィルタリング機能の動的な有効化と無効化をサポートする機能もあります。ブロックデバイスがロードされると、BIO要求のフィルタリングを自動的に開始できます。ブロックデバイスが削除されると、フィルターも自動的に削除されます。
blk-snapは、スナップショットおよびブロック変更追跡機能を実装します。それがblk-filterに依存していることは間違いありません。デバイスマッパーを使用せずに、ブロックデバイスのバックアップコピーを作成するように設計されています。スナップショットは一時的なものであり、バックアッププロセスが完了すると破棄されます。変更されたブロック追跡により、増分および差分バックアップコピーが可能になります。
3.2 btrfsは、4Kサブページの読み取りと書き込みのサポートを追加しました
*パッチ：https：//lwn.net/Articles/834872/
このパッチは主に、64Kページサイズのシステムが4Kセクターサイズのbtrfsをマウントできるようにし、この状態で通常の読み取りと書き込みをサポートすることを目的としています。
64 Kのページサイズは、一部の小さなデータの下で内部スペースの浪費を引き起こします。操作の粒度が小さい場合、スペースの浪費を大幅に軽減できます。したがって、4Kサブページの操作をサポートする必要があります。テスト後、作成者は十分に安定しており、reflinkなどのサブページサイズの純粋なメタデータ操作を実行できると考えています。作成者は、圧縮および非圧縮の場合に読み取りデータサブページを検証し、メタデータサブページの読み取りと書き込みを検証し、非圧縮の場合にページ全体の書き込みも検証しました。
このパッチには、実際にやるべきことがたくさんあり、多くの課題があります。たとえば、サブページに書き込まれるデータ（非メタデータ）は実装されません。たとえば、サブページデータのライトバックはiomapをサポートします。
第四に、仮想化
4.1KVMで保護されたメモリ拡張
==背景と関連する問題==
ホストへの不正アクセスによって仮想マシンのメモリにアクセスするのを防ぐことができる多くのハードウェア機能（MKTME、SEVなど）があります。このパッチセットは、同じホスト側の読み取り専用攻撃の一部を軽減できる純粋なソフトウェア機能を提案します。
==このパッチセットは何を軽減しましたか？==
-ホストカーネルが「誤って」仮想マシンデータにアクセスする（推測を考慮）
-ホストカーネルにより、仮想マシンデータにアクセスします（write（fd＆guest_data_ptr、len））
-仮想マシンデータにアクセスするためのホストユーザースペース（改ざんされたQEMUなど）
-改ざんされたQEMUデバイスシミュレータを介して仮想マシンの特権を高めます
==このパッチセットは何を軽減しませんか？==
-ホストのカーネルが完全に改ざんされています。カーネルはページを再度マップします
-ハードウェアベースの攻撃
RFCパッチセットの第2版は、ほとんどのフィードバックに対応しています。
しかし、それでも再起動とKEXECを解決するための良い解決策は見つかりませんでした。これらの操作では、すべてのメモリの保護をキャンセルする必要があります。これは、この機能の目的と矛盾します。
再起動（またはKEXEC）に必要なコンテンツを保護しない前に、ほとんどのメモリのクリーンアップには時間がかかり、エラーが発生しやすくなります。たぶん、これらの操作はサポートされていないことを宣言する必要がありますか？
==シーケンスの概要==
ハードウェア機能を使用して仮想マシンのデータを暗号化し、正しい仮想マシンのみがそれを復号化できるようにして、仮想マシンのデータを保護します。これの副作用は、直接カーネルマッピングとユーザースペースマッピング（QEMUなどで使用される）が役に立たなくなることです。
ただし、これはいくつかの非常に有用な情報を示しています。通常の仮想マシン操作では、カーネルマッピングとユーザースペースマッピングが実際には必要ない場合があります。
パッチセットでは、暗号化を使用せず、単にメモリのマップを解除します。暗号テキストへのアクセスを許可する場合と比較して、その利点の1つは、誤ったアクセスによって例外が発生し、暗号化されたデータなどのガベージデータを単に返すのではなくキャッチされることです。
4.2 KVM：ダーティリングインターフェース
パッチは10月に2回更新され、どちらもv15を最新のKVMブランチにリベースします。この作業は、Lei Cao <[email protected]>とPaoloBonziniによって行われたKVMダーティリングインターフェイス作業の続きです。
この新しいダーティリングインターフェイスは、仮想マシンがダーティページを再利用するためのもう1つの方法です。多くの点で、主に既存のダーティロギングインターフェイスとは異なります。
データ形式：ダーティデータがビットマップ形式ではなくリング形式になっているため、ダーティデータログの同期に使用されるビットは、仮想マシンのメモリのサイズではなく、データの速度に依存します。さらに、新しいダーティリングは各vCPU専用ですが、ダーティビットマップはすべてのvCPUで共有され、ダーティビットマップはVMごとになります。
データコピー：ダーティページの同期でデータをコピーする必要がなくなりました。逆に、ダーティリングは、ページ共有（vcpu_fdのmmap経由）を通じてユーザースペースとカーネルスペースで共有されます。
インターフェイス：収集されたダーティページを再び保護モードにリセットする場合、新しいダーティリングは、元のKVM_GET_DIRTY_LOG、KVM_CLEAR_DIRTY_LOGインターフェイスの代わりに、新しいKVM_RESET_DIRTY_RINGSioctlインターフェイスを使用します。ダーティビットを収集するには、ダーティリング内のデータを読み取るだけでよく、ioctlインターフェイスを呼び出す必要はありません。
（終わり）
更多精彩，尽在"Linux阅码场"，扫描下方二维码关注