diff options
Diffstat (limited to 'Documentation/translations')
53 files changed, 2654 insertions, 348 deletions
diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index 6ee713988531..baa344f4523a 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -10,8 +10,8 @@ Questo documento descrive come usare lo spazio dei nomi dei simboli per strutturare quello che viene esportato internamente al kernel grazie alle macro della famiglia EXPORT_SYMBOL(). -1. Introduzione -=============== +Introduzione +============ Lo spazio dei nomi dei simboli è stato introdotto come mezzo per strutturare l'API esposta internamente al kernel. Permette ai manutentori di un @@ -24,15 +24,15 @@ devono prima importare detto spazio. Altrimenti il kernel, a seconda della configurazione, potrebbe rifiutare di caricare il modulo o avvisare l'utente di un'importazione mancante. -2. Come definire uno spazio dei nomi dei simboli -================================================ +Come definire uno spazio dei nomi dei simboli +============================================= I simboli possono essere esportati in spazi dei nomi usando diversi meccanismi. Tutti questi meccanismi cambiano il modo in cui EXPORT_SYMBOL e simili vengono guidati verso la creazione di voci in ksymtab. -2.1 Usare le macro EXPORT_SYMBOL -================================ +Usare le macro EXPORT_SYMBOL +---------------------------- In aggiunta alle macro EXPORT_SYMBOL() e EXPORT_SYMBOL_GPL(), che permettono di esportare simboli del kernel nella rispettiva tabella, ci sono @@ -53,8 +53,8 @@ di base. Il programma ``modpost`` e il codice in kernel/module/main.c usano lo spazio dei nomi, rispettivamente, durante la compilazione e durante il caricamento di un modulo. -2.2 Usare il simbolo di preprocessore DEFAULT_SYMBOL_NAMESPACE -============================================================== +Usare il simbolo di preprocessore DEFAULT_SYMBOL_NAMESPACE +---------------------------------------------------------- Definire lo spazio dei nomi per tutti i simboli di un sottosistema può essere logorante e di difficile manutenzione. Perciò è stato fornito un simbolo @@ -83,8 +83,8 @@ direttamente nei file da compilare. L'esempio precedente diventerebbe:: Questo va messo prima di un qualsiasi uso di EXPORT_SYMBOL. -3. Come usare i simboli esportati attraverso uno spazio dei nomi -================================================================ +Come usare i simboli esportati attraverso uno spazio dei nomi +============================================================= Per usare i simboli esportati da uno spazio dei nomi, i moduli del kernel devono esplicitamente importare il relativo spazio dei nomi; altrimenti @@ -108,12 +108,10 @@ modinfo:: Si consiglia di posizionare la dichiarazione MODULE_IMPORT_NS() vicino -ai metadati del modulo come MODULE_AUTHOR() o MODULE_LICENSE(). Fate -riferimento alla sezione 5. per creare automaticamente le importazioni -mancanti. +ai metadati del modulo come MODULE_AUTHOR() o MODULE_LICENSE(). -4. Caricare moduli che usano simboli provenienti da spazi dei nomi -================================================================== +Caricare moduli che usano simboli provenienti da spazi dei nomi +=============================================================== Quando un modulo viene caricato (per esempio usando ``insmod``), il kernel verificherà la disponibilità di ogni simbolo usato e se lo spazio dei nomi @@ -125,8 +123,8 @@ un'opzione di configurazione: impostare MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y caricherà i moduli comunque ma emetterà un avviso. -5. Creare automaticamente la dichiarazione MODULE_IMPORT_NS -=========================================================== +Creare automaticamente la dichiarazione MODULE_IMPORT_NS +======================================================== La mancanza di un'importazione può essere individuata facilmente al momento della compilazione. Infatti, modpost emetterà un avviso se il modulo usa diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index c7d05e2fff15..77db13c4022b 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -32,13 +32,13 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. ====================== ================= ======================================== Programma Versione minima Comando per verificare la versione ====================== ================= ======================================== -GNU C 5.1 gcc --version +GNU C 8.1 gcc --version Clang/LLVM (optional) 13.0.0 clang --version Rust (opzionale) 1.78.0 rustc --version bindgen (opzionale) 0.65.1 bindgen --version GNU make 4.0 make --version bash 4.2 bash --version -binutils 2.25 ld -v +binutils 2.30 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -118,7 +118,7 @@ Questo richiede bash 4.2 o successivo. Binutils -------- -Per generare il kernel è necessario avere Binutils 2.25 o superiore. +Per generare il kernel è necessario avere Binutils 2.30 o superiore. pkg-config ---------- diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst index 692be4af9c9b..5bf1b4adebc1 100644 --- a/Documentation/translations/it_IT/process/submit-checklist.rst +++ b/Documentation/translations/it_IT/process/submit-checklist.rst @@ -58,9 +58,10 @@ Fornite documentazione 4) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``. 5) Tutte le nuove interfacce verso lo spazio utente sono documentate in - ``Documentation/ABI/``. Leggete ``Documentation/ABI/README`` per maggiori - informazioni. Le patch che modificano le interfacce utente dovrebbero - essere inviate in copia anche a linux-api@vger.kernel.org. + ``Documentation/ABI/``. Leggete Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) per maggiori informazioni. + Le patch che modificano le interfacce utente dovrebbero essere inviate + in copia anche a linux-api@vger.kernel.org. 6) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate ``Documentation/userspace-api/ioctl/ioctl-number.rst``. diff --git a/Documentation/translations/ja_JP/SubmitChecklist b/Documentation/translations/ja_JP/SubmitChecklist deleted file mode 100644 index 1759c6b452d6..000000000000 --- a/Documentation/translations/ja_JP/SubmitChecklist +++ /dev/null @@ -1,105 +0,0 @@ -NOTE: -This is a version of Documentation/process/submit-checklist.rst into Japanese. -This document is maintained by Takenori Nagano <t-nagano@ah.jp.nec.com> -and the JF Project team <http://www.linux.or.jp/JF/>. -If you find any difference between this document and the original file -or a problem with the translation, -please contact the maintainer of this file or JF project. - -Please also note that the purpose of this file is to be easier to read -for non English (read: Japanese) speakers and is not intended as a -fork. So if you have any comments or updates of this file, please try -to update the original English file first. - -Last Updated: 2008/07/14 -================================== -これは、 -linux-2.6.26/Documentation/process/submit-checklist.rst の和訳です。 - -翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > -翻訳日： 2008/07/14 -翻訳者： Takenori Nagano <t-nagano at ah dot jp dot nec dot com> -校正者： Masanori Kobayashi さん <zap03216 at nifty dot ne dot jp> -================================== - - -Linux カーネルパッチ投稿者向けチェックリスト -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -本書では、パッチをより素早く取り込んでもらいたい開発者が実践すべき基本的な事柄 -をいくつか紹介します。ここにある全ての事柄は、Documentation/process/submitting-patches.rst -などのLinuxカーネルパッチ投稿に際しての心得を補足するものです。 - - 1: 妥当なCONFIGオプションや変更されたCONFIGオプション、つまり =y, =m, =n - 全てで正しくビルドできることを確認してください。その際、gcc及びリンカが - warningやerrorを出していないことも確認してください。 - - 2: allnoconfig, allmodconfig オプションを用いて正しくビルドできることを - 確認してください。 - - 3: 手許のクロスコンパイルツールやOSDLのPLMのようなものを用いて、複数の - アーキテクチャにおいても正しくビルドできることを確認してください。 - - 4: 64bit長の'unsigned long'を使用しているppc64は、クロスコンパイルでの - チェックに適当なアーキテクチャです。 - - 5: カーネルコーディングスタイルに準拠しているかどうか確認してください(!) - - 6: CONFIGオプションの追加・変更をした場合には、CONFIGメニューが壊れていない - ことを確認してください。 - - 7: 新しくKconfigのオプションを追加する際には、必ずそのhelpも記述してください。 - - 8: 適切なKconfigの依存関係を考えながら慎重にチェックしてください。 - ただし、この作業はマシンを使ったテストできちんと行うのがとても困難です。 - うまくやるには、自分の頭で考えることです。 - - 9: sparseを利用してちゃんとしたコードチェックをしてください。 - -10: 'make checkstack' を利用し、問題が発見されたら修正してください。 - 'make checkstack' は明示的に問題を示しませんが、どれか - １つの関数が512バイトより大きいスタックを使っていれば、修正すべき候補と - なります。 - -11: グローバルなkernel API を説明する kernel-doc をソースの中に含めてください。 - ( staticな関数においては必須ではありませんが、含めてもらっても結構です ) - そして、'make htmldocs' もしくは 'make mandocs' を利用して追記した - ドキュメントのチェックを行い、問題が見つかった場合には修正を行ってください。 - -12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, - CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, - CONFIG_DEBUG_ATOMIC_SLEEP これら全てを同時に有効にして動作確認を - 行ってください。 - -13: CONFIG_SMP, CONFIG_PREEMPT を有効にした場合と無効にした場合の両方で - ビルドした上、動作確認を行ってください。 - -14: lockdepの機能を全て有効にした上で、全てのコードパスを評価してください。 - -15: /proc に新しいエントリを追加した場合には、Documentation/ 配下に - 必ずドキュメントを追加してください。 - -16: 新しいブートパラメータを追加した場合には、 - 必ずDocumentation/admin-guide/kernel-parameters.rst に説明を追加してください。 - -17: 新しくmoduleにパラメータを追加した場合には、MODULE_PARM_DESC()を - 利用して必ずその説明を記述してください。 - -18: 新しいuserspaceインタフェースを作成した場合には、Documentation/ABI/ に - Documentation/ABI/README を参考にして必ずドキュメントを追加してください。 - -19: 少なくともslabアロケーションとpageアロケーションに失敗した場合の - 挙動について、fault-injectionを利用して確認してください。 - Documentation/fault-injection/ を参照してください。 - - 追加したコードがかなりの量であったならば、サブシステム特有の - fault-injectionを追加したほうが良いかもしれません。 - -20: 新たに追加したコードは、`gcc -W'でコンパイルしてください。 - このオプションは大量の不要なメッセージを出力しますが、 - "warning: comparison between signed and unsigned" のようなメッセージは、 - バグを見つけるのに役に立ちます。 - -21: 投稿したパッチが -mm パッチセットにマージされた後、全ての既存のパッチや - VM, VFS およびその他のサブシステムに関する様々な変更と、現時点でも共存 - できることを確認するテストを行ってください。 diff --git a/Documentation/translations/ja_JP/disclaimer-ja_JP.rst b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst new file mode 100644 index 000000000000..46a026000407 --- /dev/null +++ b/Documentation/translations/ja_JP/disclaimer-ja_JP.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _translations_ja_JP_disclaimer: + +========================== +免責条項 (Disclaimer) 抄訳 +========================== + +.. note:: 【訳註】 + この文書は、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` + の一部を翻訳したものです。全文は英語版を参照願います。 + +Documentation/translations/ja_JP/ 以下のファイルは、対応する +Documentation/ 以下のファイル (原文) の日本語訳です。 +翻訳と原文との違いや翻訳上の問題を見つけたら、 +MAINTAINERS に記載の維持管理者に知らせてください。 +翻訳が原文の更新に追いついていない場合は、それを日本語版に反映するパッチの +投稿も歓迎です。 + +なお、この翻訳の目的は非英語 (ここでは日本語) 話者への便宜提供であり、 +フォークを意図したものではない事を念頭においてください。したがって、 +このファイルの内容に対するコメントや更新すべきことがあれば、先に原文の +更新を検討してください。 diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 0b476b429e3b..4159b417bfdd 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -11,7 +11,9 @@ .. toctree:: :maxdepth: 1 + disclaimer-ja_JP process/howto + process/submit-checklist .. raw:: latex diff --git a/Documentation/translations/ja_JP/process/howto.rst b/Documentation/translations/ja_JP/process/howto.rst index d9ba40588e46..5e307f90982c 100644 --- a/Documentation/translations/ja_JP/process/howto.rst +++ b/Documentation/translations/ja_JP/process/howto.rst @@ -1,35 +1,18 @@ -.. raw:: latex +.. SPDX-License-Identifier: GPL-2.0 - \kerneldocCJKoff - -NOTE: -This is a version of Documentation/process/howto.rst translated into Japanese. -This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> -If you find any difference between this document and the original file or -a problem with the translation, please contact the maintainer of this file. - -Please also note that the purpose of this file is to be easier to -read for non English (read: Japanese) speakers and is not intended as -a fork. So if you have any comments or updates for this file, please -try to update the original English file first. - ----------------------------------- - -.. raw:: latex - - \kerneldocCJKon - -この文書は、 -Documentation/process/howto.rst -の和訳です。 - -翻訳者： Tsugikazu Shibata <tshibata@ab.jp.nec.com> - ----------------------------------- +.. Originally contributed by Tsugikazu Shibata Linux カーネル開発のやり方 ========================== +.. note:: 【訳註】 + この文書は、 + Documentation/process/howto.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した ドキュメントです。ここには Linux カーネル開発者になるための方法とLinux カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。 diff --git a/Documentation/translations/ja_JP/process/submit-checklist.rst b/Documentation/translations/ja_JP/process/submit-checklist.rst new file mode 100644 index 000000000000..fb3b9e3bd8ee --- /dev/null +++ b/Documentation/translations/ja_JP/process/submit-checklist.rst @@ -0,0 +1,163 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. Translated by Akira Yokosawa <akiyks@gmail.com> + +.. An old translation of this document of a different origin was at + Documentation/translations/ja_JP/SubmitChecklist, which can be found + in the pre-v6.14 tree if you are interested. + Please note that this translation is independent of the previous one. + +====================================== +Linux カーネルパッチ投稿チェックリスト +====================================== + +.. note:: 【訳註】 + この文書は、 + Documentation/process/submit-checklist.rst + の翻訳です。 + 免責条項については、 + :ref:`免責条項の抄訳 <translations_ja_JP_disclaimer>` および、 + :ref:`Disclaimer (英語版) <translations_disclaimer>` を参照してください。 + +以下は、カーネルパッチの投稿時に、そのスムーズな受け入れのために心がける +べき基本的な事項です。 + +これは、 Documentation/process/submitting-patches.rst およびその他の +Linux カーネルパッチ投稿に関する文書を踏まえ、それを補足するものです。 + +.. note:: 【訳註】 + 可能な項目については、パッチもしくはパッチ内の更新を暗黙の主語として、 + その望ましい状態を表す文体とします。その他、原義を損なわない範囲で + 係り結びを調整するなど、簡潔で把握しやすい箇条書きを目指します。 + + +コードのレビュー +================ + +1) 利用する機能について、その機能を定義・宣言しているファイルを + ``#include`` している。 + 他のヘッダーファイル経由での取り込みに依存しない。 + +2) Documentation/process/coding-style.rst に詳述されている一般的なスタイル + についてチェック済み。 + +3) メモリバリアー (例, ``barrier()``, ``rmb()``, ``wmb()``) について、 + そのすべてに、作用と目的、及び必要理由についての説明がソースコード内の + コメントとして記述されている。 + + +Kconfig 変更のレビュー +====================== + +1) 新規の、もしくは変更された ``CONFIG`` オプションについて、それが関係する + コンフィグメニューへの悪影響がない。また、 + Documentation/kbuild/kconfig-language.rst の + "Menu attibutes: default value" に記載の例外条件を満たす場合を除き、 + そのデフォルトが無効になっている。 + +2) 新規の ``Kconfig`` オプションにヘルプテキストがある。 + +3) 妥当な ``Kconfig`` の組み合わせについて注意深くレビューされている。 + これをテストでやり切るのは困難で、知力が決め手となる。 + +ドキュメンテーションの作成 +========================== + +1) グローバルなカーネル API が :ref:`kernel-doc <kernel_doc>` の形式で + ドキュメント化されている (静的関数には求められないが、付けてもよい)。 + +2) 新規 ``/proc`` エントリーが、すべて ``Documentation/`` 以下に記載されて + いる。 + +3) 新規カーネル・ブート・パラメータが、すべて + ``Documentation/admin-guide/kernel-parameters.rst`` に記載されている。 + +4) 新規モジュール・パラメータが、すべて ``MODULE_PARM_DESC()`` によって記述 + されている。 + +5) 新規ユーザースペース・インターフェースが、すべて ``Documentaion/ABI/`` + 以下に記載されている。詳しくは、 Documentation/admin-guide/abi.rst + (もしくは ``Documentation/ABI/README``) を参照。 + ユーザースペース・インターフェースを変更するパッチは、 + linux-api@vger.kernel.org にも CC すべし。 + +6) なんらかの ioctl を追加するパッチは、 + ``Documentation/userspace-api/ioctl/ioctl-number.rst`` + の更新を伴う。 + +ツールによるコードのチェック +============================ + +1) スタイル・チェッカー (``scripts/checkpatch.pl``) によって、犯しがちな + パッチ・スタイルの違反がないことを確認済み。 + 指摘される違反を残す場合は、それを正当化できること。 + +2) sparse により入念にチェック済み。 + +3) ``make checkstack`` で指摘される問題があれば、それが修正済み。 + ``checkstack`` は問題点を明示的には指摘しないが、 スタック消費が + 512 バイトを越える関数は見直しの候補。 + +コードのビルド +============== + +1) 以下の条件でクリーンにビルドできる。 + + a) 適用可能な、および ``=y``, ``=m``, ``=n`` を変更した ``CONFIG`` + オプションでのビルド。 + ``gcc`` およびリンカーからの警告・エラーがないこと。 + + b) ``allnoconfig`` と ``allmodconfig`` がパス + + c) ``O=builddir`` を指定してのビルド + + d) Documentation/ 以下の変更に関して、ドキュメントのビルドで新たな警告や + エラーが出ない。 + ``make htmldocs`` または ``make pdfdocs`` でビルドし、問題があれば修正。 + +2) ローカルのクロス・コンパイル・ツール、その他のビルド環境 (訳註: build farm) + を使って、複数の CPU アーキテクチャ向けにビルドできる。 + 特に、ワードサイズ (32 ビットと 64 ビット) やエンディアン (ビッグとリトル) + の異なるアーキテクチャを対象とするテストは、表現可能数値範囲・データ整列・ + エンディアンなどについての誤った仮定に起因する様々な移植上の問題を捕える + のに効果的。 + +3) 新規に追加されたコードについて (``make KCFLAGS=-W`` を使って) + ``gcc -W`` でコンパイル。 + これは多くのノイズを伴うが、 + ``warning: comparison between signed and unsigned`` + の類いのバグをあぶり出すのに効果的。 + +4) 変更されるソースコードが、下記の ``Kconfig`` シンボルに関連するカーネル + API や機能に依存 (もしくは利用) する場合、それらの ``Kconfig`` シンボルが、 + 無効、および (可能なら) ``=m`` の場合を組み合わせた複数のビルドを + (全部まとめてではなく、いろいろなランダムの組み合わせで) テスト済み。 + + ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``, + ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``, + ``CONFIG_NET``, ``CONFIG_INET=n`` (ただし、後者は ``CONFIG_NET=y`` + との組み合わせ)。 + +コードのテスト +============== + +1) ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``, + ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``, + ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``, + ``CONFIG_PROVE_RCU`` および ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` をすべて + 同時に有効にしてのテスト済み。 + +2) ``CONFIG_SMP`` と ``CONFIG_PREEMPT`` が有効と無効の場合について、ビルドと + ランタイムのテスト済み。 + +3) lockdep の機能をすべて有効にしての実行で、すべてのコード経路が確認済み。 + +4) 最低限、slab と ページ・アロケーションの失敗に関する誤り注入 + (訳註: fault injection) によるチェック済み。 + 詳しくは、 Documentation/fault-injection/index.rst を参照。 + 新規のコードが多い場合は、サブシステム対象の誤り注入を追加するのが望ましい + 可能性あり。 + +5) linux-next の最新タグに対するテストにより、他でキューイングされている + パッチや、VM、VFS、その他のサブシステム内のすべての変更と組み合わせての + 動作を確認済み。 diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Documentation/translations/sp_SP/process/2.Process.rst index 5993eed71563..c21b0134cfa1 100644 --- a/Documentation/translations/sp_SP/process/2.Process.rst +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -428,13 +428,14 @@ los desarrolladores, que corren el riesgo de quedar enterrados bajo una carga de correo electrónico, incumplir las convenciones utilizadas en las listas de Linux, o ambas cosas. -La mayoría de las listas de correo del kernel se ejecutan en -vger.kernel.org; la lista principal se puede encontrar en: +La mayoría de las listas de correo del kernel se alojan en kernel.org; la +lista principal se puede encontrar en: - http://vger.kernel.org/vger-lists.html + https://subspace.kernel.org -Sim embargo, hay listas alojadas en otros lugares; varios de ellos se -encuentran en redhat.com/mailman/listinfo. +Sin embargo, hay listas alojadas en otros lugares; consulte el archivo +MAINTAINERS para obtener la lista relevante para cualquier subsistema en +particular. La lista de correo principal para el desarrollo del kernel es, por supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen diff --git a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst index 7d4d694967c7..9d444b9c46d3 100644 --- a/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst +++ b/Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst @@ -287,7 +287,7 @@ revelada involucrada. La lista de embajadores actuales: Google Kees Cook <keescook@chromium.org> - LLVM Nick Desaulniers <ndesaulniers@google.com> + LLVM Nick Desaulniers <nick.desaulniers+lkml@gmail.com> ============= ======================================================== Si quiere que su organización se añada a la lista de embajadores, por diff --git a/Documentation/translations/sp_SP/process/howto.rst b/Documentation/translations/sp_SP/process/howto.rst index 72ea855ac9dc..e1a6e6a52ae4 100644 --- a/Documentation/translations/sp_SP/process/howto.rst +++ b/Documentation/translations/sp_SP/process/howto.rst @@ -334,7 +334,7 @@ con el árbol principal, necesitan probar su integración. Para ello, existe un repositorio especial de pruebas en el que se encuentran casi todos los árboles de subsistema, actualizado casi a diario: - https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git + https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git De esta manera, linux-next ofrece una perspectiva resumida de lo que se espera que entre en el kernel principal en el próximo período de "merge" @@ -378,13 +378,13 @@ desarrolladores del kernel participan en la lista de correo del kernel de Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se pueden encontrar en: - http://vger.kernel.org/vger-lists.html#linux-kernel + https://subspace.kernel.org/subscribing.html Existen archivos de la lista de correo en la web en muchos lugares distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por ejemplo: - http://dir.gmane.org/gmane.linux.kernel + https://lore.kernel.org/linux-kernel/ Es muy recomendable que busque en los archivos sobre el tema que desea tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas @@ -398,13 +398,13 @@ los diferentes grupos. Muchas de las listas están alojadas en kernel.org. La información sobre estas puede ser encontrada en: - http://vger.kernel.org/vger-lists.html + https://subspace.kernel.org Recuerde mantener buenos hábitos de comportamiento al usar las listas. Aunque un poco cursi, la siguiente URL tiene algunas pautas simples para interactuar con la lista (o cualquier lista): - http://www.albion.com/netiquette/ + https://subspace.kernel.org/etiquette.html Si varias personas responden a su correo, el CC (lista de destinatarios) puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una diff --git a/Documentation/translations/sp_SP/process/kernel-docs.rst b/Documentation/translations/sp_SP/process/kernel-docs.rst index a62c6854f59b..b9e0ca4be324 100644 --- a/Documentation/translations/sp_SP/process/kernel-docs.rst +++ b/Documentation/translations/sp_SP/process/kernel-docs.rst @@ -170,9 +170,8 @@ Recursos varios * Título: **linux-kernel mailing list archives and search engines** - :URL: http://vger.kernel.org/vger-lists.html - :URL: http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html - :URL: http://groups.google.com/group/mlist.linux.kernel + :URL: https://subspace.kernel.org + :URL: https://lore.kernel.org :Palabras Clave: linux-kernel, archives, buscar, search, archivos. :Descripción: Algunos de los archivadores de listas de correo del kernel de Linux. Si usted tiene uno mejor/otro, por favor hágamelo diff --git a/Documentation/translations/sp_SP/process/submit-checklist.rst b/Documentation/translations/sp_SP/process/submit-checklist.rst index 0d6651f9d871..e7107cc97001 100644 --- a/Documentation/translations/sp_SP/process/submit-checklist.rst +++ b/Documentation/translations/sp_SP/process/submit-checklist.rst @@ -97,9 +97,10 @@ y en otros lugares con respecto al envío de parches del kernel de Linux. ``MODULE_PARM_DESC()``. 18) Todas las nuevas interfaces de espacio de usuario están documentadas - en ``Documentation/ABI/``. Consulte ``Documentation/ABI/README`` para - obtener más información. Los parches que cambian las interfaces del - espacio de usuario deben ser CCed a linux-api@vger.kernel.org. + en ``Documentation/ABI/``. Consulte Documentation/admin-guide/abi.rst + (o ``Documentation/ABI/README``) para obtener más información. + Los parches que cambian las interfaces del espacio de usuario deben + ser CCed a linux-api@vger.kernel.org. 19) Se ha comprobado con la inyección de al menos errores de asignación de slab y página. Consulte ``Documentation/fault-injection/``. diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index 328ec80bd61d..ecb08b14c2c0 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -136,11 +136,11 @@ algo documentado en la web, referencie esto. Cuando se vincule a archivos de listas de correo, preferiblemente use el servicio de archivador de mensajes lore.kernel.org. Para crear la URL del -enlace, utilice el contenido del encabezado ("header") ``Message-Id`` del +enlace, utilice el contenido del encabezado ("header") ``Message-ID`` del mensaje sin los corchetes angulares que lo rodean. Por ejemplo:: - Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + Link: https://lore.kernel.org/30th.anniversary.repost@klaava.Helsinki.FI Verifique el enlace para asegurarse de que realmente funciona y apunta al mensaje correspondiente. @@ -257,10 +257,10 @@ archivo MAINTAINERS una lista específica de los subsistemas; su parche probablemente recibirá más atención allí. Sin embargo, no envíe spam a listas no relacionadas. -Muchas listas relacionadas con el kernel están alojadas en vger.kernel.org; +Muchas listas relacionadas con el kernel están alojadas en kernel.org; puedes encontrar un listado de estas en -http://vger.kernel.org/vger-lists.html. Existen listas relacionadas con el -kernel alojadas en otros lugares, no obstante. +https://subspace.kernel.org. Existen listas relacionadas con el kernel +alojadas en otros lugares, no obstante. ¡No envíe más de 15 parches a la vez a las listas de correo de vger! @@ -907,9 +907,6 @@ Referencias <http://www.kroah.com/log/linux/maintainer-06.html> -NO!!!! Gente, no mas bombas enormes de parches a linux-kernel@vger.kernel.org! - <https://lore.kernel.org/r/20050711.125305.08322243.davem@davemloft.net> - Kernel Documentation/process/coding-style.rst Email de Linus Torvalds sobre la forma canónica de los parches: diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst index dc728c739e28..b35d24464be9 100644 --- a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst +++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst @@ -112,7 +112,7 @@ CFS usa una granularidad de nanosegundos y no depende de ningún jiffy o detalles como HZ. De este modo, el gestor de tareas CFS no tiene noción de "ventanas de tiempo" de la forma en que tenía el gestor de tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro -central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG): +central ajustable: /sys/kernel/debug/sched/base_slice_ns diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst index e679cbc3c89d..82e628b77efd 100644 --- a/Documentation/translations/zh_CN/admin-guide/README.rst +++ b/Documentation/translations/zh_CN/admin-guide/README.rst @@ -146,7 +146,7 @@ Linux内核6.x版本 <http://kernel.org/> "make xconfig" 基于Qt的配置工具。 - "make gconfig" 基于GTK+的配置工具。 + "make gconfig" 基于GTK的配置工具。 "make oldconfig" 基于现有的 ./.config 文件选择所有选项，并询问 新配置选项。 @@ -224,7 +224,7 @@ Linux内核6.x版本 <http://kernel.org/> 编译内核 --------- - - 确保您至少有gcc 5.1可用。 + - 确保您至少有gcc 8.1可用。 有关更多信息，请参阅 :ref:`Documentation/process/changes.rst <changes>` 。 - 执行 ``make`` 来创建压缩内核映像。如果您安装了lilo以适配内核makefile， diff --git a/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst b/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst index c3f6a83294dc..4b3432753eb9 100644 --- a/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst +++ b/Documentation/translations/zh_CN/admin-guide/bug-hunting.rst @@ -188,7 +188,7 @@ objdump 编行。如果没有调试符号，您将看到所示例程的汇编程序代码，但是如果内核有调试 符号，C代码也将可见（调试符号可以在内核配置菜单的hacking项中启用）。例如:: - $ objdump -r -S -l --disassemble net/dccp/ipv4.o + $ objdump -r -S -l --disassemble net/ipv4/tcp.o .. note:: diff --git a/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst index cadc580fa23b..d728e4db0b85 100644 --- a/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst @@ -17,10 +17,10 @@ OpenRISC 1000系列（或1k）。 关于OpenRISC处理器和正在进行中的开发的信息: - ======= ============================= + ======= ============================== 网站 https://openrisc.io - 邮箱 openrisc@lists.librecores.org - ======= ============================= + 邮箱 linux-openrisc@vger.kernel.org + ======= ============================== --------------------------------------------------------------------- @@ -36,11 +36,11 @@ OpenRISC工具链和Linux的构建指南 工具链的构建指南可以在openrisc.io或Stafford的工具链构建和发布脚本 中找到。 - ====== ================================================= - 二进制 https://github.com/openrisc/or1k-gcc/releases + ====== ========================================================== + 二进制 https://github.com/stffrdhrn/or1k-toolchain-build/releases 工具链 https://openrisc.io/software 构建 https://github.com/stffrdhrn/or1k-toolchain-build - ====== ================================================= + ====== ========================================================== 2) 构建 diff --git a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst index 9174fce12c1b..4a2d3b27aa4d 100644 --- a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst +++ b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst @@ -60,8 +60,6 @@ irq_domain和一个hwirq号作为参数。 如果hwirq的映射还不存在， - irq_find_mapping()返回给定域和hwirq的Linux IRQ号，如果没有映射则返回0。 -- irq_linear_revmap()现与irq_find_mapping()相同，已被废弃。 - - generic_handle_domain_irq()处理一个由域和hwirq号描述的中断。 请注意，irq域的查找必须发生在与RCU读临界区兼容的上下文中。 @@ -83,7 +81,6 @@ irq_domain映射的类型 :: - irq_domain_add_linear() irq_domain_create_linear() 线性反向映射维护了一个固定大小的表，该表以hwirq号为索引。 当一个hwirq被映射 @@ -104,7 +101,6 @@ irq_domain_add_linear()和irq_domain_create_linear()在功能上是等价的， :: - irq_domain_add_tree() irq_domain_create_tree() irq_domain维护着从hwirq号到Linux IRQ的radix的树状映射。 当一个hwirq被映射时， @@ -124,7 +120,7 @@ irq_domain_add_tree()和irq_domain_create_tree()在功能上是等价的，除 :: - irq_domain_add_nomap() + irq_domain_create_nomap() 当硬件中的hwirq号是可编程的时候，就可以采用无映射类型。 在这种情况下，最好将 Linux IRQ号编入硬件本身，这样就不需要映射了。 调用irq_create_direct_mapping() @@ -138,8 +134,6 @@ Linux IRQ号编入硬件本身，这样就不需要映射了。 调用irq_create :: - irq_domain_add_simple() - irq_domain_add_legacy() irq_domain_create_simple() irq_domain_create_legacy() diff --git a/Documentation/translations/zh_CN/core-api/printk-formats.rst b/Documentation/translations/zh_CN/core-api/printk-formats.rst index bd36d35eba4e..96a917ecc93f 100644 --- a/Documentation/translations/zh_CN/core-api/printk-formats.rst +++ b/Documentation/translations/zh_CN/core-api/printk-formats.rst @@ -523,9 +523,8 @@ clk结构体 :: %pC pll1 - %pCn pll1 -用于打印clk结构。%pC 和 %pCn 打印时钟的名称（通用时钟框架）或唯一的32位 +用于打印clk结构。%pC 打印时钟的名称（通用时钟框架）或唯一的32位 ID（传统时钟框架）。 通过引用传递。 diff --git a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst index b1bec219912d..d9477ccea98f 100644 --- a/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst +++ b/Documentation/translations/zh_CN/core-api/symbol-namespaces.rst @@ -14,18 +14,8 @@ 本文档描述了如何使用符号命名空间来构造通过EXPORT_SYMBOL()系列宏导出的内核内符号的导出面。 -.. 目录 - - === 1 简介 - === 2 如何定义符号命名空间 - --- 2.1 使用EXPORT_SYMBOL宏 - --- 2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 - === 3 如何使用命名空间中导出的符号 - === 4 加载使用命名空间符号的模块 - === 5 自动创建MODULE_IMPORT_NS声明 - -1. 简介 -======= +简介 +==== 符号命名空间已经被引入，作为构造内核内API的导出面的一种手段。它允许子系统维护者将 他们导出的符号划分进独立的命名空间。这对于文档的编写非常有用（想想SUBSYSTEM_DEBUG @@ -33,14 +23,14 @@ 的模块必须导入命名空间。否则，内核将根据其配置，拒绝加载该模块或警告说缺少 导入。 -2. 如何定义符号命名空间 -======================= +如何定义符号命名空间 +==================== 符号可以用不同的方法导出到命名空间。所有这些都在改变 EXPORT_SYMBOL 和与之类似的那些宏 被检测到的方式，以创建 ksymtab 条目。 -2.1 使用EXPORT_SYMBOL宏 -======================= +使用EXPORT_SYMBOL宏 +------------------- 除了允许将内核符号导出到内核符号表的宏EXPORT_SYMBOL()和EXPORT_SYMBOL_GPL()之外， 这些宏的变体还可以将符号导出到某个命名空间：EXPORT_SYMBOL_NS() 和 EXPORT_SYMBOL_NS_GPL()。 @@ -54,8 +44,8 @@ 导出时未指明命名空间的符号将指向 ``NULL`` 。如果没有定义命名空间，则默认没有。 ``modpost`` 和kernel/module/main.c分别在构建时或模块加载时使用名称空间。 -2.2 使用DEFAULT_SYMBOL_NAMESPACE定义 -==================================== +使用DEFAULT_SYMBOL_NAMESPACE定义 +-------------------------------- 为一个子系统的所有符号定义命名空间可能会非常冗长，并可能变得难以维护。因此，我 们提供了一个默认定义（DEFAULT_SYMBOL_NAMESPACE），如果设置了这个定义， 它将成 @@ -80,8 +70,8 @@ 应置于相关编译单元中任何 EXPORT_SYMBOL 宏之前 -3. 如何使用命名空间中导出的符号 -=============================== +如何使用命名空间中导出的符号 +============================ 为了使用被导出到命名空间的符号，内核模块需要明确地导入这些命名空间。 否则内核可能会拒绝加载该模块。模块代码需要使用宏MODULE_IMPORT_NS来 @@ -100,11 +90,10 @@ 建议将 MODULE_IMPORT_NS() 语句添加到靠近其他模块元数据定义的地方， -如 MODULE_AUTHOR() 或 MODULE_LICENSE() 。关于自动创建缺失的导入 -语句的方法，请参考第5节。 +如 MODULE_AUTHOR() 或 MODULE_LICENSE() 。 -4. 加载使用命名空间符号的模块 -============================= +加载使用命名空间符号的模块 +========================== 在模块加载时（比如 ``insmod`` ），内核将检查每个从模块中引用的符号是否可 用，以及它可能被导出到的名字空间是否被模块导入。内核的默认行为是拒绝 @@ -113,8 +102,8 @@ EINVAL方式失败。要允许加载不满足这个前提条件的模块，可 设置 MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y 将使加载不受影响，但会 发出警告。 -5. 自动创建MODULE_IMPORT_NS声明 -=============================== +自动创建MODULE_IMPORT_NS声明 +============================ 缺少命名空间的导入可以在构建时很容易被检测到。事实上，如果一个模块 使用了一个命名空间的符号而没有导入它，modpost会发出警告。 diff --git a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst index 3c133a918f30..282aacd33442 100644 --- a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst @@ -120,35 +120,31 @@ Kgdb内核调试器、QEMU等虚拟机管理程序或基于JTAG的硬件接口 - 对当前或指定的CPU使用per-cpu函数:: - (gdb) p $lx_per_cpu("runqueues").nr_running + (gdb) p $lx_per_cpu(runqueues).nr_running $3 = 1 - (gdb) p $lx_per_cpu("runqueues", 2).nr_running + (gdb) p $lx_per_cpu(runqueues, 2).nr_running $4 = 0 - 使用container_of查看更多hrtimers信息:: - (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next - (gdb) p *$container_of($next, "struct hrtimer", "node") + (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost + (gdb) p *$container_of($leftmost, "struct hrtimer", "node") $5 = { node = { node = { - __rb_parent_color = 18446612133355256072, - rb_right = 0x0 <irq_stack_union>, - rb_left = 0x0 <irq_stack_union> + __rb_parent_color = 18446612686384860673, + rb_right = 0xffff888231da8b00, + rb_left = 0x0 }, - expires = { - tv64 = 1835268000000 - } + expires = 1228461000000 }, - _softexpires = { - tv64 = 1835268000000 - }, - function = 0xffffffff81078232 <tick_sched_timer>, - base = 0xffff88003fd0d6f0, - state = 1, - start_pid = 0, - start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>, - start_comm = "swapper/2\000\000\000\000\000\000" + _softexpires = 1228461000000, + function = 0xffffffff8137ab20 <tick_nohz_handler>, + base = 0xffff888231d9b4c0, + state = 1 '\001', + is_rel = 0 '\000', + is_soft = 0 '\000', + is_hard = 1 '\001' } diff --git a/Documentation/translations/zh_CN/dev-tools/ubsan.rst b/Documentation/translations/zh_CN/dev-tools/ubsan.rst index 2487696b3772..81ef6f77caeb 100644 --- a/Documentation/translations/zh_CN/dev-tools/ubsan.rst +++ b/Documentation/translations/zh_CN/dev-tools/ubsan.rst @@ -3,7 +3,14 @@ .. include:: ../disclaimer-zh_CN.rst :Original: Documentation/dev-tools/ubsan.rst -:Translator: Dongliang Mu <dzm91@hust.edu.cn> + +:翻译: + + 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn> + +:校译: + + 王昱力 WangYuli <wangyuli@uniontech.com> 未定义行为消毒剂 - UBSAN ==================================== @@ -55,30 +62,20 @@ GCC自4.9.x [1_] （详见 ``-fsanitize=undefined`` 选项及其子选项）版 使用如下内核配置启用UBSAN:: - CONFIG_UBSAN=y - -使用如下内核配置检查整个内核:: - - CONFIG_UBSAN_SANITIZE_ALL=y - -为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容: + CONFIG_UBSAN=y -- 单文件（如main.o）:: - - UBSAN_SANITIZE_main.o := y - -- 一个目录中的所有文件:: - - UBSAN_SANITIZE := y - -即使设置了``CONFIG_UBSAN_SANITIZE_ALL=y``，为了避免文件被插桩，可使用:: +排除要被检测的文件:: UBSAN_SANITIZE_main.o := n -与:: +排除一个目录中的所有文件:: UBSAN_SANITIZE := n +当全部文件都被禁用，可通过如下方式为特定文件启用:: + + UBSAN_SANITIZE_main.o := y + 未对齐的内存访问检测可通过开启独立选项 - CONFIG_UBSAN_ALIGNMENT 检测。 该选项在支持未对齐访问的架构上(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y) 默认为关闭。该选项仍可通过内核配置启用，但它将产生大量的UBSAN报告。 diff --git a/Documentation/translations/zh_CN/devicetree/overlay-notes.rst b/Documentation/translations/zh_CN/devicetree/overlay-notes.rst index 43e3c0bc5a9f..ba5edd05dc1e 100644 --- a/Documentation/translations/zh_CN/devicetree/overlay-notes.rst +++ b/Documentation/translations/zh_CN/devicetree/overlay-notes.rst @@ -43,10 +43,10 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。 }; ---- foo.dts --------------------------------------------------------------- -覆盖bar.dts, +覆盖bar.dtso, :: - ---- bar.dts - 按标签覆盖目标位置 ---------------------------- + ---- bar.dtso - 按标签覆盖目标位置 --------------------------- /dts-v1/; /插件/; &ocp { @@ -56,7 +56,7 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。 ... /* 各种属性和子节点 */ }; }; - ---- bar.dts --------------------------------------------------------------- + ---- bar.dtso -------------------------------------------------------------- 当加载（并按照[1]中描述的方式解决）时，应该产生foo+bar.dts:: @@ -90,9 +90,9 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。 DT中的适当位置。在这种情况下，可以提供目标路径。通过标签的目标位置的语法是比 较好的，因为不管标签在DT中出现在哪里，覆盖都可以被应用到任何包含标签的基础DT上。 -上面的bar.dts例子被修改为使用目标路径语法，即为:: +上面的bar.dtso例子被修改为使用目标路径语法，即为:: - ---- bar.dts - 通过明确的路径覆盖目标位置 -------------------- + ---- bar.dtso - 通过明确的路径覆盖目标位置 ------------------- /dts-v1/; /插件/; &{/ocp} { @@ -102,7 +102,7 @@ DT中的适当位置。在这种情况下，可以提供目标路径。通过标 ... /* 各种外围设备和子节点 */ } }; - ---- bar.dts --------------------------------------------------------------- + ---- bar.dtso -------------------------------------------------------------- 内核中关于覆盖的API diff --git a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst index 3c6db094a63c..37681c0b2a01 100644 --- a/Documentation/translations/zh_CN/disclaimer-zh_CN.rst +++ b/Documentation/translations/zh_CN/disclaimer-zh_CN.rst @@ -1,9 +1,7 @@ :orphan: -.. warning:: +.. note:: 此文件的目的是为让中文读者更容易阅读和理解，而不是作为一个分支。 因此， 如果您对此文件有任何意见或更新，请先尝试更新原始英文文件。 - -.. note:: - 如果您发现本文档与原始文件有任何不同或者有翻译问题，请联系该文件的译者， - 或者请求时奎亮的帮助：<alexs@kernel.org>。 + 如果您发现本文档与原始文件有任何不同或者有翻译问题，请发建议或者补丁给 + 该文件的译者，或者请求中文文档维护者和审阅者的帮助。 diff --git a/Documentation/translations/zh_CN/driver-api/gpio/index.rst b/Documentation/translations/zh_CN/driver-api/gpio/index.rst index e4d54724a1b5..f64a69f771ca 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/index.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/index.rst @@ -42,7 +42,7 @@ ACPI支持 该API在以下内核代码中: -drivers/gpio/gpiolib-acpi.c +drivers/gpio/gpiolib-acpi-core.c 设备树支持 ========== diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst new file mode 100644 index 000000000000..569b0209385a --- /dev/null +++ b/Documentation/translations/zh_CN/how-to.rst @@ -0,0 +1,459 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +Linux内核中文文档翻译规范 +========================= + +修订记录： + - v1.0 2025年3月28日，司延腾、慕冬亮共同编写了该规范。 + +制定规范的背景 +============== + +过去几年，在广大社区爱好者的友好合作下，Linux 内核中文文档迎来了蓬勃的发 +展。在翻译的早期，一切都是混乱的，社区对译稿只有一个准确翻译的要求，以鼓 +励更多的开发者参与进来，这是从0到1的必然过程，所以早期的中文文档目录更加 +具有多样性，不过好在文档不多，维护上并没有过大的压力。 + +然而，世事变幻，不觉有年，现在内核中文文档在前进的道路上越走越远，很多潜 +在的问题逐渐浮出水面，而且随着中文文档数量的增加，翻译更多的文档与提高中 +文文档可维护性之间的矛盾愈发尖锐。由于文档翻译的特殊性，很多开发者并不会 +一直更新文档，如果中文文档落后英文文档太多，文档更新的工作量会远大于重新 +翻译。而且邮件列表中陆续有新的面孔出现，他们那股热情，就像燃烧的火焰，能 +瞬间点燃整个空间，可是他们的补丁往往具有个性，这会给审阅带来了很大的困难， +reviewer 们只能耐心地指导他们如何与社区更好地合作，但是这项工作具有重复 +性，长此以往，会渐渐浇灭 reviewer 审阅的热情。 + +虽然内核文档中已经有了类似的贡献指南，但是缺乏专门针对于中文翻译的，尤其 +是对于新手来说，浏览大量的文档反而更加迷惑，该文档就是为了缓解这一问题而 +编写，目的是为提供给新手一个快速翻译指南。 + +详细的贡献指南：Documentation/translations/zh_CN/process/index.rst。 + +环境搭建 +======== + +工欲善其事必先利其器，如果您目前对内核文档翻译满怀热情，并且会独立地安装 +linux 发行版和简单地使用 linux 命令行，那么可以迅速开始了。若您尚不具备该 +能力，很多网站上会有详细的手把手教程，最多一个上午，您应该就能掌握对应技 +能。您需要注意的一点是，请不要使用 root 用户进行后续步骤和文档翻译。 + +拉取开发树 +---------- + +中文文档翻译工作目前独立于 linux-doc 开发树开展，所以您需要拉取该开发树， +打开终端命令行执行:: + + git clone git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git + +如果您遇到网络连接问题，也可以执行以下命令:: + + git clone https://mirrors.hust.edu.cn/git/kernel-doc-zh.git linux + +这是 Alex 开发树的镜像库，每两个小时同步一次上游。如果您了解到更快的 mirror， +请随时 **添加** 。 + +命令执行完毕后，您会在当前目录下得到一个 linux 目录，该目录就是您之后的工作 +仓库，请把它放在一个稳妥的位置。 + +安装文档构建环境 +---------------- + +内核仓库里面提供了一个半自动化脚本，执行该脚本，会检测您的发行版中需要安 +装哪些软件包，请按照命令行提示进行安装，通常您只需要复制命令并执行就行。 +:: + + cd linux + ./scripts/sphinx-pre-install + +以Fedora为例，它的输出是这样的:: + + You should run: + + sudo dnf install -y dejavu-sans-fonts dejavu-sans-mono-fonts dejavu-serif-fonts google-noto-sans-cjk-fonts graphviz-gd latexmk librsvg2-tools texlive-anyfontsize texlive-capt-of texlive-collection-fontsrecommended texlive-ctex texlive-eqparbox texlive-fncychap texlive-framed texlive-luatex85 texlive-multirow texlive-needspace texlive-tabulary texlive-threeparttable texlive-upquote texlive-wrapfig texlive-xecjk + + Sphinx needs to be installed either: + 1) via pip/pypi with: + + /usr/bin/python3 -m venv sphinx_latest + . sphinx_latest/bin/activate + pip install -r ./Documentation/sphinx/requirements.txt + + If you want to exit the virtualenv, you can use: + deactivate + + 2) As a package with: + + sudo dnf install -y python3-sphinx + + Please note that Sphinx >= 3.0 will currently produce false-positive + warning when the same name is used for more than one type (functions, + structs, enums,...). This is known Sphinx bug. For more details, see: + https://github.com/sphinx-doc/sphinx/pull/8313 + +请您按照提示复制打印的命令到命令行执行，您必须具备 root 权限才能执行 sudo +开头的命令。 + +如果您处于一个多用户环境中，为了避免对其他人造成影响，建议您配置单用户 +sphinx 虚拟环境，即只需要执行:: + + /usr/bin/python3 -m venv sphinx_latest + . sphinx_latest/bin/activate + pip install -r ./Documentation/sphinx/requirements.txt + +最后执行以下命令退出虚拟环境:: + + deactivate + +您可以在任何需要的时候再次执行以下命令进入虚拟环境:: + + . sphinx_latest/bin/activate + +进行第一次文档编译 +------------------ + +进入开发树目录:: + + cd linux + +这是一个标准的编译和调试流程，请每次构建时都严格执行:: + + . sphinx_latest/bin/activate + make cleandocs + make htmldocs + deactivate + +检查编译结果 +------------ + +编译输出在Documentation/output/目录下，请用浏览器打开该目录下对应 +的文件进行检查。 + +git和邮箱配置 +------------- + +打开命令行执行:: + + sudo dnf install git-email + vim ~/.gitconfig + +这里是我的一个配置文件示范，请根据您的邮箱域名服务商提供的手册替换到对 +应的字段。 +:: + + [user] + name = Yanteng Si # 这会出现在您的补丁头部签名栏 + email = si.yanteng@linux.dev # 这会出现在您的补丁头部签名栏 + + [sendemail] + from = Yanteng Si <si.yanteng@linux.dev> # 这会出现在您的补丁头部 + smtpencryption = ssl + smtpserver = smtp.migadu.com + smtpuser = si.yanteng@linux.dev + smtppass = <passwd> # 建议使用第三方客户端专用密码 + chainreplyto = false + smtpserverport = 465 + +关于邮件客户端的配置，请查阅Documentation/translations/zh_CN/process/email-clients.rst。 + +开始翻译文档 +============ + +文档索引结构 +------------ + +目前中文文档是在Documentation/translations/zh_CN/目录下进行，该 +目录结构最终会与Documentation/结构一致，所以您只需要将您感兴趣的英文 +文档文件和对应的 index.rst 复制到 zh_CN 目录下对应的位置，然后修改更 +上一级的 index 即可开始您的翻译。 + +为了保证翻译的文档补丁被顺利合并，不建议多人同时翻译一个目录，因为这会 +造成补丁之间互相依赖，往往会导致一部分补丁被合并，另一部分产生冲突。 + +如果实在无法避免两个人同时对一个目录进行翻译的情况，请将补丁制作进一个补 +丁集。但是不推荐刚开始就这么做，因为经过实践，在没有指导的情况下，新手很 +难一次处理好这个补丁集。 + +请执行以下命令，新建开发分支:: + + git checkout docs-next + git branch my-trans + git checkout my-trans + +译文格式要求 +------------ + + - 每行长度最多不超过40个字符 + - 每行长度请保持一致 + - 标题的下划线长度请按照一个英文一个字符、一个中文两个字符与标题对齐 + - 其它的修饰符请与英文文档保持一致 + +此外在译文的头部，您需要插入以下内容:: + + .. SPDX-License-Identifier: GPL-2.0 + .. include:: ../disclaimer-zh_CN.rst #您需要了解该文件的路径，根 + 据您实际翻译的文档灵活调整 + + :Original: Documentation/xxx/xxx.rst #替换为您翻译的英文文档路径 + + :翻译: + + 司延腾 Yanteng Si <si.yanteng@linux.dev> #替换为您自己的联系方式 + +翻译技巧 +-------- + +中文文档有每行40字符限制，因为一个中文字符等于2个英文字符。但是社区并没有 +那么严格，一个诀窍是将您的翻译的内容与英文原文的每行长度对齐即可，这样， +您也不必总是检查有没有超限。 + +如果您的英文阅读能力有限，可以考虑使用辅助翻译工具，例如 deepseek 。但是您 +必须仔细地打磨，使译文达到“信达雅”的标准。 + +**请注意** 社区不接受纯机器翻译的文档，社区工作建立在信任的基础上，请认真对待。 + +编译和检查 +---------- + +请执行:: + + . sphinx_latest/bin/activate + make cleandocs + make htmldocs + +解决与您翻译的文档相关的 warning 和 error，然后执行:: + + make cleandocs #该步骤不能省略，否则可能不会再次输出真实存在的警告 + make htmldocs + deactivate + +进入 output 目录用浏览器打开您翻译的文档，检查渲染的页面是否正常，如果正常， +继续进行后续步骤，否则请尝试解决。 + +制作补丁 +======== + +提交改动 +-------- + +执行以下命令，在弹出的交互式页面中填写必要的信息。 +:: + + git add . + git commit -s -v + +请参考以下信息进行输入:: + + docs/zh_CN: Add self-protection index Chinese translation + + Translate .../security/self-protection.rst into Chinese. + + Update the translation through commit b080e52110ea #请执行git log <您翻译的英文文档路径> 复制最顶部第一个补丁的sha值的前12位，替换掉12位sha值。 + ("docs: update self-protection __ro_after_init status") + + Signed-off-by: Yanteng Si <si.yanteng@linux.dev> #如果您前面的步骤正确执行，该行会自动显示，否则请检查gitconfig文件。 + +保存并退出。 + +**请注意** 以上四行，缺少任何一行，您都将会在第一轮审阅后返工，如果您需要一个更加明确的示例，请对 zh_CN 目录执行 git log。 + +导出补丁和制作封面 +------------------ + +这个时候，可以导出补丁，做发送邮件列表最后的准备了。命令行执行:: + + git format-patch -N + +然后命令行会输出类似下面的内容:: + + 0001-docs-zh_CN-add-xxxxxxxx.patch + 0002-docs-zh_CN-add-xxxxxxxx.patch + …… + +测试补丁 +-------- + +内核提供了一个补丁检测脚本，请执行:: + + ./scripts/checkpatch.pl *.patch + +参考脚本输出，解决掉所有的 error 和 warning，通常情况下，只有下面这个 +warning 不需要解决:: + + WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? + +一个简单的解决方法是一次只检查一个补丁，然后打上该补丁，直接对译文进行修改， +然后执行以下命令为补丁追加更改:: + + git checkout docs-next + git branch test-trans + git am 0001-xxxxx.patch + ./scripts/checkpatch.pl 0001-xxxxx.patch + 直接修改您的翻译 + git add . + git am --amend + 保存退出 + git am 0002-xxxxx.patch + …… + +重新导出再次检测，重复这个过程，直到处理完所有的补丁。 + +最后，如果检测时没有 warning 和 error 需要被处理或者您只有一个补丁，请跳 +过下面这个步骤，否则请重新导出补丁制作封面:: + + git format-patch -N --cover-letter --thread=shallow #N为您的补丁数量,N一般要大于1。 + +然后命令行会输出类似下面的内容:: + + 0000-cover-letter.patch + 0001-docs-zh_CN-add-xxxxxxxx.patch + 0002-docs-zh_CN-add-xxxxxxxx.patch + +您需要用编辑器打开0号补丁，修改两处内容:: + + vim 0000-cover-letter.patch + + ... + Subject: [PATCH 0/1] *** SUBJECT HERE *** #修改该字段，概括您的补丁集都做了哪些事情 + + *** BLURB HERE *** #修改该字段，详细描述您的补丁集做了哪些事情 + + Yanteng Si (1): + docs/zh_CN: add xxxxx + ... + +如果您只有一个补丁，则可以不制作封面，即0号补丁，只需要执行:: + + git format-patch -1 + +把补丁提交到邮件列表 +==================== + +恭喜您，您的文档翻译现在可以提交到邮件列表了。 + +获取维护者和审阅者邮箱以及邮件列表地址 +-------------------------------------- + +内核提供了一个自动化脚本工具，请执行:: + + ./scripts/get_maintainer.pl *.patch + +将输出的邮箱地址保存下来。 + +将补丁提交到邮件列表 +-------------------- + +打开上面您保存的邮件地址，执行:: + + git send-email *.patch --to <maintainer email addr> --cc <others addr> #一个to对应一个地址，一个cc对应一个地址，有几个就写几个。 + +执行该命令时，请确保网络通常，邮件发送成功一般会返回250。 + +您可以先发送给自己，尝试发出的 patch 是否可以用 'git am' 工具正常打上。 +如果检查正常， 您就可以放心的发送到社区评审了。 + +如果该步骤被中断，您可以检查一下，继续用上条命令发送失败的补丁，一定不要再 +次发送已经发送成功的补丁。 + +积极参与审阅过程并迭代补丁 +========================== + +补丁提交到邮件列表并不代表万事大吉，您还需要积极回复 maintainer 和 +reviewer 的评论，做到每条都有回复，每个回复都落实到位。 + +如何回复评论 +------------ + + - 请先将您的邮箱客户端信件回复修改为 **纯文本** 格式，并去除所有签名，尤其是 + 企业邮箱。 + - 然后点击回复按钮，并将要回复的邮件带入， + - 在第一条评论行尾换行，输入您的回复 + - 在第二条评论行尾换行，输入您的回复 + - 直到处理完最后一条评论，换行空两行输入问候语和署名 + +注意，信件回复请尽量使用英文。 + +迭代补丁 +-------- + +建议您每回复一条评论，就修改一处翻译。然后重新生成补丁，相信您现在已经具 +备了灵活使用 git am --amend 的能力。 + +每次迭代一个补丁，不要一次多个:: + + git am <您要修改的补丁> + 直接对文件进行您的修改 + git add . + git commit --amend + +当您将所有的评论落实到位后，导出第二版补丁，并修改封面:: + + git format-patch -N -v 2 --cover-letter --thread=shallow + +打开0号补丁，在 BLURB HERE 处编写相较于上个版本，您做了哪些改动。 + +然后执行:: + + git send-email v2* --to <maintainer email addr> --cc <others addr> + +这样，新的一版补丁就又发送到邮件列表等待审阅，之后就是重复这个过程。 + +审阅周期 +-------- + +因为有时邮件列表比较繁忙，您的邮件可能会被淹没，如果超过两周没有得到任何 +回复，请自己回复自己，回复的内容为 Ping. + +最终，如果您落实好了所有的评论，并且一段时间后没有最新的评论，您的补丁将 +会先进入 Alex 的开发树，然后进入 linux-doc 开发树，最终在下个窗口打开 +时合并进 mainline 仓库。 + +紧急处理 +-------- + +如果您发送到邮件列表之后。发现发错了补丁集，尤其是在多个版本迭代的过程中； +自己发现了一些不妥的翻译；发送错了邮件列表…… + +git email默认会抄送给您一份，所以您可以切换为审阅者的角色审查自己的补丁， +并留下评论，描述有何不妥，将在下个版本怎么改，并付诸行动，重新提交，但是 +注意频率，每天提交的次数不要超过两次。 + +新手任务 +-------- +对于首次参与 Linux 内核中文文档翻译的新手，建议您在 linux 目录中运行以下命令： +:: + + ./script/checktransupdate.py -l zh_CN`` + +该命令会列出需要翻译或更新的英文文档。 + +关于详细操作说明，请参考： Documentation/translations/zh_CN/doc-guide/checktransupdate.rst\ + +进阶 +---- + +希望您不只是单纯的翻译内核文档，在熟悉了一起与社区工作之后，您可以审阅其他 +开发者的翻译，或者提出具有建设性的主张。与此同时，与文档对应的代码更加有趣， +而且需要完善的地方还有很多，勇敢地去探索，然后提交你的想法吧。 + +常见的问题 +========== + +Maintainer回复补丁不能正常apply +------------------------------- + +这通常是因为您的补丁与邮件列表其他人的补丁产生了冲突，别人的补丁先被 apply 了， +您的补丁集就无法成功 apply 了，这需要您更新本地分支，在本地解决完冲突后再次提交。 + +请尽量避免冲突，不要多个人同时翻译一个目录。翻译之前可以通过 git log 查看您感 +兴趣的目录近期有没有其他人翻译，如果有，请提前私信联系对方，请求其代为发送您 +的补丁。如果对方未来一个月内没有提交新补丁的打算，您可以独自发送。 + +回信被邮件列表拒收 +------------------ + +大部分情况下，是由于您发送了非纯文本格式的信件，请尽量避免使用 webmail，推荐 +使用邮件客户端，比如 thunderbird，记得在设置中的回信配置那改为纯文本发送。 + +如果超过了24小时，您依旧没有在<https://lore.kernel.org/linux-doc/>发现您的邮 +件，请联系您的网络管理员帮忙解决。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 7574e1673180..b08c09d8e96e 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -21,12 +21,18 @@ 这是中文内核文档树的顶级目录。内核文档，就像内核本身一样，在很大程度上是一 项正在进行的工作；当我们努力将许多分散的文件整合成一个连贯的整体时尤其如此。 另外，随时欢迎您对内核文档进行改进；如果您想提供帮助，请加入vger.kernel.org -上的linux-doc邮件列表。 +上的linux-doc邮件列表，并按照Documentation/translations/zh_CN/how-to.rst的 +指引提交补丁。提交补丁之前请确保执行"make htmldocs”后无与翻译有关的异常输出。 -顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文 -的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时， -中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将 -补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。 +如何翻译内核文档 +---------------- + +翻译文档本身是一件很简单的事情，但是提交补丁需要注意一些细节，为了保证内核中文文档的高质量可持续发展，提供了一份翻译指南。 + +.. toctree:: + :maxdepth: 1 + + how-to.rst 与Linux 内核社区一起工作 ------------------------ diff --git a/Documentation/translations/zh_CN/mm/balance.rst b/Documentation/translations/zh_CN/mm/balance.rst index 6fd79209c307..f877c0cfa39a 100644 --- a/Documentation/translations/zh_CN/mm/balance.rst +++ b/Documentation/translations/zh_CN/mm/balance.rst @@ -64,7 +64,7 @@ kswapd并不真正需要平衡高内存区，因为中断上下文并不请求 如果从进程内存和shm中偷取页面可以减轻该页面节点中任何区的内存压力，而该区的内存压力 已经低于其水位，则会进行偷取。 -watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： +watermark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： 这些是每个区的字段，用于确定一个区何时需要平衡。当页面数低于水位[WMARK_MIN]时， hysteric 的字段low_on_memory被设置。这个字段会一直被设置，直到空闲页数变成水位 [WMARK_HIGH]。当low_on_memory被设置时，页面分配请求将尝试释放该区域的一些页面（如果 diff --git a/Documentation/translations/zh_CN/mm/hmm.rst b/Documentation/translations/zh_CN/mm/hmm.rst index 0669f947d0bc..22c210f4e94f 100644 --- a/Documentation/translations/zh_CN/mm/hmm.rst +++ b/Documentation/translations/zh_CN/mm/hmm.rst @@ -326,7 +326,7 @@ devm_memunmap_pages() 和 devm_release_mem_region() 当资源可以绑定到 ``s 一些设备具有诸如原子PTE位的功能，可以用来实现对系统内存的原子访问。为了支持对一 个共享的虚拟内存页的原子操作，这样的设备需要对该页的访问是排他的，而不是来自CPU -的任何用户空间访问。 ``make_device_exclusive_range()`` 函数可以用来使一 +的任何用户空间访问。 ``make_device_exclusive()`` 函数可以用来使一 个内存范围不能从用户空间访问。 这将用特殊的交换条目替换给定范围内的所有页的映射。任何试图访问交换条目的行为都会 diff --git a/Documentation/translations/zh_CN/mm/index.rst b/Documentation/translations/zh_CN/mm/index.rst index c8726bce8f74..a71116be058f 100644 --- a/Documentation/translations/zh_CN/mm/index.rst +++ b/Documentation/translations/zh_CN/mm/index.rst @@ -58,7 +58,6 @@ Linux内存管理文档 remap_file_pages split_page_table_lock vmalloced-kernel-stacks - z3fold zsmalloc TODOLIST: diff --git a/Documentation/translations/zh_CN/mm/z3fold.rst b/Documentation/translations/zh_CN/mm/z3fold.rst deleted file mode 100644 index 9569a6d88270..000000000000 --- a/Documentation/translations/zh_CN/mm/z3fold.rst +++ /dev/null @@ -1,31 +0,0 @@ -:Original: Documentation/mm/z3fold.rst - -:翻译: - - 司延腾 Yanteng Si <siyanteng@loongson.cn> - -:校译: - - -====== -z3fold -====== - -z3fold是一个专门用于存储压缩页的分配器。它被设计为每个物理页最多可以存储三个压缩页。 -它是zbud的衍生物，允许更高的压缩率，保持其前辈的简单性和确定性。 - -z3fold和zbud的主要区别是: - -* 与zbud不同的是，z3fold允许最大的PAGE_SIZE分配。 -* z3fold在其页面中最多可以容纳3个压缩页面 -* z3fold本身没有输出任何API，因此打算通过zpool的API来使用 - -为了保持确定性和简单性，z3fold，就像zbud一样，总是在每页存储一个整数的压缩页，但是 -它最多可以存储3页，不像zbud最多可以存储2页。因此压缩率达到2.7倍左右，而zbud的压缩 -率是1.7倍左右。 - -不像zbud（但也像zsmalloc），z3fold_alloc()那样不返回一个可重复引用的指针。相反，它 -返回一个无符号长句柄，它编码了被分配对象的实际位置。 - -保持有效的压缩率接近于zsmalloc，z3fold不依赖于MMU的启用，并提供更可预测的回收行 -为，这使得它更适合于小型和反应迅速的系统。 diff --git a/Documentation/translations/zh_CN/networking/index.rst b/Documentation/translations/zh_CN/networking/index.rst new file mode 100644 index 000000000000..d07dd69f980b --- /dev/null +++ b/Documentation/translations/zh_CN/networking/index.rst @@ -0,0 +1,160 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/networking/index.rst + +:翻译: + + 王亚鑫 Wang Yaxin <wang.yaxin@zte.com.cn> + +:校译: + +网络 +==== + +有关网络设备（netdev）开发过程的详细指南，请参考：:ref:`netdev-FAQ` + +目录： + +.. toctree:: + :maxdepth: 1 + + msg_zerocopy + +Todolist: + +* af_xdp +* bareudp +* batman-adv +* can +* can_ucan_protocol +* device_drivers/index +* diagnostic/index +* dsa/index +* devlink/index +* caif/index +* ethtool-netlink +* ieee802154 +* iso15765-2 +* j1939 +* kapi +* failover +* net_dim +* net_failover +* page_pool +* phy +* sfp-phylink +* alias +* bridge +* snmp_counter +* checksum-offloads +* segmentation-offloads +* scaling +* tls +* tls-offload +* tls-handshake +* nfc +* 6lowpan +* 6pack +* arcnet-hardware +* arcnet +* atm +* ax25 +* bonding +* cdc_mbim +* dccp +* dctcp +* devmem +* dns_resolver +* driver +* eql +* fib_trie +* filter +* generic-hdlc +* generic_netlink +* netlink_spec/index +* gen_stats +* gtp +* ila +* ioam6-sysctl +* ip_dynaddr +* ipsec +* ip-sysctl +* ipv6 +* ipvlan +* ipvs-sysctl +* kcm +* l2tp +* lapb-module +* mac80211-injection +* mctp +* mpls-sysctl +* mptcp +* mptcp-sysctl +* multiqueue +* multi-pf-netdev +* napi +* net_cachelines/index +* netconsole +* netdev-features +* netdevices +* netfilter-sysctl +* netif-msg +* netmem +* nexthop-group-resilient +* nf_conntrack-sysctl +* nf_flowtable +* oa-tc6-framework +* openvswitch +* operstates +* packet_mmap +* phonet +* phy-link-topology +* pktgen +* plip +* ppp_generic +* proc_net_tcp +* pse-pd/index +* radiotap-headers +* rds +* regulatory +* representors +* rxrpc +* sctp +* secid +* seg6-sysctl +* skbuff +* smc-sysctl +* sriov +* statistics +* strparser +* switchdev +* sysfs-tagging +* tc-actions-env-rules +* tc-queue-filters +* tcp_ao +* tcp-thin +* team +* timestamping +* tipc +* tproxy +* tuntap +* udplite +* vrf +* vxlan +* x25 +* x25-iface +* xfrm_device +* xfrm_proc +* xfrm_sync +* xfrm_sysctl +* xdp-rx-metadata +* xsk-tx-metadata + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/networking/msg_zerocopy.rst b/Documentation/translations/zh_CN/networking/msg_zerocopy.rst new file mode 100644 index 000000000000..821b32c4d1bf --- /dev/null +++ b/Documentation/translations/zh_CN/networking/msg_zerocopy.rst @@ -0,0 +1,223 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/networking/msg_zerocopy.rst + +:翻译: + + 王亚鑫 Wang Yaxin <wang.yaxin@zte.com.cn> + +:校译: + + - 徐鑫 xu xin <xu.xin16@zte.com.cn> + - 何配林 He Peilin <he.peilin@zte.com.cn> + +============ +MSG_ZEROCOPY +============ + +简介 +==== + +MSG_ZEROCOPY 标志用于启用套接字发送调用的免拷贝功能。该功能目前适用于 TCP、UDP 和 VSOCK +（使用 virtio 传输）套接字。 + +机遇与注意事项 +-------------- + +在用户进程与内核之间拷贝大型缓冲区可能会消耗大量资源。Linux 支持多种免拷贝的接口，如sendfile +和 splice。MSG_ZEROCOPY 标志将底层的拷贝避免机制扩展到了常见的套接字发送调用中。 + +免拷贝并非毫无代价。在实现上，它通过页面固定（page pinning）将按字节拷贝的成本替换为页面统计 +（page accounting）和完成通知的开销。因此，MSG_ZEROCOPY 通常仅在写入量超过大约 10 KB 时 +才有效。 + +页面固定还会改变系统调用的语义。它会暂时在进程和网络堆栈之间共享缓冲区。与拷贝不同，进程在系统 +调用返回后不能立即覆盖缓冲区，否则可能会修改正在传输中的数据。内核的完整性不会受到影响，但有缺 +陷的程序可能会破坏自己的数据流。 + +当内核返回数据可以安全修改的通知时，进程才可以修改数据。因此，将现有应用程序转换为使用 +MSG_ZEROCOPY 并非总是像简单地传递该标志那样容易。 + +更多信息 +-------- + +本文档的大部分内容是来自于 netdev 2.1 上发表的一篇长篇论文。如需更深入的信息，请参阅该论文和 +演讲，或者浏览 LWN.net 上的精彩报道，也可以直接阅读源码。 + + 论文、幻灯片、视频： + https://netdevconf.org/2.1/session.html?debruijn + + LWN 文章： + https://lwn.net/Articles/726917/ + + 补丁集： + [PATCH net-next v4 0/9] socket sendmsg MSG_ZEROCOPY + https://lore.kernel.org/netdev/20170803202945.70750-1-willemdebruijn.kernel@gmail.com + +接口 +==== + +传递 MSG_ZEROCOPY 标志是启用免拷贝功能的最明显步骤，但并非唯一的步骤。 + +套接字设置 +---------- + +当应用程序向 send 系统调用传递未定义的标志时，内核通常会宽容对待。默认情况下，它会简单地忽略 +这些标志。为了避免为那些偶然传递此标志的遗留进程启用免拷贝模式，进程必须首先通过设置套接字选项 +来表明意图： + +:: + + if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one))) + error(1, errno, "setsockopt zerocopy"); + +传输 +---- + +对 send（或 sendto、sendmsg、sendmmsg）本身的改动非常简单。只需传递新的标志即可。 + +:: + + ret = send(fd, buf, sizeof(buf), MSG_ZEROCOPY); + +如果零拷贝操作失败，将返回 -1，并设置 errno 为 ENOBUFS。这种情况可能发生在套接字超出其 +optmem 限制，或者用户超出其锁定页面的 ulimit 时。 + +混合使用免拷贝和拷贝 +~~~~~~~~~~~~~~~~~~~~ + +许多工作负载同时包含大型和小型缓冲区。由于对于小数据包来说，免拷贝的成本高于拷贝，因此该 +功能是通过标志实现的。带有标志的调用和没有标志的调用可以安全地混合使用。 + +通知 +---- + +当内核认为可以安全地重用之前传递的缓冲区时，它必须通知进程。完成通知在套接字的错误队列上 +排队，类似于传输时间戳接口。 + +通知本身是一个简单的标量值。每个套接字都维护一个内部的无符号 32 位计数器。每次带有 +MSG_ZEROCOPY 标志的 send 调用成功发送数据时，计数器都会增加。如果调用失败或长度为零， +则计数器不会增加。该计数器统计系统调用的调用次数，而不是字节数。在 UINT_MAX 次调用后， +计数器会循环。 + +通知接收 +~~~~~~~~ + +下面的代码片段展示了 API 的使用。在最简单的情况下，每次 send 系统调用后，都会对错误队列 +进行轮询和 recvmsg 调用。 + +从错误队列读取始终是一个非阻塞操作。poll 调用用于阻塞，直到出现错误。它会在其输出标志中 +设置 POLLERR。该标志不需要在 events 字段中设置。错误会无条件地发出信号。 + +:: + + pfd.fd = fd; + pfd.events = 0; + if (poll(&pfd, 1, -1) != 1 || pfd.revents & POLLERR == 0) + error(1, errno, "poll"); + + ret = recvmsg(fd, &msg, MSG_ERRQUEUE); + if (ret == -1) + error(1, errno, "recvmsg"); + +read_notification(msg); + + +这个示例仅用于演示目的。在实际应用中，不等待通知，而是每隔几次 send 调用就进行一次非阻塞 +读取会更高效。 + +零拷贝通知可以与其他套接字操作乱序处理。通常，拥有错误队列套接字会阻塞其他操作，直到错误 +被读取。然而，零拷贝通知具有零错误代码，因此不会阻塞 send 和 recv 调用。 + +通知批处理 +~~~~~~~~~~~~ + +可以使用 recvmmsg 调用来一次性读取多个未决的数据包。这通常不是必需的。在每条消息中，内核 +返回的不是一个单一的值，而是一个范围。当错误队列上有一个通知正在等待接收时，它会将连续的通 +知合并起来。 + +当一个新的通知即将被排队时，它会检查队列尾部的通知的范围是否可以扩展以包含新的值。如果是这 +样，它会丢弃新的通知数据包，并增大未处理通知的范围上限值。 + +对于按顺序确认数据的协议（如 TCP），每个通知都可以合并到前一个通知中，因此在任何时候在等待 +的通知都不会超过一个。 + +有序交付是常见的情况，但不能保证。在重传和套接字拆除时，通知可能会乱序到达。 + +通知解析 +~~~~~~~~ + +下面的代码片段演示了如何解析控制消息：前面代码片段中的 read_notification() 调用。通知 +以标准错误格式 sock_extended_err 编码。 + +控制数据中的级别和类型字段是协议族特定的，对于 TCP 或 UDP 套接字，分别为 IP_RECVERR 或 +IPV6_RECVERR。对于 VSOCK 套接字，cmsg_level 为 SOL_VSOCK，cmsg_type 为 VSOCK_RECVERR。 + +错误来源是新的类型 SO_EE_ORIGIN_ZEROCOPY。如前所述，ee_errno 为零，以避免在套接字上 +阻塞地读取和写入系统调用。 + +32 位通知范围编码为 [ee_info, ee_data]。这个范围是包含边界值的。除了下面讨论的 ee_code +字段外，结构中的其他字段应被视为未定义的。 + +:: + + struct sock_extended_err *serr; + struct cmsghdr *cm; + + cm = CMSG_FIRSTHDR(msg); + if (cm->cmsg_level != SOL_IP && + cm->cmsg_type != IP_RECVERR) + error(1, 0, "cmsg"); + + serr = (void *) CMSG_DATA(cm); + if (serr->ee_errno != 0 || + serr->ee_origin != SO_EE_ORIGIN_ZEROCOPY) + error(1, 0, "serr"); + +printf("completed: %u..%u\n", serr->ee_info, serr->ee_data); + + +延迟拷贝 +~~~~~~~~ + +传递标志 MSG_ZEROCOPY 是向内核发出的一个提示，让内核采用免拷贝的策略，同时也是一种约 +定，即内核会对完成通知进行排队处理。但这并不保证拷贝操作一定会被省略。 + +拷贝避免不总是适用的。不支持分散/聚集 I/O 的设备无法发送由内核生成的协议头加上零拷贝用户 +数据组成的数据包。数据包可能需要在协议栈底层转换为一份私有数据副本，例如用于计算校验和。 + +在所有这些情况下，当内核释放对共享页面的持有权时，它会返回一个完成通知。该通知可能在（已 +拷贝）数据完全传输之前到达。因此。零拷贝完成通知并不是传输完成通知。 + +如果数据不在缓存中，延迟拷贝可能会比立即在系统调用中拷贝开销更大。进程还会因通知处理而产 +生成本，但却没有带来任何好处。因此，内核会在返回时通过在 ee_code 字段中设置标志 +SO_EE_CODE_ZEROCOPY_COPIED 来指示数据是否以拷贝的方式完成。进程可以利用这个信号，在 +同一套接字上后续的请求中停止传递 MSG_ZEROCOPY 标志。 + +实现 +==== + +环回 +---- + +对于 TCP 和 UDP： +如果接收进程不读取其套接字，发送到本地套接字的数据可能会无限期排队。无限期的通知延迟是不 +可接受的。因此，所有使用 MSG_ZEROCOPY 生成并环回到本地套接字的数据包都将产生延迟拷贝。 +这包括环回到数据包套接字（例如，tcpdump）和 tun 设备。 + +对于 VSOCK： +发送到本地套接字的数据路径与非本地套接字相同。 + +测试 +==== + +更具体的示例代码可以在内核源码的 tools/testing/selftests/net/msg_zerocopy.c 中找到。 + +要留意环回约束问题。该测试可以在一对主机之间进行。但如果是在本地的一对进程之间运行，例如当使用 +msg_zerocopy.sh 脚本在跨命名空间的虚拟以太网（veth）对之间运行时，测试将不会显示出任何性能 +提升。为了便于测试，可以通过让 skb_orphan_frags_rx 与 skb_orphan_frags 相同，来暂时放宽 +环回限制。 + +对于 VSOCK 类型套接字的示例可以在 tools/testing/vsock/vsock_test_zerocopy.c 中找到。 diff --git a/Documentation/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst index 10536b74aeec..0e524f1c1af5 100644 --- a/Documentation/translations/zh_CN/process/submit-checklist.rst +++ b/Documentation/translations/zh_CN/process/submit-checklist.rst @@ -82,8 +82,8 @@ Linux内核补丁提交检查单 17) 所有新的模块参数都记录在 ``MODULE_PARM_DESC()`` 18) 所有新的用户空间接口都记录在 ``Documentation/ABI/`` 中。有关详细信息， - 请参阅 ``Documentation/ABI/README`` 。更改用户空间接口的补丁应该抄送 - linux-api@vger.kernel.org。 + 请参阅 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用户空间接口的补丁应该抄送 linux-api@vger.kernel.org\ 。 19) 已通过至少注入slab和page分配失败进行检查。请参阅 ``Documentation/fault-injection/`` 。 如果新代码是实质性的，那么添加子系统特定的故障注入可能是合适的。 diff --git a/Documentation/translations/zh_CN/security/credentials.rst b/Documentation/translations/zh_CN/security/credentials.rst new file mode 100644 index 000000000000..91c353dfb622 --- /dev/null +++ b/Documentation/translations/zh_CN/security/credentials.rst @@ -0,0 +1,479 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/credentials.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +============= +Linux中的凭据 +============= + +作者: David Howells <dhowells@redhat.com> + +.. contents:: :local: + +概述 +==== + +当一个对象对另一个对象进行操作时，Linux执行的安全检查包含几个部分： + + 1. 对象 + + 对象是可以直接由用户空间程序操作的系统中的实体。Linux具有多种可操作 + 的对象，包括： + + - 任务 + - 文件/索引节点 + - 套接字 + - 消息队列 + - 共享内存段 + - 信号量 + - 密钥 + + 所有这些对象的描述的一部分是一组凭据。集合中的内容取决于对象的类型。 + + 2. 对象所有权 + + 大多数对象的凭据中会有一个子集用来表示该对象的所有权。 + 这用于资源核算和限制（如磁盘配额和任务资源限制）。 + + 例如，在标准的UNIX文件系统中，这将由标记在索引节点上的UID定义。 + + 3. 对象上下文 + + 此外在这些对象的凭据中，将有一个子集表示对象的“对象上下文”。 + 这可能与（2）中相同，也可能不同 —— 例如，在标准的UNIX文件中， + 这是由标记在索引节点上的UID和GID定义的。 + + 对象上下文是进行安全计算的一部分，当对象被操作时会用到。 + + 4. 主体 + + 主体是正在对其他对象执行操作的对象。 + + 系统中的大多数对象是不活动的：他们不会对系统中的其他对象起作用。 + 进程/任务是明显的例外：它们可以访问和操纵其他对象。 + + 任务之外的其他对象在某些情况下也可以是主体。例如，打开的文件可以使用 + 名为 ``fcntl(F_SETOWN)`` 的任务给它的UID和EUID向一个任务发送SIGIO + 信号。在这种情况下，文件结构也会有一个主体上下文。 + + 5. 主体上下文 + + 主体对其凭据有一个额外的解释。其凭据的一个子集形成了“主体上下文”。主体 + 上下文在主体执行操作时作为安全计算的一部分使用。 + + 例如，Linux任务在操作文件时会有FSUID、FSGID和附加组列表 —— 这些凭据 + 与通常构成任务的对象上下文的真实UID和GID是相互独立的。 + + 6. 操作 + + Linux提供许多操作，主体可以对对象执行这些操作。可用的操作集取决于主体 + 和对象的性质。 + + + 操作包括读取、写入、创建和删除文件，以及派生（forking）或发送 + 信号（signalling）和跟踪（tracing）任务等。 + + 7. 规则，访问控制列表和安全计算 + + 当主体对对象进行操作时，会进行安全计算。这涉及到使用主体上下文、对象 + 上下文和操作，并搜索一个或多个规则集，以确定在给定这些上下文的情况下， + 主体是否被授予或拒绝以所需方式对对象进行操作的权限。 + + 主要有两个规则来源： + + a. 自主访问控制（DAC）： + + 有时，对象的描述中会包含一组规则。这就是所谓的“访问控制列表”或‘ACL’。 + 一个Linux文件可以提供多个ACL。 + + 例如，传统的UNIX文件包括一个权限掩码，它是一个简化的ACL，具有三个固定的 + 主体类别（“用户”、“组”和“其他”），每一个都可以被授予一定的特权（如“读取”、 + “写入”和“执行” —— 无论这些映射对于对象意味着什么）。然而，UNIX文件权限不 + 允许任意指定主体，因此用途有限。 + + Linux文件还可以支持POSIX ACL。这是一个规则列表，为任意主体授予各种权限。 + + b. 强制访问控制（MAC）： + + 整个系统可能有一个或多个规则集，适用于所有主体和对象，不考虑它们的来源。 + SELinux和Smack就是这种情况的例子。 + + 在SELinux和Smack的情况下，每个对象在其凭据中都被赋予一个标签。当请求执 + 行操作时，它们使用主体标签、对象标签和操作，寻找一个规则，该规则表示此操 + 作是授予还是拒绝的。 + + +凭据类型 +======== + +Linux内核支持以下类型的凭据： + + 1. 传统的UNIX凭据。 + + - 真实用户ID + - 真实组ID + + UID和GID由大多数（如果不是全部）Linux对象携带，即使有时它们需要被虚构出 + 来（例如FAT或CIFS文件，这些文件来源于Windows）。这些（通常）定义了该对象 + 的对象上下文，但任务在某些情况下略有不同。 + + - 有效用户ID，保存用户ID和FS用户ID + - 有效组ID，保存组ID和FS组ID + - 补充组 + + 这些是仅由任务使用的额外凭据。通常，一个EUID/EGID/GROUPS 被用作主体上下文， + 而真实UID/GID 被用作对象上下文。对于任务，这并不总是正确的。 + + 2. 能力 + + - 允许的能力集合 + - 可继承的能力集合 + - 有效的能力集合 + - 能力边界集合 + + 这些仅由任务携带，表示授予任务的超出普通任务权限的能力。这些可以通过传统 + UNIX凭据的更改进行隐式操作，但也可以通过 ``capset()`` 系统调用直接操作。 + + 允许的能力是指进程可以通过 ``capset()`` 将其添加到其有效或允许集合中的 + 那些能力。这个可继承的集合也可能受到这样的限制。 + + 有效能力是任务本身实际可以使用的能力。 + + 可继承能力是那些可以通过 ``execve()`` 传递的能力。 + + 边界集限制了通过 ``execve()`` 继承的能力，特别是在以UID 0执行二进制文件时。 + + 3. 安全管理标记（securebits） + + 它们用于控制上述凭据在特定操作如execve()中的操作和继承方式。它们并不直接 + 用作对象或主体凭据使用。 + + 4. 密钥和密钥环 + + 这些仅由任务携带。它们用于携带和缓存不适合放入其他标准UNIX凭据中的安全令牌。 + 它们用诸如使网络文件系统密钥在进程执行的文件访问时可用，而无需让普通程序了解 + 涉及的安全细节。 + + 密钥环是一种特殊类型的密钥。它们携带一组其他密钥，并可以搜索来查找所需的密钥。 + 每个进程可以订阅多个密钥环： + + 每线程密钥 + 每进程密钥环 + 每会话密钥环 + + 当进程访问一个密钥时，若尚不存在，则通常会将其缓存在一个密钥环中，以便将来的 + 访问时找到该密钥。 + + 有关密钥的更多信息，请参见 ``Documentation/translations/zh_CN/security/keys/*`` 。 + + 5. LSM + + Linux安全模块允许在任务执行操作时施加额外的控制。目前，Linux支持几种LSM选项。 + + 一些工作通过标记系统中的对象，并应用一组规则（策略）说明某个标签的任务可以对 + 另一标签的对象执行哪些操作。 + + 6. AF_KEY + + 这是一种基于套接字网络协议栈中的凭据管理[RFC 2367]。本文档中没有讨论它,因为不 + 直接与任务和文件凭据进行交互，而是保留了系统级的凭据。 + + +当打开一个文件时，打开任务的主体上下文的一部分会记录在创建的文件结构中。 +这使得使用该文件结构的操作可以使用这些凭据，而不是发出操作的任务的主体上下文。 +一个例子是在网络文件系统上打开的文件，打开文件的凭据应该被呈现给服务器，而不管 +实际进行读取或写入操作的是谁。 + + +文件标记 +======== + +存储在磁盘上或通过网络获取的文件可能具有注释，构成该文件的对象安全上下文。 +根据文件系统的类型，这些注释可能包括以下一项或多项： + + * UNIX UID, GID, mode; + * Windows user ID; + * Access control list; + * LSM security label; + * UNIX exec privilege escalation bits (SUID/SGID); + * File capabilities exec privilege escalation bits. + +将这些与任务的主体安全上下文进行比较，并根据比较结果允许或禁止执行某些操作。 +在execve()的情况下，特权提升位起作用，并且可能允许由可执行文件的注释决定的 +进程获得额外的特权。 + + +任务凭据 +======== + +在Linux中，一个任务的所有凭据都保存在一个引用计数结构体‘struct cred’中， +通过(uid, gid)或(groups, keys, LSM security)进行访问。每个任务在其 +task_struct中通过一个名为‘cred’的指针指向其凭据。 + +一旦一组凭据已经准备好并提交，除非以下几种情况，否则不能更改： + + 1. 其引用计数可以更改； + + 2. 它所指向的 group_info 结构体的引用计数可以更改； + + 3. 它所指向的安全数据的引用计数可以更改； + + 4. 它所指向的任何密钥环的引用计数可以更改； + + 5. 它所指向的任何密钥环可以被撤销、过期或其安全属性可以更改； + + 6. 它所指向的任何密钥环的内容可以更改（密钥环的整个目的就是作为一组共享凭据， + 可由具有适当访问权限的任何人修改）。 + +要更改cred结构体中的任何内容，必须遵循复制和替换的原则。首先进行复制，然后修 +改副本，最后使用RCU（读-复制-更新）将任务指针更改为指向新的副本。有一些封装可 +用于帮助执行这个过程（见下文）。 + +一个任务只能修改自己的凭据；不再允许一个任务修改另一个任务的凭据。 +这意味着 ``capset()`` 系统调用不再允许使用除当前进程之外的任何PID。 +此外， ``keyctl_instantiate()`` 和 ``keyctl_negate()`` 函数也不再 +允许在请求进程中附加到特定于进程的密钥环，因为实例化进程可能需要创建它们。 + + +不可变凭据 +---------- + +一旦一组凭据已经被公开（例如通过调用 ``commit_creds()`` ），必须将其视为 +不可变的,除了两个例外情况： + + 1. 引用计数可以被修改。 + + 2. 虽然无法更改一组凭据的密钥环订阅，但订阅的密钥环的内容可以被更改。 + +为了在编译时捕获意外的凭据修改，struct task_struct具有_const_指针指向其凭据集， +struct file也是如此。此外，某些函数如 ``get_cred()`` 和 ``put_cred()`` 在 +const指针上操作，因此不需要进行类型转换，但需要临时放弃const限定，以便能够修改 +引用计数。 + + +访问任务凭据 +------------ + +任务只能修改自己的凭据，允许当前进程可以读取或替换自己的凭据，无需任何形式锁定的 +情况下 —— 这极大简化了事情。它可以调用:: + + const struct cred *current_cred() + +获取指向其凭据结构的指针，并且之后不必释放它。 + +有一些方便的封装用于检索任务凭据的特定方面（在每种情况下都只返回值）:: + + uid_t current_uid(void) Current's real UID + gid_t current_gid(void) Current's real GID + uid_t current_euid(void) Current's effective UID + gid_t current_egid(void) Current's effective GID + uid_t current_fsuid(void) Current's file access UID + gid_t current_fsgid(void) Current's file access GID + kernel_cap_t current_cap(void) Current's effective capabilities + struct user_struct *current_user(void) Current's user account + +还有一些方便的封装，用于检索任务凭据的特定关联对:: + + void current_uid_gid(uid_t *, gid_t *); + void current_euid_egid(uid_t *, gid_t *); + void current_fsuid_fsgid(uid_t *, gid_t *); + +在从当前任务的凭据中检索后，通过其参数返回这些值对。 + + +此外，还有一个函数用于获取当前进程的当前凭据集的引用:: + + const struct cred *get_current_cred(void); + +以及用于获取对一个实际上不存在于struct cred中的凭据的引用的函数:: + + struct user_struct *get_current_user(void); + struct group_info *get_current_groups(void); + +分别获得对当前进程的 user accounting structure 和补充组列表的引用。 + +一旦获得引用，就必须使用 ``put_cred（）``, ``free_uid（）`` 或 +``put_group_info（）`` 来适当释放它。 + + +访问其他任务的凭据 +------------------ + +虽然一个任务可以在不需要锁定的情况下访问自己的凭据，但想要访问另一个任务 +的凭据的任务并非如此。它必须使用RCU读锁和 ``rcu_dereference（）``。 + +``rcu_dereference()`` 是由:: + + const struct cred *__task_cred(struct task_struct *task); + +这应该在RCU读锁中使用，如下例所示:: + + void foo(struct task_struct *t, struct foo_data *f) + { + const struct cred *tcred; + ... + rcu_read_lock(); + tcred = __task_cred(t); + f->uid = tcred->uid; + f->gid = tcred->gid; + f->groups = get_group_info(tcred->groups); + rcu_read_unlock(); + ... + } + +如果需要长时间持有另一个任务的凭据，并且可能在此过程中休眠，则调用方 +应该使用以下函数来获取对这些凭据的引用:: + + const struct cred *get_task_cred(struct task_struct *task); + +这个函数内部完成了所有的RCU操作。当使用完这些凭据时，调用方必须调用put_cred() +函数释放它们。 + +.. note:: + ``__task_cred()`` 的结果不应直接传递给 ``get_cred()`` ， + 因为这可能与 ``commit_cred()`` 发生竞争条件。 + +还有一些方便的函数可以访问另一个任务凭据的特定部分，将RCU操作对调用方隐藏起来:: + + uid_t task_uid(task) Task's real UID + uid_t task_euid(task) Task's effective UID + +如果调用方在此时已经持有RCU读锁，则应使用:: + + __task_cred(task)->uid + __task_cred(task)->euid + +类似地，如果需要访问任务凭据的多个方面，应使用RCU读锁，调用 ``__task_cred()`` +函数，将结果存储在临时指针中，然后从临时指针中调用凭据的各个方面，最后释放锁。 +这样可以防止多次调用昂贵的RCU操作。 + +如果需要访问另一个任务凭据的其他单个方面，可以使用:: + + task_cred_xxx(task, member) + +这里的‘member’是cred结构体的非指针成员。例如:: + + uid_t task_cred_xxx(task, suid); + +将从任务中检索‘struct cred::suid’，并执行适当的RCU操作。对于指针成员， +不能使用这种形式，因为它们指向的内容可能在释放RCU读锁的瞬间消失。 + + +修改凭据 +-------- + +如先前提到的，一个任务只能修改自己的凭据，不能修改其他任务的凭据。这意味 +着它不需要使用任何锁来修改自己的凭据。 + +要修改当前进程的凭据，函数应首先调用:: + + struct cred *prepare_creds(void); + +这将锁定current->cred_replace_mutex，然后分配并构建当前进程凭据的副本。 +如果成功，函数返回时仍然保持互斥锁。如果不成功（内存不足），则返回NULL。 + +互斥锁防止 ``ptrace()`` 在进行凭据构建和更改的安全检查时更改进程的ptrace +状态，因为ptrace状态可能会改变结果，特别是在 ``execve()`` 的情况下。 + +新的凭据集应适当地进行修改，并进行任何安全检查和挂钩。在此时，当前和建议的 +凭据集都可用，因为current_cred()将返回当前的凭据集。 + +在替换组列表时，必须在将其添加到凭据之前对新列表进行排序，因为使用二分查找 +测试成员资格。实际上，这意味着在set_groups()或set_current_groups()之 +前应调用groups_sort()。groups_sort()不能在共享的 ``struct group_list`` +上调用，因为即使数组已经排序，它也可能作为排序过程的一部分对元素进行排列。 + +当凭据集准备好时，应通过调用以下函数将其提交给当前进程:: + + int commit_creds(struct cred *new); + +这将修改凭据和进程的各个方面，给LSM提供机会做同样的修改，然后使用 +``rcu_assign_pointer()`` 将新的凭据实际提交给 ``current->cred`` ， +释放 ``current->cred_replace_mutex`` 以允许 ``ptrace()`` 进行操 +作，并通知调度程序和其他组件有关更改的情况。 + +该函数保证返回0，以便可以在诸如 ``sys_setresuid()`` 函数的末尾进行尾调用。 + +请注意，该函数会消耗调用者对新凭据的引用。调用者在此之后不应调用 +``put_cred()`` 释放新凭据。 + +此外，一旦新的凭据上调用了该函数，就不能进一步更改这些凭据。 + + +如果在调用 ``prepare_creds()`` 之后安全检查失败或发生其他错误， +则应调用以下函数:: + + void abort_creds(struct cred *new); + +这将释放 ``prepare_creds()`` 获取的 ``current->cred_replace_mutex`` 的锁， +并释放新的凭据。 + +一个典型的凭据修改函数看起来像这样:: + + int alter_suid(uid_t suid) + { + struct cred *new; + int ret; + + new = prepare_creds(); + if (!new) + return -ENOMEM; + + new->suid = suid; + ret = security_alter_suid(new); + if (ret < 0) { + abort_creds(new); + return ret; + } + + return commit_creds(new); + } + + +管理凭据 +-------- + +有一些函数用来辅助凭据管理: + + - ``void put_cred(const struct cred *cred);`` + + 这将释放对给定凭据集的引用。如果引用计数为零，凭据集将由 + RCU系统安排进行销毁。 + + - ``const struct cred *get_cred(const struct cred *cred);`` + + 这将获取对活动凭据集的引用。返回指向凭据集的指针。 + + - ``struct cred *get_new_cred(struct cred *cred);`` + + 这将获取对当前正在构建且可变的凭据集的引用。返回指向凭据集的指针。 + +打开文件凭据 +============ + +当打开新文件时，会获取对打开任务凭据的引用，并将其附加到文件结构体的 +``f_cred`` 字段中，替代原来的 ``f_uid`` 和 ``f_gid`` 。原来访问 +``file->f_uid`` 和 ``file->f_gid`` 的代码现在应访问 ``file->f_cred->fsuid`` +和 ``file->f_cred->fsgid`` 。 + +安全访问 ``f_cred`` 的情况下可以不使用RCU或加锁，因为指向凭据的指针 +以及指向的凭据结构的内容在文件结构的整个生命周期中保持不变，除非是 +上述列出的例外情况（参阅任务凭据部分）。 + +为了避免“混淆代理”权限提升攻击，在打开的文件后续操作时，访问控制检查 +应该使用这些凭据，而不是使用“当前”的凭据，因为该文件可能已经被传递给 +一个更具特权的进程。 + +覆盖VFS对凭据的使用 +=================== + +在某些情况下，需要覆盖VFS使用的凭据，可以通过使用不同的凭据集调用 +如 ``vfs_mkdir()`` 来实现。以下是一些进行此操作的位置: + + * ``sys_faccessat()``. + * ``do_coredump()``. + * nfs4recover.c. diff --git a/Documentation/translations/zh_CN/security/index.rst b/Documentation/translations/zh_CN/security/index.rst index d8aacd1930d9..78d9d4b36dca 100644 --- a/Documentation/translations/zh_CN/security/index.rst +++ b/Documentation/translations/zh_CN/security/index.rst @@ -15,20 +15,20 @@ .. toctree:: :maxdepth: 1 + credentials + snp-tdx-threat-model lsm sak + self-protection siphash + tpm/index digsig landlock TODOLIST: -* credentials -* snp-tdx-threat-model * IMA-templates * keys/index * lsm-development * SCTP -* self-protection -* tpm/index * secrets/index * ipe diff --git a/Documentation/translations/zh_CN/security/keys/index.rst b/Documentation/translations/zh_CN/security/keys/index.rst new file mode 100644 index 000000000000..7c28d003fb0a --- /dev/null +++ b/Documentation/translations/zh_CN/security/keys/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/keys/index.rst + +:翻译: + + +======== +内核密钥 +======== + +.. toctree:: + :maxdepth: 1 + + +TODOLIST: +* core +* ecryptfs +* request-key +* trusted-encrypted diff --git a/Documentation/translations/zh_CN/security/secrets/index.rst b/Documentation/translations/zh_CN/security/secrets/index.rst new file mode 100644 index 000000000000..5ea78713f10e --- /dev/null +++ b/Documentation/translations/zh_CN/security/secrets/index.rst @@ -0,0 +1,17 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/secrets/index.rst + +:翻译: + +===================== +密钥文档 +===================== + +.. toctree:: + + +TODOLIST: + +* coco diff --git a/Documentation/translations/zh_CN/security/self-protection.rst b/Documentation/translations/zh_CN/security/self-protection.rst new file mode 100644 index 000000000000..3c8a68b1e1be --- /dev/null +++ b/Documentation/translations/zh_CN/security/self-protection.rst @@ -0,0 +1,271 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst +:Original: Documentation/security/self-protection.rst + +:翻译: + + 张巍 zhangwei <zhangwei@cqsoftware.com.cn> + +============ +内核自我保护 +============ + +内核自我保护是指在Linux内核中设计与实现的各种系统与结构 +以防止内核本身的安全漏洞问题。它涵盖了广泛问题，包括去除 +整个类的漏洞，阻止安全漏洞利用方法，以及主动检测攻击尝 +试。并非所有的话题都在本文中涉及，但它应该为了解内核自我 +保护提供一个合理的起点，并解答常见的问题。（当然，欢迎提 +交补丁！） + +在最坏的情况下，我们假设一个非特权的本地攻击者对内核内存 +有任意读写访问权限。虽然在许多情况下，漏洞被利用时并不会 +提供此级别的访问权限，但如果我们能防御最坏情况，也能应对 +权限较低的攻击。一个更高的标准，且需要牢记的是保护内核免 +受具有特权的本地攻击者的攻击，因为root用户可以有更多权限。 +（尤其是当他们能够加载任意内核模块时） + +成功的自我保护的目标是：有效、默认开启、不需要开发者主动 +选择、没有性能影响、不妨碍内核调试、并且没有测试。虽然很 +难满足所有的这些目标，但明确提到这些目标非常重要，因为这 +些方面需要被探索、解决或接受。 + +========== +攻击面缩减 +========== + +防止安全漏洞最基本的防御方式是减少可以被用来重定向执行的 +内核区域。这包括限制用户公开使用的API、使内核API更难被错 +误使用、最小化可写内核内存区域等。 + +严格的内核内存权限 +------------------- + +当所有内核内存都是可写的，攻击者可以轻松地重定向执行流。 +为了减少这种攻击目标的可用性，内核需要更严格的权限集来 +保护其内存。 + +可执行代码和只读数据必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +任何具有可执行内存的区域必须不可写，显然这也包括内核文本 +本身。我们还必须考虑其他地方：内核模块、JIT内存等，（在 +某些情况下，为了支持像指令替代、断点、kprobes等功能，这些 +区域会暂时被设置为可写。如果这些功能必须存在于内核中，它 +们的实现方式是：在更新期间将内存临时设置可写，然后再恢复 +为原始权限。） + +为了支持这一点，CONFIG_STRICT_KERNEL_RWX 和 +CONFIG_STRICT_MODULE_RWX 的设计旨在确保代码不可写，数据不 +可执行，以及只读数据既不可写也不可执行。 + +大多数架构默认支持这些选项，且用户无法选择。对于一些像arm +这种希望能够选择这些选项的架构，可以在架构Kconfig中选择 +ARCH_OPTIONAL_KERNEL_RWX以启用Kconfig提示。 +CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT决定在启用 +ARCH_OPTIONAL_KERNEL_RWX时的默认设置。 + +函数指针和敏感变量必须不可写 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核内存中有大量的函数指针，这些指针被内核查找并用于继续执行 +（例如，描述符/向量表、文件/网络等操作结构等）。这些变量的数 +量必须减少到最低限度 + +许多像这样的变量可以通过设置为"const"来实现只读，从而使它们 +存放在内核的.rodata段而非.data段，从而获得内核严格内存权限的 +保护。 + +对于在_init是仅初始化一次的变量，可以使用_ro_after_init属性 +进行标记。 + +剩下的变量通常是那些更新频率较低的（例如GDT）。这些变量需要另 +一个机制（类似于上述提到的对内核代码所做的临时例外），以便在 +其余生命周期内保持只读状态。（例如，在进行更新时，只有执行 +更新的CPU线程会被授予对内存的不可中断写入访问权限。） + +将内核内存与用户空间内存分隔开 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +内核绝对不可以执行用户空间内存，同时，内核也不得在没有明确预 +期的情况下访问用户内存空间。这些规则可以通过一些硬件限制来支 +持（如x86的SMEP/SMAP，ARM的PXN/PAN）或通过仿真（如ARM的内存 +域）来强制执行。通过这种方式阻止用户空间内存的访问，攻击者就 +无法将执行和数据解析转移到易于控制的用户空间内存，从而迫使攻 +击完全在内核中进行。 + +减少对系统调用的访问 +-------------------- + +对于64位系统，一种消除许多系统调用最简单的方法是构建时不启用 +CONFIG_CONPAT。然而，这种情况通常不可行。 + +“seccomp”系统为用户空间提供了一种可选功能，提供了一种减少可供 +运行中进程使用内核入口点数量的方法。这限制了可以访问内核代码 +的范围，可能降低了某个特定漏洞被攻击者利用的可能性。 + +一个改进的方向是创建有效的方法，仅允许受信任的进程访问例如兼 +容模式、用户命名空间、BPF创建和性能分析等功能。这将把内核入口 +点范围限制在通常可以被非特权用户空间进程访问的较常见集合中 + +限制对内核模块的访问 +-------------------- + +内核绝不应允许非特权用户加载特定的内核模块，因为这可能为攻击者 +提供一个意外扩展的可用攻击面的方法。（通过已预定义子系统按需加 +载模块，如MODULE_ALIAS_*，被认为是“预期的”，但即便如此，也应对 +这些情况给予更多的关注。）例如，通过非特权的套接字API加载文件 +系统模块是没有意义的：只有root用户或物理本地用户应该触发文件系 +统模块的加载。（在某些情况下，这甚至可能存在争议。） + +为了防止特权用户的攻击，系统可能需要完全禁止模块加载（例如，通 +过单体内核构建或modules_disabled sysctl），或者使用签名模块（例 +如，CONFIG_MODULE_SIG_FORCE或通过LoadPin保护的dm-crypt），以防 +止root用户通过模块加载器加载任意内核代码。 + +内存完整性 +---------- + +内核中有许多内存结构在攻击过程中被定期泛滥用以获取执行控制，迄今 +为止，最常见的是堆栈缓冲区溢出，在这种攻击中，堆栈上存储的返回地 +址被覆盖。除此之外，还有许多其他类型的攻击，防护措施也应运而生。 + +堆栈缓冲区溢出 +-------------- + +经典的堆栈缓冲区溢出攻击是指超出栈上分配的变量预期大小，从而将一 +个受控值写入栈帧的返回地址。最常见的防御措施是堆栈保护 +（CONFIG_STACKPROTECTOR），它在函数返回前会验证栈上的“stack canary”。 +其他防御措施还包括影子堆栈等。 + +堆栈深度溢出 +------------ + +一个不太容易被理解的攻击方式是利用bug触发内核通过深度函数调用或 +大的堆栈分配来消耗堆栈内存。通过这种攻击，攻击者可以将数据写入内 +核预分配堆栈空间之外的敏感结构。为了更好的防护这种攻击，必须进行 +两项重要的更改：将敏感的线程信息结构转移到其他地方，并在堆栈底部 +添加一个故障内存洞，以捕获这些溢出 + +栈内存完整性 +------------ + +用于跟踪堆空闲列表的结构可以在分配和释放时进行完整性检查，以确保它 +们不会被用来操作其它内存区域。 + +计算器完整性 +------------ + +内核中的许多地方使用原子计数器来跟踪对象引用或执行类似的生命周期管 +理。当这些计数器可能发生溢出时（无论是上溢还是下溢），这通常会暴露 +出使用后释放（use-after-free）漏洞。通过捕捉原子计数器溢出，这类漏 +洞就可以消失。 + +大小计算溢出检测 +---------------- + +与计算器溢出类似，整数溢出（通常是大小计算）需要在运行时进行检测， +以防止这类在传统上会导致能够写入内核缓冲区末尾之外的漏洞。 + +概率性防御 +---------- + +尽管许多防御措施可以被认定是确定的（例如，只读内存不能写入），但 +有些确保措施仅提供统计防御，即攻击者必须收集足够的关于运行系统的 +信息才能突破防御。尽管这些防御并不完美，但它们确实提供了有意义的 +保护。 + +栈保护、迷惑技术和其他秘密 +-------------------------- + +值得注意的是，像之前讨论的栈保护这样的技术，从技术上来说是统计性防 +御，因为它们依赖于一个秘密值，而这样的值可能会通过信息泄露漏洞而被 +发现。 + +对于想JIT（及时翻译器）这样的情况，其中可执行内容可能部分由用户空间 +控制，也需要类似的秘密之来迷惑。 + +至关重要的是，所使用的秘密值必须是独立的（例如，每个栈使用不同的栈 +保护值），并且具有高熵（例如，随机数生成器（RNG）是否正常工作？）， +以最大限度地提高其成功率。 + +内核地址空间布局随机化（KASLR） +------------------------------- + +由于内核内存的位置几乎总是攻击成功的关键因素，因此使内核内存位置变 +得非确定性会增加攻击的难度。（请注意，这反过来提高了信息泄露的价 +值，因为泄露的信息可以用来发现目标内存位置。） + +文本和模块基址 +-------------- + +通过在启动时重新设定内核的物理基地址和虚拟基地址 +（CONFIG_RANDOMIZE_BASE）,那些需要利用内核代码的攻击将会受阻。此外 +通过偏移模块加载基地址，意味着即使系统每次启动时按相同顺序加载同一 +组模块，这些模块也不会与内核文本的其余部分公用一个基地址。 + +堆栈基地址 +---------- + +如果进程之间内核堆栈的基地址不相同，甚至在不同系统调用之间也不相同， +那么栈上或超出栈的目标位置就会变得更加难以确定。 + +动态内存基址 +------------ + +很多内核的动态内存（例如kmalloc，vmalloc等）由于早期启动初始化的顺 +序，最终布局是相对确定的。如果这些区域的基地址在启动之间不相同，攻 +击者就无法轻易定位它们，必须依赖于针对该区域的信息泄露才能成功。 + +结构布局 +-------- + +通过在每次构建时对敏感结构的布局进行随机化处理，攻击这必须将攻击调 +节到已知的内核版本，或者泄露足够的内核内存来确定结构布局，然后才能 +对其进行操作。 + +防止信息泄露 +------------ + +由于敏感结构的位置是攻击的主要目标，因此防止内核内存地址和内核内存 +内容泄露非常重要（因为它们可能包含内核地址或者其他敏感数据，例如 +栈保护值）。 + +内核地址 +-------- + +将内核地址打印到用户空间会泄露有关内核内存布局的敏感信息。在使用任 +何打印符号打印原始地址时，目前%px,%p[ad]（和在某些情况下的%p[sSb]） +时。使用这些格式符写入的文件需要限制为只有特权进程可读。 + +在4.14及以前的内核版本中，使用%p格式符打印的是原始地址。从4.15-rcl +版本开始，使用%p格式符打印的地址会在打印前进行哈希处理。 + +[*]如果启用KALLSYMS并且符号查找失败，则打印原始地址；如果没有启用 +KALLSYSM，则会直接打印原始地址。 + +唯一标识符 +---------- + +内核内存地址绝不可能用作向用户空间公开的标识符。相反，应该使用原子 +计数器，IDR（ID映射表）或类似的唯一标识符。 + +内存初始化 +---------- + +复制到用户空间的内存必须始终被完全初始化，如果没有显式地使用memset() +函数进行初始化，那就需要修改编译器，确保清除结构中的空洞。 + +内存清除 +-------- + +在释放内存时，最好对内存内容进行清除处理，以防止攻击者重用内存中以前 +的内容。例如，在系统调用返回时清除堆栈（CONFIG_GCC_PLUGIN_STACKLEAK）, +在释放堆内容是清除其内容。这有助于防止许多未初始化变量攻击、堆栈内容 +泄露、堆内容泄露以及使用后释放攻击（user-after-free）。 + +目标追踪 +-------- + +为了帮助消除导致内核地址被写入用户空间的各种错误，需要跟踪写入的目标。 +如果缓冲区的目标是用户空间（例如，基于seq_file的/proc文件），则应该自 +动审查敏感值。 diff --git a/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst new file mode 100644 index 000000000000..b51eeaebab67 --- /dev/null +++ b/Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst @@ -0,0 +1,209 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/security/snp-tdx-threat-model.rst + +:翻译: + + 毛玉贤 Yuxian Mao <maoyuxian@cqsoftware.com.cn> + +========================== +Linux中x86虚拟化的机密计算 +========================== + +.. contents:: :local: + +By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> + +动机 +==== + +在x86虚拟环境中从事机密计算工作的内核开发人员，是基于一组与传统Linux内核 +威胁模型有所不同的假设条件下开展工作的。传统意义上，Linux威胁模型承认攻 +击者可以存在于用户空间，以及一小部分能够通过各种网络接口或有限的硬件特定 +暴露接口（如USB、Thunderbolt）与内核交互的外部攻击者。本文档的目的是解释 +在机密计算领域中出现的额外攻击向量，并讨论为 Linux 内核提出的保护机制。 + +概述与术语 +========== + +机密计算（Confidential Computing，简称CoCo）是一个广泛的术语，涵盖了多种 +旨在保护数据在使用过程中（与静态数据或传输数据相比）的机密性和完整性的安 +全技术。从本质上讲，机密计算（CoCo）解决方案提供了一个受信任执行环境（TEE）， +在该环境中可以进行安全的数据处理，因此，它们通常根据预期在TEE中运行的软件 +来进一步划分为不同的子类型。本文档专注于一类针对虚拟化环境的机密计算技术 +（Confidential Computing, CoCo），这些技术允许在可信执行环境 +（Trusted Execution Environment, TEE）中运行虚拟机（VM）。从现在起，本文档 +将把这一类机密计算（CoCo）技术称为“虚拟化环境（VE）中的机密计算（CoCo）”。 + +在虚拟化环境中，机密计算（CoCo）指的是一组硬件和/或软件技术，这些技术能够 +为在CoCo虚拟机（VM）内运行的软件提供更强的安全保障。具体来说，机密计算允许 +其用户确认所有软件组件的可信度，从而将其包含在精简的受信任计算基（TCB）中， +这是基于机密计算具备验证这些受信组件状态的能力。 + +虽然不同技术之间的具体实现细节有所不同，但所有现有机制都旨在为虚拟机的客户 +内存和执行状态（vCPU寄存器）提供更高的机密性和完整性，更严格地控制客户中断 +注入，并提供一些额外机制来控制客户与宿主机之间的页映射。有关x86特定解决方案 +的更多细节，可以参考 +:doc:`Intel Trust Domain Extensions (TDX) </arch/x86/tdx>` 和 +`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_. + +基本的机密计算（CoCo）客户布局包括宿主机、客户机、用于客户机与宿主机之间通信 +的接口、能够支持CoCo虚拟机（VM）的平台，以及一个在客户VM和底层平台之间充当安 +全管理员的可信中介。宿主机侧的虚拟机监视器（VMM）通常由传统VMM功能的一个子集 +组成，并仍然负责客户机生命周期的管理，即创建或销毁CoCo虚拟机、管理其对系统资 +源的访问等。然而，由于它通常不在CoCo VM的可信计算基（TCB）内，其访问权限受到 +限制，以确保实现安全目标。 + +在下图中，"<--->" 线表示机密计算（CoCo）安全管理员与其余组件之间的双向通信通 +道或接口，这些组件包括客户机、宿主机和硬件（数据流）:: + + +-------------------+ +-----------------------+ + | CoCo guest VM |<---->| | + +-------------------+ | | + | Interfaces | | CoCo security manager | + +-------------------+ | | + | Host VMM |<---->| | + +-------------------+ | | + | | + +--------------------+ | | + | CoCo platform |<--->| | + +--------------------+ +-----------------------+ + +机密计算（CoCo）安全管理器的具体细节在在不同技术之间存在显著差异。例如，在某 +些情况下，它可能通过硬件（HW）实现，而在其他情况下，它可能是纯软件（SW）实现。 + +现有的Linux内核威胁模型 +======================= + +当前Linux内核威胁模型的总体组件包括:: + + +-----------------------+ +-------------------+ + | |<---->| Userspace | + | | +-------------------+ + | External attack | | Interfaces | + | vectors | +-------------------+ + | |<---->| Linux Kernel | + | | +-------------------+ + +-----------------------+ +-------------------+ + | Bootloader/BIOS | + +-------------------+ + +-------------------+ + | HW platform | + +-------------------+ + +在启动过程中，引导加载程序（bootloader）和内核之间也存在通信，但本图并未明确 +表示这一点。“接口”框表示允许内核与用户空间之间通信的各种接口。 这包括系统调用、 +内核 API、设备驱动程序等。 + +现有的 Linux 内核威胁模型通常假设其在一个受信任的硬件平台上执行，并且所有固件 +和启动加载程序都包含在该平台的受信任计算基（TCB）中。主要攻击者驻留在用户空间 +中，来自用户空间的所有数据通常被认为是不可信的，除非用户空间具有足够的特权来 +执行受信任的操作。此外，通常还会考虑外部攻击者，包括那些能够访问启用的外部网络 +（例如以太网、无线网络、蓝牙）、暴露的硬件接口（例如 USB、Thunderbolt），以及 +能够离线修改磁盘内容的攻击者。 + +关于外部攻击途径，值得注意的是，在大多数情况下，外部攻击者会首先尝试利用用户空 +间的漏洞，但攻击者也可能直接针对内核，特别是在宿主机具有物理访问权限的情况下。直 +接攻击内核的例子包括漏洞 CVE-2019-19524、CVE-2022-0435 和 CVE-2020-24490。 + +机密计算威胁模型及其安全目标 +============================ + +机密计算在上述攻击者列表中增加了一种新的攻击者类型：可能存在行为不当的宿主机 +（这可能包括传统虚拟机监视器VMM的部分组件或全部），由于其较大的软件攻击面， +通常被置于CoCo VM TCB之外。需要注意的是，这并不意味着宿主机或VMM是故意恶意的， +而是强调拥有一个较小的CoCo VM TCB具有安全价值。这种新型的攻击者可以被视为一种 +更强大的外部攻击者，因为它位于同一物理机器上（与远程网络攻击者不同），并且对 +客户机内核与大部分硬件的通信具有控制权:: + + +------------------------+ + | CoCo guest VM | + +-----------------------+ | +-------------------+ | + | |<--->| | Userspace | | + | | | +-------------------+ | + | External attack | | | Interfaces | | + | vectors | | +-------------------+ | + | |<--->| | Linux Kernel | | + | | | +-------------------+ | + +-----------------------+ | +-------------------+ | + | | Bootloader/BIOS | | + +-----------------------+ | +-------------------+ | + | |<--->+------------------------+ + | | | Interfaces | + | | +------------------------+ + | CoCo security |<--->| Host/Host-side VMM | + | manager | +------------------------+ + | | +------------------------+ + | |<--->| CoCo platform | + +-----------------------+ +------------------------+ + +传统上，宿主机对客户机数据拥有无限访问权限，并可以利用这种访问权限来攻击客户虚 +拟机。然而，机密计算（CoCo）系统通过添加诸如客户数据保密性和完整性保护等安全 +特性来缓解此类攻击。该威胁模型假设这些安全特性是可用且完好的。 + +这个 **Linux内核机密计算虚拟机（CoCo VM）的安全目标** 可以总结如下： + +1. 保护CoCo客户机私有内存和寄存器的机密性和完整性。 + +2. 防止宿主机特权升级到CoCo客户机Linux内核。虽然宿主机（及主机端虚拟机管理程序） + 确实需要一定的特权来创建、销毁或暂停访客，但防止特权升级的部分目标是确保这些 + 操作不会为攻击者提供获取客户机内核访问权限的途径。 + +上述安全目标导致了两个主要的**Linux内核机密计算虚拟机（CoCo VM）资产**： + +1. 客户机内核执行上下文。 +2. 客户机内核私有内存。 + +宿主机对CoCo客户机资源具有完全控制权，并可以随时拒绝访问这些资源。资源的示例包 +括CPU时间、客户机可以消耗的内存、网络带宽等。因此，宿主机对CoCo客户机的拒绝服务 +（DoS）攻击超出了此威胁模型的范围。 + +Linux CoCo虚拟机攻击面是指从CoCo客户机Linux内核暴露到不受信任的主机的任何接口， +这些接口未被CoCo技术的软硬件保护所覆盖。这包括所有可能的侧信道攻击以及瞬态执 +行侧信道攻击。显式（非旁道）接口的示例包括访问端口I/O、内存映射I/O（MMIO）和 +直接内存访问（DMA）接口、访问PCI配置空间、特定于虚拟机管理程序（VMM）的超调用 +（指向主机端VMM）、访问共享内存页、主机允许注入到访客内核的中断，以及特定于 +CoCo技术的超调用（如果存在）。此外，在CoCo系统中，宿主机通常控制创建CoCo客户机 +的过程：它有方法将固件和引导程序镜像、内核镜像以及内核命令行加载到客户机中。所有 +这些数据在通过证明机制确认其完整性和真实性之前，都应视为不可信的。 + +下表显示了针对CoCo客户机Linux内核的威胁矩阵，但并未讨论潜在的缓解策略。该矩阵涉 +及的是CoCo特定版本的客户机、宿主机和平台。 + +.. list-table:: CoCo Linux客户机内核威胁矩阵 + :widths: auto + :align: center + :header-rows: 1 + + * - 威胁名称 + - 威胁描述 + + * - 客户机恶意配置 + - 一个行为不当的主机修改了以下其中一个客户机的配置： + + 1. 客户机固件或引导加载程序 + + 2. 客户机内核或模块二进制文件 + + 3. 客户机命令行参数 + + 这使得宿主机能够破坏在CoCo客户虚拟机内部运行代码的完整性，从而违反了机密计算 + （CoCo）的安全目标。 + + * - CoCo客户机数据攻击 + - 一个行为不当的宿主机对CoCo客户虚拟机与宿主机管理的物理或虚拟设备之间传输的数 + 据拥有完全控制权。这使得宿主机可以对这类数据的保密性、完整性和新鲜性进行任何攻击。 + + * - 格式错误的运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入格式错误的输入。 + 如果代码没有正确处理这些输入，这可能导致从宿主机到客户机内核的特权提升。这包 + 括传统的侧信道攻击和/或瞬态执行攻击路径。 + + * - 恶意运行时输入 + - 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入特定的输入值。与之前 + 的攻击向量（格式错误的运行时输入）不同，这个输入并非格式错误，而是其值被精心设 + 计以影响客户机内核的安全性。这类输入的例子包括向客户机提供恶意的时间或向客户机 + 的随机数生成器提供熵值。此外，如果它导致客户机内核执行特定操作（例如处理主机注 + 入的中断），此类事件的时序本身也可能成为一种攻击路径。这种攻击是对提供的宿主机输 + 入具有抵抗性的一种方式。 diff --git a/Documentation/translations/zh_CN/security/tpm/index.rst b/Documentation/translations/zh_CN/security/tpm/index.rst new file mode 100644 index 000000000000..707646590647 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/index.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +可信平台模块文档 +================ + +.. toctree:: + + tpm_event_log + tpm-security + tpm_tis + tpm_vtpm_proxy + xen-tpmfront + tpm_ftpm_tee diff --git a/Documentation/translations/zh_CN/security/tpm/tpm-security.rst b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst new file mode 100644 index 000000000000..26818d28c98f --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm-security.rst @@ -0,0 +1,151 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm-security.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM安全 +======= + +本文档的目的是描述我们如何使内核使用TPM在面对外部窥探和数据包篡改 +攻击（文献中称为被动和主动中间人攻击）时保持合理的稳健性。当前的 +安全文档适用于TPM2.0。 + +介绍 +---- + +TPM通常是一个通过某种低带宽总线连接到PC的独立芯片。虽然有一些 +例外，例如Intel PTT，它是运行在靠近CPU的软件环境中的软件TPM， +容易受到不同类型的攻击，但目前大多数强化的安全环境要求使用独立 +硬件TPM，这是本文讨论的使用场景。 + +总线上的窥探和篡改攻击 +---------------------- + +当前的技术状态允许使用 `TPM Genie`_ 硬件中间人，这是一种简单的外部设备，可以在 +任何系统或笔记本电脑上几秒钟内安装。最近成功演示了针对 `Windows Bitlocker TPM`_ +系统的攻击。最近同样的攻击针对 `基于TPM的Linux磁盘加密`_ 方案也遭到了同样的攻击。 +下一阶段的研究似乎是入侵总线上现有的设备以充当中间人，因此攻击者需要物理访问几 +秒钟的要求可能不再存在。然而，本文档的目标是尽可能在这种环境下保护TPM的机密性和 +完整性，并尝试确保即使我们不能防止攻击，至少可以检测到它。 + +不幸的是，大多数TPM功能，包括硬件重置功能，都能被能够访问总线的攻击 +者控制，因此下面我们将讨论一些可能出现的干扰情况。 + +测量（PCR）完整性 +----------------- + +由于攻击者可以向TPM发送自己的命令，他们可以发送任意的PCR扩展，从而破 +坏测量系统，这将是一种烦人的拒绝服务攻击。然而，针对密封到信任测量中 +的实体，有两类更严重的攻击。 + +1. 攻击者可以拦截来自系统的所有PCR扩展，并完全替换为自己的值，产生 + 一个未篡改状态的重现，这会使PCR测量证明状态是可信的，并释放密钥。 + +2. 攻击者可能会在某个时刻重置TPM，清除PCR，然后发送自己的测量，从而 + 有效地覆盖TPM已经完成的启动时间测量。 + +第一种攻击可以通过始终对PCR扩展和读取命令进行HMAC保护来防止，这意味着 +如果没有在响应中产生可检测的HMAC失败，则测量值无法被替换。然而第二种 +攻击只能通过依赖某种机制来检测，这种机制会在TPM重置后发生变化。 + +秘密保护 +-------- + +某些进出TPM的信息,如密钥密封、私钥导入和随机数生成容易被拦截，而仅仅 +使用HMAC保护无法防止这种情况。因此，对于这些类型的命令，我们必须使用 +请求和响应加密来防止秘密信息的泄露。 + +与TPM建立初始信任 +----------------- + +为了从一开始就提供安全性，必须建立一个初始的共享或非对称秘密，并且该 +秘钥必须对攻击者不可知。最明显的途径是使用背书和存储种子，这些可以用 +来派生非对称密钥。然而，使用这些密钥很困难，因为将它们传递给内核的唯 +一方法是通过命令行，这需要在启动系统中进行广泛的支持，而且无法保证任 +何一个层次不会有任何形式的授权。 + +Linux内核选择的机制是从空种子使用标准的存储种子参数派生出主椭圆曲线 +密钥。空种子有两个优势：首先该层次物理上无法具有授权，因此我们始终可 +以使用它；其次空种子在TPM重置时会发生变化，这意味着如果我们在当天开始 +时基于空种子建立信任，如果TPM重置且种子变化，则所有派生的密钥进行加盐 +处理的会话都将失败。 + +显然，在没有任何其他共享秘密的情况下使用空种子，我们必须创建并读取初始 +公钥，这当然可能会被总线中间人拦截并替换。然而，TPM有一个密钥认证机制 +（使用EK背书证书，创建认证身份密钥，并用该密钥认证空种子主密钥），但由 +于它过于复杂，无法在内核中运行，因此我们保留空主密钥名称的副本，通过 +sysfs导出，以便用户空间在启动时进行完整的认证。这里的明确保证是，如果空 +主密钥认证成功，那么从当天开始的所有TPM交易都是安全的；如果认证失败，则 +说明系统上有中间人（并且任何在启动期间使用的秘密可能已被泄露）。 + +信任堆叠 +-------- + +在当前的空主密钥场景中，TPM必须在交给下一个使用者之前完全清除。然而， +内核将派生出的空种子密钥的名称传递给用户空间，用户空间可以通过认证来 +验证该名称。因此，这种名称传递链也可以用于各个启动组件之间（通过未指 +定的机制）。例如grub可以使用空种子方案来实现安全性，并将名称交给内核。 +内核可以派生出密钥和名称，并确定如果它们与交接的版本不同，则表示发生 +了篡改。因此可以通过名称传递将任意启动组件（从UEFI到grub到内核）串联 +起来，只要每个后续组件知道如何收集该名称,并根据其派生的密钥进行验证。 + +会话属性 +-------- + +所有内核使用的TPM命令都允许会话。HMAC会话可用于检查请求和响应的完整性， +而解密和加密标志可用于保护参数和响应。HMAC和加密密钥通常是从共享授权秘 +钥推导出来的，但对于许多内核操作来说，这些密钥是已知的（通常为空）。因 +此内核使用空主密钥作为盐密钥来创建每个HMAC会话，这样就为会话密钥的派生 +提供了加密输入。因此内核仅需创建一次空主密钥（作为一个易失的TPM句柄）， +并将其保存在tpm_chip中，用于每次在内核中使用TPM时。由于内核资源管理器缺 +乏去间隙化，当前每次操作都需要创建和销毁会话，但未来可能会将单个会话重用 +用于内核中的HMAC、加密和解密会话。 + +保护类型 +-------- + +对于每个内核操作，我们使用空主密钥加盐的HMAC来保护完整性。此外我们使用参数 +加密来保护密钥密封，并使用参数解密来保护密钥解封和随机数生成。 + +空主密钥认证在用户空间的实现 +============================ + +每个TPM都会附带几个X.509证书，通常用于主背书密钥。本文档假设存在椭圆曲线 +版本的证书，位于01C00002，但也同样适用于RSA证书(位于01C00001)。 + +认证的第一步是使用 `TCG EK Credential Profile`_ 模板进行主密钥的创建，该 +模板允许将生成的主密钥与证书中的主密钥进行比较（公钥必须匹配）。需要注意 +的是，生成EK主密钥需要EK层级密码，但EC主密钥的预生成版本应位于81010002， +并且可以无需密钥授权对其执行TPM2_ReadPublic()操作。接下来，证书本身必须 +经过验证，以确保其可以追溯到制造商根证书（该根证书应公开在制造商网站上）。 +完成此步骤后将在TPM内部生成一个认证密钥（AK），并使用TPM2_MakeCredential、 +AK的名称和EK公钥加密一个秘密。然后TPM执行TPM2_ActivateCredential，只有在 +TPM、EK和AK之间的绑定关系成立时，才能恢复秘密。现在，生成的AK可以用于对由 +内核导出的空主密钥进行认证。由于TPM2_MakeCredential/ActivateCredential操作 +相对复杂，下面将描述一种涉及外部生成私钥的简化过程。 + +这个过程是通常基于隐私CA认证过程的简化缩写。假设此时认证由TPM所有者进行， +所有者只能访问所有者层次。所有者创建一个外部公/私钥对（假设是椭圆曲线）， +并使用内部包装过程将私钥进行封装以便导入，该私钥被其父级由EC派生的存储主密 +钥保护。TPM2_Import()操作使用一个以EK主密钥为盐值的参数解密HMAC会话（这也不 +需要EK密钥授权），意味着内部封装密钥是加密参数，因此除非TPM拥有认证的EK，否 +则无法执行导入操作。如果该命令成功执行并且HMAC在返回时通过验证，我们就知道 +我们有一个只为认证TPM加载的私钥副本。现在该密钥已加载到TPM中，并且存储主密 +钥已被清除（以释放空间用于生成空密钥）。 + +现在根据 `TCG TPM v2.0 Provisioning Guidance`_ 中的存储配置生成空EC主密钥； +该密钥的名称（即公钥区域的哈希值）被计算出来并与内核在/sys/class/tpm/tpm0/null_name +中提供的空种子名称进行比较。如果名称不匹配，TPM就被认为是受损的。如果名称匹配， +用户执行TPM2_Certify()，使用空主密钥作为对象句柄，使用加载的私钥作为签名句柄， +并提供随机的合格数据。返回的certifyInfo的签名将与加载的私钥的公钥部分进行验证， +并检查合格数据以防止重放。如果所有测试都通过，用户就可以确信TPM的完整性和隐私 +性在整个内核启动过程中得到了保护。 + +.. _TPM Genie: https://www.nccgroup.trust/globalassets/about-us/us/documents/tpm-genie.pdf +.. _Windows Bitlocker TPM: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network +.. _基于TPM的Linux磁盘加密: https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets +.. _TCG EK Credential Profile: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/ +.. _TCG TPM v2.0 Provisioning Guidance: https://trustedcomputinggroup.org/resource/tcg-tpm-v2-0-provisioning-guidance/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst new file mode 100644 index 000000000000..9c173291ac3e --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_event_log.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_event_log.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +TPM事件日志 +=========== + +本文档简要介绍了什么是TPM日志，以及它是如何从预启动固件移交到操作系统的。 + +介绍 +==== + +预启动固件维护一个事件日志，每当它将某些内容哈希到任何一个PCR寄存器时，该 +日志会添加新条目。这些事件按类型分类，并包含哈希后的PCR寄存器值。通常，预 +启动固件会哈希那些即将移交执行权或与启动过程相关的组件。 + +其主要应用是远程认证，而它之所以有用的原因在[1]中第一部分很好地阐述了： + +认证用于向挑战者提供有关平台状态的信息。然而，PCR的内容难以解读；因此，当 +PCR内容附有测量日志时，认证通常会更有用。尽管测量日志本身并不可信，但它们 +包含比PCR内容更为丰富的信息集。PCR内容用于对测量日志进行验证。 + +UEFI事件日志 +============ + +UEFI提供的事件日志有一些比较奇怪的特性。 + +在调用ExitBootServices()之前，Linux EFI引导加载程序会将事件日志复制到由 +引导加载程序自定义的配置表中。不幸的是，通过ExitBootServices()生成的事件 +并不会出现在这个表里。 + +固件提供了一个所谓的最终事件配置表排序来解决这个问题。事件会在第一次调用 +EFI_TCG2_PROTOCOL.GetEventLog()后被镜像到这个表中。 + +这引出了另一个问题：无法保证它不会在 Linux EFI stub 开始运行之前被调用。 +因此，在 stub 运行时，它需要计算并将最终事件表的大小保存到自定义配置表中， +以便TPM驱动程序可以在稍后连接来自自定义配置表和最终事件表的两个事件日志时 +跳过这些事件。 + +参考文献 +======== + +- [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ +- [2] The final concatenation is done in drivers/char/tpm/eventlog/efi.c diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst new file mode 100644 index 000000000000..5901eee32563 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_ftpm_tee.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_ftpm_tee.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +=========== +固件TPM驱动 +=========== + +本文档描述了固件可信平台模块（fTPM）设备驱动。 + +介绍 +==== + +该驱动程序是用于ARM的TrustZone环境中实现的固件的适配器。该驱动 +程序允许程序以与硬件TPM相同的方式与TPM进行交互。 + +设计 +==== + +该驱动程序充当一个薄层，传递命令到固件实现的TPM并接收其响应。驱动 +程序本身并不包含太多逻辑，更像是固件与内核/用户空间之间的一个管道。 + +固件本身基于以下论文： +https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/ftpm1.pdf + +当驱动程序被加载时，它会向用户空间暴露 ``/dev/tpmX`` 字符设备，允许 +用户空间通过该设备与固件TPM进行通信。 diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst new file mode 100644 index 000000000000..0fb009f93e10 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_tis.rst @@ -0,0 +1,43 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_tis.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +TPM FIFO接口驱动 +================ + +TCG PTP规范定义了两种接口类型：FIFO和CRB。前者基于顺序的读写操作， +后者基于包含完整命令或响应的缓冲区。 + +FIFO（先进先出）接口被tpm_tis_core依赖的驱动程序使用。最初，Linux只 +有一个名为tpm_tis的驱动，覆盖了内存映射（即 MMIO）接口，但后来它被 +扩展以支持TCG标准所支持的其他物理接口。 + +由于历史原因，最初的MMIO驱动被称为tpm_tis，而FIFO驱动的框架被命名为 +tpm_tis_core。在tpm_tis中的“tis”后缀来自TPM接口规范，这是针对TPM1.x +芯片的硬件接口规范。 + +通信基于一个由TPM芯片通过硬件总线或内存映射共享的20KiB 缓冲区，具体 +取决于物理接线。该缓冲区进一步分为五个相等大小的4KiB缓冲区，为CPU和 +TPM之间的通信提供等效的寄存器集。这些通信端点在TCG术语中称为localities。 + +当内核想要向TPM芯片发送命令时，它首先通过在TPM_ACCESS寄存器中设置 +requestUse位来保留locality0。当访问被授予时，该位由芯片清除。一旦完成 +通信，内核会写入TPM_ACCESS.activeLocality位。这告诉芯片该本地性已被 +释放。 + +待处理的本地性由芯片按优先级降序逐个服务，一次一个： + +- Locality0优先级最低。 +- Locality5优先级最高。 + +关于localities的更多信息和含义，请参阅TCG PC客户端平台TPM 配置文件规范的第3.2节。 + +参考文献 +======== + +TCG PC客户端平台TPM配置文件（PTP）规范 +https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/ diff --git a/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst new file mode 100644 index 000000000000..bc92cfb684c3 --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/tpm_vtpm_proxy.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/tpm_vtpm_proxy.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +========================== +Linux容器的虚拟TPM代理驱动 +========================== + +| 作者： +| Stefan Berger <stefanb@linux.vnet.ibm.com> + +本文档描述了用于Linux容器的虚拟可信平台模块（vTPM）代理设备驱动。 + +介绍 +==== + +这项工作的目标是为每个Linux容器提供TPM功能。这使得程序能够像与物理系统 +上的TPM交互一样，与容器中的TPM进行交互。每个容器都会获得一个唯一的、模 +拟的软件TPM。 + +设计 +==== + +为了使每个容器都能使用模拟的软件TPM，容器管理栈需要创建一对设备，其中 +包括一个客户端TPM字符设备 ``/dev/tpmX`` （X=0,1,2...）和一个‘服务器端’ +文件描述符。当文件描述符传被递给TPM模拟器时，前者通过创建具有适当主次 +设备号的字符设备被移入容器，然后，容器内的软件可以使用字符设备发送TPM +命令，模拟器将通过文件描述符接收这些命令，并用它来发送响应。 + +为了支持这一点，虚拟TPM代理驱动程序提供了一个设备 ``/dev/vtpmx`` ，该设备 +用于通过ioctl创建设备对。ioctl将其作为配置设备的输入标志，例如这些标志指示 +TPM模拟器是否支持TPM1.2或TPM2功能。ioctl的结果是返回‘服务器端’的文件描述符 +以及创建的字符设备的主次设备号。此外，还会返回TPM字符设备的编号。例如，如果 +创建了 ``/dev/tpm10`` ，则返回编号（ ``dev_num`` ）10。 + +一旦设备被创建，驱动程序将立即尝试与TPM进行通信。来自驱动程序的所有命令 +都可以从ioctl返回的文件描述符中读取。这些命令应该立即得到响应。 + +UAPI +==== + +该API在以下内核代码中： + +include/uapi/linux/vtpm_proxy.h +drivers/char/tpm/tpm_vtpm_proxy.c + +函数：vtpmx_ioc_new_dev diff --git a/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst new file mode 100644 index 000000000000..fa085d98a99b --- /dev/null +++ b/Documentation/translations/zh_CN/security/tpm/xen-tpmfront.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/security/tpm/xen-tpmfront.rst + +:翻译: + 赵硕 Shuo Zhao <zhaoshuo@cqsoftware.com.cn> + +================ +Xen的虚拟TPM接口 +================ + +作者：Matthew Fioravante (JHUAPL), Daniel De Graaf (NSA) + +本文档描述了用于Xen的虚拟可信平台模块（vTPM）子系统。假定读者熟悉 +Xen和Linux的构建和安装，并对TPM和vTPM概念有基本的理解。 + +介绍 +---- + +这项工作的目标是为虚拟客户操作系统（在Xen中称为DomU）提供TPM功能。这使得 +程序能够像与物理系统上的TPM交互一样，与虚拟系统中的TPM进行交互。每个客户 +操作系统都会获得一个唯一的、模拟的软件TPM。然而，vTPM的所有秘密（如密钥、 +NVRAM 等）由vTPM管理域进行管理，该域将这些秘密封存到物理TPM中。如果创建这 +些域（管理域、vTPM域和客户域）的过程是可信的，vTPM子系统就能将根植于硬件 +TPM的信任链扩展到Xen中的虚拟机。vTPM的每个主要组件都作为一个独立的域实现， +从而通过虚拟机监控程序（hypervisor）提供安全隔离。 + +这个mini-os vTPM 子系统是建立在IBM和Intel公司之前的vTPM工作基础上的。 + + +设计概述 +-------- + +vTPM的架构描述如下:: + + +------------------+ + | Linux DomU | ... + | | ^ | + | v | | + | xen-tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpm-stubdom | ... + | | ^ | + | v | | + | mini-os/tpmfront | + +------------------+ + | ^ + v | + +------------------+ + | mini-os/tpmback | + | | ^ | + | v | | + | vtpmmgr-stubdom | + | | ^ | + | v | | + | mini-os/tpm_tis | + +------------------+ + | ^ + v | + +------------------+ + | Hardware TPM | + +------------------+ + +* Linux DomU: + 希望使用vTPM的基于Linux的客户机。可能有多个这样的实例。 + +* xen-tpmfront.ko: + Linux内核虚拟TPM前端驱动程序。该驱动程序为基于Linux的DomU提供 + vTPM访问。 + +* mini-os/tpmback: + Mini-os TPM后端驱动程序。Linux前端驱动程序通过该后端驱动程序连 + 接，以便在Linux DomU和其vTPM之间进行通信。该驱动程序还被 + vtpmmgr-stubdom用于与vtpm-stubdom通信。 + +* vtpm-stubdom: + 一个实现vTPM的mini-os存根域。每个正在运行的vtpm-stubdom实例与系统 + 上的逻辑vTPM之间有一一对应的关系。vTPM平台配置寄存器（PCRs）通常都 + 初始化为零。 + +* mini-os/tpmfront: + Mini-os TPM前端驱动程序。vTPM mini-os域vtpm-stubdom使用该驱动程序 + 与vtpmmgr-stubdom通信。此驱动程序还用于与vTPM域通信的mini-os域，例 + 如 pv-grub。 + +* vtpmmgr-stubdom: + 一个实现vTPM管理器的mini-os域。系统中只有一个vTPM管理器，并且在整个 + 机器生命周期内应一直运行。此域调节对系统中物理TPM的访问，并确保每个 + vTPM的持久状态。 + +* mini-os/tpm_tis: + Mini-osTPM1.2版本TPM 接口规范（TIS）驱动程序。该驱动程序由vtpmmgr-stubdom + 用于直接与硬件TPM通信。通信通过将硬件内存页映射到vtpmmgr-stubdom来实现。 + +* 硬件TPM: + 固定在主板上的物理 TPM。 + +与Xen的集成 +----------- + +vTPM驱动程序的支持已在Xen4.3中通过libxl工具堆栈添加。有关设置vTPM和vTPM +管理器存根域的详细信息，请参见Xen文档（docs/misc/vtpm.txt）。一旦存根域 +运行，与磁盘或网络设备相同，vTPM设备将在域的配置文件中进行设置 + +为了使用诸如IMA（完整性测量架构）等需要在initrd之前加载TPM的功能，必须将 +xen-tpmfront驱动程序编译到内核中。如果不使用这些功能，驱动程序可以作为 +模块编译，并像往常一样加载。 diff --git a/Documentation/translations/zh_TW/admin-guide/README.rst b/Documentation/translations/zh_TW/admin-guide/README.rst index a6e34c200ea3..0b038074d9d1 100644 --- a/Documentation/translations/zh_TW/admin-guide/README.rst +++ b/Documentation/translations/zh_TW/admin-guide/README.rst @@ -149,7 +149,7 @@ Linux內核6.x版本 <http://kernel.org/> "make xconfig" 基於Qt的配置工具。 - "make gconfig" 基於GTK+的配置工具。 + "make gconfig" 基於GTK的配置工具。 "make oldconfig" 基於現有的 ./.config 文件選擇所有選項，並詢問 新配置選項。 diff --git a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst index b25ecc44d735..80ea5677ee52 100644 --- a/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst +++ b/Documentation/translations/zh_TW/admin-guide/bug-hunting.rst @@ -191,7 +191,7 @@ objdump 編行。如果沒有調試符號，您將看到所示例程的彙編程序代碼，但是如果內核有調試 符號，C代碼也將可見（調試符號可以在內核配置菜單的hacking項中啓用）。例如:: - $ objdump -r -S -l --disassemble net/dccp/ipv4.o + $ objdump -r -S -l --disassemble net/ipv4/tcp.o .. note:: diff --git a/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst b/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst index 422fe9f7a3f2..a1e4517dc601 100644 --- a/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst +++ b/Documentation/translations/zh_TW/arch/openrisc/openrisc_port.rst @@ -17,10 +17,10 @@ OpenRISC 1000系列（或1k）。 關於OpenRISC處理器和正在進行中的開發的信息: - ======= ============================= + ======= ============================== 網站 https://openrisc.io - 郵箱 openrisc@lists.librecores.org - ======= ============================= + 郵箱 linux-openrisc@vger.kernel.org + ======= ============================== --------------------------------------------------------------------- @@ -36,11 +36,11 @@ OpenRISC工具鏈和Linux的構建指南 工具鏈的構建指南可以在openrisc.io或Stafford的工具鏈構建和發佈腳本 中找到。 - ====== ================================================= - 二進制 https://github.com/openrisc/or1k-gcc/releases + ====== ========================================================== + 二進制 https://github.com/stffrdhrn/or1k-toolchain-build/releases 工具鏈 https://openrisc.io/software 構建 https://github.com/stffrdhrn/or1k-toolchain-build - ====== ================================================= + ====== ========================================================== 2) 構建 diff --git a/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst b/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst index c881e8872b19..b595af59ba78 100644 --- a/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst +++ b/Documentation/translations/zh_TW/dev-tools/gdb-kernel-debugging.rst @@ -116,35 +116,31 @@ Kgdb內核調試器、QEMU等虛擬機管理程序或基於JTAG的硬件接口 - 對當前或指定的CPU使用per-cpu函數:: - (gdb) p $lx_per_cpu("runqueues").nr_running + (gdb) p $lx_per_cpu(runqueues).nr_running $3 = 1 - (gdb) p $lx_per_cpu("runqueues", 2).nr_running + (gdb) p $lx_per_cpu(runqueues, 2).nr_running $4 = 0 - 使用container_of查看更多hrtimers信息:: - (gdb) set $next = $lx_per_cpu("hrtimer_bases").clock_base[0].active.next - (gdb) p *$container_of($next, "struct hrtimer", "node") + (gdb) set $leftmost = $lx_per_cpu(hrtimer_bases).clock_base[0].active.rb_root.rb_leftmost + (gdb) p *$container_of($leftmost, "struct hrtimer", "node") $5 = { node = { node = { - __rb_parent_color = 18446612133355256072, - rb_right = 0x0 <irq_stack_union>, - rb_left = 0x0 <irq_stack_union> + __rb_parent_color = 18446612686384860673, + rb_right = 0xffff888231da8b00, + rb_left = 0x0 }, - expires = { - tv64 = 1835268000000 - } + expires = 1228461000000 }, - _softexpires = { - tv64 = 1835268000000 - }, - function = 0xffffffff81078232 <tick_sched_timer>, - base = 0xffff88003fd0d6f0, - state = 1, - start_pid = 0, - start_site = 0xffffffff81055c1f <hrtimer_start_range_ns+20>, - start_comm = "swapper/2\000\000\000\000\000\000" + _softexpires = 1228461000000, + function = 0xffffffff8137ab20 <tick_nohz_handler>, + base = 0xffff888231d9b4c0, + state = 1 '\001', + is_rel = 0 '\000', + is_soft = 0 '\000', + is_hard = 1 '\001' } diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst index 0ecb187753e4..a0cb91a6945f 100644 --- a/Documentation/translations/zh_TW/process/submit-checklist.rst +++ b/Documentation/translations/zh_TW/process/submit-checklist.rst @@ -85,8 +85,8 @@ Linux內核補丁提交檢查單 17) 所有新的模塊參數都記錄在 ``MODULE_PARM_DESC()`` 18) 所有新的用戶空間接口都記錄在 ``Documentation/ABI/`` 中。有關詳細信息， - 請參閱 ``Documentation/ABI/README`` 。更改用戶空間接口的補丁應該抄送 - linux-api@vger.kernel.org。 + 請參閱 Documentation/admin-guide/abi.rst (或 ``Documentation/ABI/README``)。 + 更改用戶空間接口的補丁應該抄送 linux-api@vger.kernel.org\ 。 19) 已通過至少注入slab和page分配失敗進行檢查。請參閱 ``Documentation/fault-injection/`` 。 如果新代碼是實質性的，那麼添加子系統特定的故障注入可能是合適的。 |