summaryrefslogtreecommitdiff
path: root/Documentation/translations/zh_CN
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2024-01-12 06:46:52 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2024-01-12 06:46:52 +0300
commit5b9b41617bf3e1282cc60f07d3d52e62399aa4ba (patch)
treecff3bb6bac83d19a7afd9e6d637ec4d6480e5d0f /Documentation/translations/zh_CN
parent22d29f1112c85c1ad519a8c0403f7f7289cf060c (diff)
parent2d179e8ac02e33c82c1a314961254353eb5028b3 (diff)
downloadlinux-5b9b41617bf3e1282cc60f07d3d52e62399aa4ba.tar.xz
Merge tag 'docs-6.8' of git://git.lwn.net/linux
Pull documentation update from Jonathan Corbet: "Another moderately busy cycle for documentation, including: - The minimum Sphinx requirement has been raised to 2.4.4, following a warning that was added in 6.2 - Some reworking of the Documentation/process front page to, hopefully, make it more useful - Various kernel-doc tweaks to, for example, make it deal properly with __counted_by annotations - We have also restored a warning for documentation of nonexistent structure members that disappeared a while back. That had the delightful consequence of adding some 600 warnings to the docs build. A sustained effort by Randy, Vegard, and myself has addressed almost all of those, bringing the documentation back into sync with the code. The fixes are going through the appropriate maintainer trees - Various improvements to the HTML rendered docs, including automatic links to Git revisions and a nice new pulldown to make translations easy to access - Speaking of translations, more of those for Spanish and Chinese ... plus the usual stream of documentation updates and typo fixes" * tag 'docs-6.8' of git://git.lwn.net/linux: (57 commits) MAINTAINERS: use tabs for indent of CONFIDENTIAL COMPUTING THREAT MODEL A reworked process/index.rst ring-buffer/Documentation: Add documentation on buffer_percent file Translated the RISC-V architecture boot documentation. Docs: remove mentions of fdformat from util-linux Docs/zh_CN: Fix the meaning of DEBUG to pr_debug() Documentation: move driver-api/dcdbas to userspace-api/ Documentation: move driver-api/isapnp to userspace-api/ Documentation/core-api : fix typo in workqueue Documentation/trace: Fixed typos in the ftrace FLAGS section kernel-doc: handle a void function without producing a warning scripts/get_abi.pl: ignore some temp files docs: kernel_abi.py: fix command injection scripts/get_abi: fix source path leak CREDITS, MAINTAINERS, docs/process/howto: Update man-pages' maintainer docs: translations: add translations links when they exist kernel-doc: Align quick help and the code MAINTAINERS: add reviewer for Spanish translations docs: ignore __counted_by attribute in structure definitions scripts: kernel-doc: Clarify missing struct member description ..
Diffstat (limited to 'Documentation/translations/zh_CN')
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/boot.rst155
-rw-r--r--Documentation/translations/zh_CN/arch/riscv/index.rst1
-rw-r--r--Documentation/translations/zh_CN/core-api/printk-basics.rst2
-rw-r--r--Documentation/translations/zh_CN/dev-tools/index.rst5
-rw-r--r--Documentation/translations/zh_CN/dev-tools/testing-overview.rst2
-rw-r--r--Documentation/translations/zh_CN/driver-api/gpio/index.rst3
-rw-r--r--Documentation/translations/zh_CN/driver-api/index.rst5
-rw-r--r--Documentation/translations/zh_CN/process/development-process.rst5
-rw-r--r--Documentation/translations/zh_CN/process/index.rst53
-rw-r--r--Documentation/translations/zh_CN/process/magic-number.rst69
-rw-r--r--Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst789
-rw-r--r--Documentation/translations/zh_CN/userspace-api/index.rst5
12 files changed, 1037 insertions, 57 deletions
diff --git a/Documentation/translations/zh_CN/arch/riscv/boot.rst b/Documentation/translations/zh_CN/arch/riscv/boot.rst
new file mode 100644
index 000000000000..0c2619095819
--- /dev/null
+++ b/Documentation/translations/zh_CN/arch/riscv/boot.rst
@@ -0,0 +1,155 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/arch/riscv/boot.rst
+
+:翻译:
+
+ 龙进 Jin Long <longjin@dragonos.org>
+
+========================
+RISC-V内核启动要求和限制
+========================
+
+:Author: Alexandre Ghiti <alexghiti@rivosinc.com>
+:Date: 23 May 2023
+
+这份文档描述了RISC-V内核对引导加载程序和固件的期望,以及任何开发者在接触
+早期启动过程时必须牢记的约束。在这份文档中, ``早期启动过程`` 指的是在最
+终虚拟映射设置之前运行的任何代码。
+
+内核预加载的要求和限制
+======================
+
+RISC-V内核对引导加载程序和平台固件有以下要求:
+
+寄存器状态
+----------
+
+RISC-V内核期望:
+
+ * ``$a0`` 应包含当前核心的hartid。
+ * ``$a1`` 应包含内存中设备树的地址。
+
+CSR 寄存器状态
+--------------
+
+RISC-V内核期望:
+
+ * ``$satp = 0``: 如果存在MMU,必须将其禁用。
+
+为常驻固件保留的内存
+--------------------
+
+RISC-V内核在直接映射中不能映射任何常驻内存或用PMPs保护的内存,
+因此固件必须根据设备树规范 和/或 UEFI规范正确标记这些区域。
+
+内核的位置
+----------
+
+RISC-V内核期望被放置在PMD边界(对于rv64为2MB对齐,对于rv32为4MB对齐)。
+请注意,如果不是这样,EFI stub 将重定位内核。
+
+硬件描述
+--------
+
+固件可以将设备树或ACPI表传递给RISC-V内核。
+
+设备树可以直接从前一阶段通过$a1寄存器传递给内核,或者在使用UEFI启动时,
+可以通过EFI配置表传递。
+
+ACPI表通过EFI配置表传递给内核。在这种情况下,EFI stub 仍然会创建一个
+小的设备树。请参阅下面的"EFI stub 和设备树"部分,了解这个设备树的详细
+信息。
+
+内核入口
+--------
+
+在SMP系统中,有两种方法可以进入内核:
+
+- ``RISCV_BOOT_SPINWAIT``:固件在内核中释放所有的hart,一个hart赢
+ 得抽奖并执行早期启动代码,而其他的hart则停在那里等待初始化完成。这种
+ 方法主要用于支持没有SBI HSM扩展和M模式RISC-V内核的旧固件。
+- ``有序启动``:固件只释放一个将执行初始化阶段的hart,然后使用SBI HSM
+ 扩展启动所有其他的hart。有序启动方法是启动RISC-V内核的首选启动方法,
+ 因为它可以支持CPU热插拔和kexec。
+
+UEFI
+----
+
+UEFI 内存映射
+~~~~~~~~~~~~~
+
+使用UEFI启动时,RISC-V内核将只使用EFI内存映射来填充系统内存。
+
+UEFI固件必须解析 ``/reserved-memory`` 设备树节点的子节点,并遵守设备
+树规范,将这些子节点的属性( ``no-map`` 和 ``reusable`` )转换为其正
+确的EFI等价物(参见设备树规范v0.4-rc1的"3.5.4/reserved-memory和
+UEFI"部分)。
+
+RISCV_EFI_BOOT_PROTOCOL
+~~~~~~~~~~~~~~~~~~~~~~~
+
+使用UEFI启动时,EFI stub 需要引导hartid以便将其传递给 ``$a1`` 中的
+RISC-V内核。EFI stub使用以下方法之一获取引导hartid:
+
+- ``RISCV_EFI_BOOT_PROTOCOL`` (**首选**)。
+- ``boot-hartid`` 设备树子节点(**已弃用**)。
+
+任何新的固件都必须实现 ``RISCV_EFI_BOOT_PROTOCOL``,因为基于设备树
+的方法现已被弃用。
+
+早期启动的要求和约束
+====================
+
+RISC-V内核的早期启动过程遵循以下约束:
+
+EFI stub 和设备树
+-----------------
+
+使用UEFI启动时,EFI stub 会用与arm64相同的参数补充(或创建)设备树,
+这些参数在Documentation/arch/arm/uefi.rst中的
+"UEFI kernel supporton ARM"段落中有描述。
+
+虚拟映射安装
+------------
+
+在RISC-V内核中,虚拟映射的安装分为两步进行:
+
+1. ``setup_vm()`` 在 ``early_pg_dir`` 中安装一个临时的内核映射,这
+ 允许发现系统内存。 此时只有内核文本/数据被映射。在建立这个映射时,
+ 不能进行分配(因为系统内存还未知),所以``early_pg_dir``页表是静
+ 态分配的(每个级别只使用一个表)。
+
+2. ``setup_vm_final()`` 在 ``swapper_pg_dir`` 中创建最终的内核映
+ 射,并利用发现的系统内存 创建线性映射。在建立这个映射时,内核可以
+ 分配内存,但不能直接访问它(因为直接映射还不存在),所以它使用fixmap
+ 区域的临时映射来访问新分配的页表级别。
+
+为了让 ``virt_to_phys()`` 和 ``phys_to_virt()`` 能够正确地将直接
+映射地址转换为物理地址,它们需要知道DRAM的起始位置。这发生在步骤1之后,
+就在步骤2安装直接映射之前(参见arch/riscv/mm/init.c中的
+``setup_bootmem()`` 函数)。在安装最终虚拟映射之前使用这些宏时必须
+仔细检查。
+
+通过fixmap进行设备树映射
+------------------------
+
+由于 ``reserved_mem`` 数组是用 ``setup_vm()`` 建立的虚拟地址初始化
+的,并且与``setup_vm_final()``建立的映射一起使用,RISC-V内核使用
+fixmap区域来映射设备树。这确保设备树可以通过两种虚拟映射访问。
+
+Pre-MMU执行
+-----------
+
+在建立第一个虚拟映射之前,需要运行一些代码。这些包括第一个虚拟映射的安装本身,
+早期替代方案的修补,以及内核命令行的早期解析。这些代码必须非常小心地编译,因为:
+
+- ``-fno-pie``:这对于使用``-fPIE``的可重定位内核是必需的,否则,任何对
+ 全局符号的访问都将通过 GOT进行,而GOT只是虚拟地重新定位。
+- ``-mcmodel=medany``:任何对全局符号的访问都必须是PC相对的,以避免在设
+ 置MMU之前发生任何重定位。
+- *所有* 的仪表化功能也必须被禁用(包括KASAN,ftrace和其他)。
+
+由于使用来自不同编译单元的符号需要用这些标志编译该单元,我们建议尽可能不要使用
+外部符号。
diff --git a/Documentation/translations/zh_CN/arch/riscv/index.rst b/Documentation/translations/zh_CN/arch/riscv/index.rst
index 3b041c116169..96573459105e 100644
--- a/Documentation/translations/zh_CN/arch/riscv/index.rst
+++ b/Documentation/translations/zh_CN/arch/riscv/index.rst
@@ -17,6 +17,7 @@ RISC-V 体系结构
.. toctree::
:maxdepth: 1
+ boot
boot-image-header
vm-layout
patch-acceptance
diff --git a/Documentation/translations/zh_CN/core-api/printk-basics.rst b/Documentation/translations/zh_CN/core-api/printk-basics.rst
index 59c6efb3fc41..cafa01bccff2 100644
--- a/Documentation/translations/zh_CN/core-api/printk-basics.rst
+++ b/Documentation/translations/zh_CN/core-api/printk-basics.rst
@@ -100,7 +100,7 @@ printk()的用法通常是这样的::
为了调试,还有两个有条件编译的宏:
pr_debug()和pr_devel(),除非定义了 ``DEBUG`` (或者在pr_debug()的情况下定义了
-``CONFIG_DYNAMIC_DEBUG`` ),否则它们会被编译。
+``CONFIG_DYNAMIC_DEBUG`` ),否则它们不会被编译。
函数接口
diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
index 02577c379007..c2db3e566b1b 100644
--- a/Documentation/translations/zh_CN/dev-tools/index.rst
+++ b/Documentation/translations/zh_CN/dev-tools/index.rst
@@ -14,11 +14,8 @@
有关测试专用工具的简要概述,参见
Documentation/translations/zh_CN/dev-tools/testing-overview.rst
-.. class:: toc-title
-
- 目录
-
.. toctree::
+ :caption: 目录
:maxdepth: 2
testing-overview
diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index 69e7e4cb2002..c91f9b60f9f1 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -3,7 +3,7 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/dev-tools/testing-overview.rst
-:Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com>
+:Translator: 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
============
内核测试指南
diff --git a/Documentation/translations/zh_CN/driver-api/gpio/index.rst b/Documentation/translations/zh_CN/driver-api/gpio/index.rst
index 9ab64e94aced..9a6a14162a6c 100644
--- a/Documentation/translations/zh_CN/driver-api/gpio/index.rst
+++ b/Documentation/translations/zh_CN/driver-api/gpio/index.rst
@@ -14,9 +14,8 @@
通用型输入/输出(GPIO)
=======================
-目录:
-
.. toctree::
+ :caption: 目录
:maxdepth: 2
legacy
diff --git a/Documentation/translations/zh_CN/driver-api/index.rst b/Documentation/translations/zh_CN/driver-api/index.rst
index ba354e1f4e6d..92ff1b7fc3d3 100644
--- a/Documentation/translations/zh_CN/driver-api/index.rst
+++ b/Documentation/translations/zh_CN/driver-api/index.rst
@@ -17,11 +17,8 @@ Linux驱动实现者的API指南
内核提供了各种各样的接口来支持设备驱动的开发。这份文档只是对其中一些接口进行了
一定程度的整理——希望随着时间的推移,它能变得更好!可用的小节可以在下面看到。
-.. class:: toc-title
-
- 目录列表:
-
.. toctree::
+ :caption: 目录列表
:maxdepth: 2
gpio/index
diff --git a/Documentation/translations/zh_CN/process/development-process.rst b/Documentation/translations/zh_CN/process/development-process.rst
index 30cffe66c075..c10d8e2e21eb 100644
--- a/Documentation/translations/zh_CN/process/development-process.rst
+++ b/Documentation/translations/zh_CN/process/development-process.rst
@@ -8,9 +8,10 @@
内核开发过程指南
================
-内容:
+本文档的目的是帮助开发人员(及其经理)以最小的挫折感与开发社区合作。它试图记录这个社区如何以一种不熟悉Linux内核开发(或者实际上是自由软件开发)的人可以访问的方式工作。虽然这里有一些技术资料,但这是一个面向过程的讨论,不需要深入了解内核编程就可以理解。
.. toctree::
+ :caption: 内容
:numbered:
:maxdepth: 2
@@ -22,5 +23,3 @@
6.Followthrough
7.AdvancedTopics
8.Conclusion
-
-本文档的目的是帮助开发人员(及其经理)以最小的挫折感与开发社区合作。它试图记录这个社区如何以一种不熟悉Linux内核开发(或者实际上是自由软件开发)的人可以访问的方式工作。虽然这里有一些技术资料,但这是一个面向过程的讨论,不需要深入了解内核编程就可以理解。
diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
index a1a35f88f4ae..3ca02d281be0 100644
--- a/Documentation/translations/zh_CN/process/index.rst
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -5,10 +5,11 @@
.. include:: ../disclaimer-zh_CN.rst
-:Original: :ref:`Documentation/process/index.rst <process_index>`
-:Translator: Alex Shi <alex.shi@linux.alibaba.com>
+:Original: Documentation/process/index.rst
-.. _cn_process_index:
+:翻译:
+
+ Alex Shi <alex.shi@linux.alibaba.com>
========================
与Linux 内核社区一起工作
@@ -23,29 +24,55 @@
.. toctree::
:maxdepth: 1
+ license-rules
howto
code-of-conduct
code-of-conduct-interpretation
+ development-process
submitting-patches
programming-language
coding-style
- development-process
+ maintainer-pgp-guide
email-clients
- license-rules
kernel-enforcement-statement
kernel-driver-statement
+TODOLIST:
+
+* handling-regressions
+* maintainer-handbooks
+
+安全方面, 请阅读:
+
+.. toctree::
+ :maxdepth: 1
+
+ embargoed-hardware-issues
+
+TODOLIST:
+
+* security-bugs
+
其它大多数开发人员感兴趣的社区指南:
.. toctree::
:maxdepth: 1
- submit-checklist
stable-api-nonsense
- stable-kernel-rules
management-style
- embargoed-hardware-issues
+ stable-kernel-rules
+ submit-checklist
+
+TODOLIST:
+
+* changes
+* kernel-docs
+* deprecated
+* maintainers
+* researcher-guidelines
+* contribution-maturity-model
+
这些是一些总体性技术指南,由于不大好分类而放在这里:
@@ -54,6 +81,16 @@
magic-number
volatile-considered-harmful
+ ../arch/riscv/patch-acceptance
+ ../core-api/unaligned-memory-access
+
+TODOLIST:
+
+* applying-patches
+* backporting
+* adding-syscalls
+* botching-up-ioctls
+* clang-format
.. only:: subproject and html
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst
index 4a92ebb619ee..4e4aeaca796c 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -1,58 +1,67 @@
-.. _cn_magicnumbers:
-
.. include:: ../disclaimer-zh_CN.rst
-:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
+:Original: Documentation/process/magic-number.rst
+
+:翻译:
-如果想评论或更新本文的内容,请直接发信到LKML。如果你使用英文交流有困难的话,也可
-以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题,请联系中文版维护者::
+ 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
- 中文版维护者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
- 中文版翻译者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
- 中文版校译者: 贾威威 Jia Wei Wei <harryxiyou@gmail.com>
+:校译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
Linux 魔术数
============
-这个文件是有关当前使用的魔术值注册表。当你给一个结构添加了一个魔术值,你也应该把这个魔术值添加到这个文件,因为我们最好把用于各种结构的魔术值统一起来。
+这个文件是有关当前使用的魔术值注册表。当你给一个结构体添加了一个魔术值,你也
+应该把这个魔术值添加到这个文件,因为我们最好把用于各种结构体的魔术值统一起来。
-使用魔术值来保护内核数据结构是一个非常好的主意。这就允许你在运行期检查(a)一个结构是否已经被攻击,或者(b)你已经给一个例行程序通过了一个错误的结构。后一种情况特别地有用---特别是当你通过一个空指针指向结构体的时候。tty源码,例如,经常通过特定驱动使用这种方法并且反复地排列特定方面的结构。
+使用魔术值来保护内核数据结构是一个 **非常好的主意** 。这就允许你在运行时检
+查一个结构体(a)是否已经被攻击,或者(b)你已经给一个例程传递了一个错误的结构
+体。最后一种情况特别地有用---特别是当你通过一个空指针指向结构体的时候。例如,
+tty源码经常通过特定驱动使用这种方法用来反复地排列特定方面的结构体。
-使用魔术值的方法是在结构的开始处声明的,如下::
+使用魔术值的方法是在结构体的开头声明它们,如下::
struct tty_ldisc {
int magic;
...
};
-当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试时间,特别是一些古怪的情况,例如,数组超出范围并且重新写了超出部分。遵守这个规则,这些情况可以被快速地,安全地避免。
+当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试
+时间,特别是一些古怪的情况,例如,数组超出范围并且覆盖写了超出部分。利用这
+个规则,这些情况可以被快速地,安全地检测到这些案例。
+
+变更日志::
- Theodore Ts'o
- 31 Mar 94
+ Theodore Ts'o
+ 31 Mar 94
-给当前的Linux 2.1.55添加魔术表。
+ 给当前的Linux 2.1.55添加魔术表。
- Michael Chastain
- <mailto:mec@shout.net>
- 22 Sep 1997
+ Michael Chastain
+ <mailto:mec@shout.net>
+ 22 Sep 1997
-现在应该最新的Linux 2.1.112.因为在特性冻结期间,不能在2.2.x前改变任何东西。这些条目被数域所排序。
+ 现在应该最新的Linux 2.1.112.因为在特性冻结期间,不能在2.2.x前改变任
+ 何东西。这些条目被数域所排序。
- Krzysztof G.Baranowski
- <mailto: kgb@knm.org.pl>
- 29 Jul 1998
+ Krzysztof G.Baranowski
+ <mailto: kgb@knm.org.pl>
+ 29 Jul 1998
-更新魔术表到Linux 2.5.45。刚好越过特性冻结,但是有可能还会有一些新的魔术值在2.6.x之前融入到内核中。
+ 更新魔术表到Linux 2.5.45。刚好越过特性冻结,但是有可能还会有一些新的魔
+ 术值在2.6.x之前融入到内核中。
- Petr Baudis
- <pasky@ucw.cz>
- 03 Nov 2002
+ Petr Baudis
+ <pasky@ucw.cz>
+ 03 Nov 2002
-更新魔术表到Linux 2.5.74。
+ 更新魔术表到Linux 2.5.74。
- Fabian Frederick
- <ffrederick@users.sourceforge.net>
- 09 Jul 2003
+ Fabian Frederick
+ <ffrederick@users.sourceforge.net>
+ 09 Jul 2003
===================== ================ ======================== ==========================================
魔术数名 数字 结构 文件
diff --git a/Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst b/Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
new file mode 100644
index 000000000000..eb12694a4c59
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
@@ -0,0 +1,789 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/process/maintainer-pgp-guide.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+:校译:
+
+
+===================
+内核维护者 PGP 指南
+===================
+
+:作者: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
+
+本文档面向 Linux 内核开发者,特别是子系统维护人员。文档中含有Linux 基金
+会发布的更通用的 `保护代码完整性`_ 指南中讨论的内容子集。阅读该文档,以更
+深入地讨论本指南中提到的一些主题。
+
+.. _`保护代码完整性`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
+
+PGP 在 Linux 内核开发中的作用
+=============================
+
+PGP 有助于确保 Linux 内核开发社区产出代码的完整性,并在较小程度上,通过
+PGP 签名的电子邮件交换,在开发者之间建立可信的交流渠道。
+
+Linux 内核源代码主要有两种(维护)方式:
+
+- 分布式源仓库 (git)
+- 定期发布快照 (tarballs)
+
+git 仓库和 tarball 都带有创建官方内核版本的内核开发者的 PGP 签名。这
+些签名提供了加密保证,即保证 kernel.org 或任何其他镜像提供的可下载版本
+与这些开发者在其工作站上的版本相同。为此:
+
+- git 仓库在所有标签上提供 PGP 签名
+- tarball 为所有下载提供独立的 PGP 签名
+
+信任开发者,不要信基础设施
+--------------------------
+
+自从 2011 年 kernel.org 核心系统遭到入侵以来,内核存档项目的主要运行原
+则就是假定基础设施的任何部分都可能随时受到入侵。因此,管理员特意采取措施,
+强调必须始终信任开发者,不能信任代码托管基础设施,无论后者的安全实践有多好。
+
+上述指导原则正是需要本指南的原因。希望确保通过对开发者的信任,我们不会简
+单地将未来潜在安全事件的责任归咎于其他人。目的是提供一套指导开发者可以用
+来创建安全的工作环境并保护用于建立 Linux 内核本身完整性的 PGP 密钥。
+
+PGP 工具
+========
+
+使用 GnuPG 2.2 或更高版本
+-------------------------
+
+默认情况下,你的发行版应该已经安装了 GnuPG,你只需要验证你使用的是相当新的
+版本即可。要检查,请运行::
+
+ $ gpg --version | head -n1
+
+如果你有 2.2 或更高版本,那么你就可以开始了。如果你的版本早于 2.2,则本指
+南中的某些命令可能不起作用。
+
+配置 gpg-agent 选项
+~~~~~~~~~~~~~~~~~~~
+
+GnuPG agent是一个辅助工具,每当你使用该命令时,它都会自动启动gpg,并在
+后台运行,目的是缓存私钥密码。你应该知道两个选项,以便调整密码何时从缓存
+过期:
+
+- ``default-cache-ttl`` (秒): 如果在生命周期结束之前再次使用相同的
+ 密钥,倒计时将重置为另一段时间。默认值为 600(10 分钟)。
+- ``max-cache-ttl`` (秒): 无论你自输入初始密码以来多久使用过密钥,
+ 如果最大生存时间倒计时结束,你都必须再次输入密码。默认值为 30 分钟。
+
+如果你发现这些默认值太短(或太长),你可以编辑 ``~/.gnupg/gpg-agent.conf``
+文件以设置你自己的值::
+
+ # 常规ttl设置为30分钟,最大ttl设置为2小时
+ default-cache-ttl 1800
+ max-cache-ttl 7200
+
+.. note::
+
+ 不需要在 shell 会话开始时手动启动 gpg-agent。你可能需要检查
+ rc 文件来删除旧版本 GnuPG 中的所有内容,因为它可能不再做正确
+ 的事情。
+
+保护你的 PGP 密钥
+=================
+
+本指南假定你已经拥有用于 Linux 内核开发目的的 PGP 密钥。如果你还没
+有,请参阅前面提到的 "`保护代码完整性`_" 文档,以获取有关如何创建新
+密钥的指导。
+
+如果你当前的密钥低于 2048 位 (RSA),你还应该创建一个新密钥。
+
+了解 PGP 子密钥
+---------------
+
+PGP 密钥很少由单个密钥对组成 - 通常它是独立子密钥的集合,这些子密钥
+可根据其功能用于不同的目的,并在创建时分配。PGP 定义了密钥可以具有的
+四种功能:
+
+- **[S]** 密钥可用于签名
+- **[E]** 密钥可用于加密
+- **[A]** 密钥可用于身份验证
+- **[C]** 密钥可用于验证其他密钥
+
+具有 **[C]** 功能的密钥通常称为“主”密钥,但该术语具有误导性,因为
+它意味着可以使用Certify密钥来代替同一链上的任何其他子密钥(如物理
+“主密钥”可用于打开为其他钥匙制作的锁)。由于情况并非如此,本指南将
+其称为“认证密钥”以避免任何歧义。
+
+充分理解以下内容至关重要:
+
+1. 所有子项彼此完全独立。如果你丢失了私有子密钥,则无法从链上的任何
+ 其他私钥恢复或重新创建它。
+2. 除 Certify 密钥外,可以有多个具有相同功能的子密钥(例如,你可
+ 以有 2 个有效的加密子密钥、3 个有效的签名子密钥,但只有 1 个有
+ 效的认证子密钥)。所有子密钥都是完全独立的——加密到一个 **[E]**
+ 子密钥的信息(messages)无法使用你可能拥有的任何其他 **[E]**
+ 子密钥解密。
+3. 单个子密钥可能具有多种功能(例如,你的 **[C]** 密钥也可以是你
+ 的 **[S]** 密钥)。
+
+携带 **[C]** (证明)能力的密钥是唯一可以用来指示与其他密钥的关系
+的密钥。仅 **[C]** 密钥可用于:
+
+- 添加或撤销具有 S/E/A 功能的其他密钥(子密钥)
+- 添加、更改或撤销与密钥关联的身份 (uid)
+- 添加或更改其本身或任何子密钥的到期日期
+- 出于信任网络的目的签署其他人的密钥
+
+默认情况下,GnuPG 在生成新密钥时创建以下内容:
+
+- 一个子密钥同时具有认证和签名功能 (**[SC]**)
+- 具有加密功能的单独子密钥 (**[E]**)
+
+如果你在生成密钥时使用了默认参数,那么这就是你将得到的。你可以通过
+运行命令来验证,例如: ``gpg --list-secret-keys``
+
+::
+
+ sec ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
+
+在 ``sec`` 这行下面长长的一行就是你的密钥指纹-无论在下文任何地方
+看到 ``[fpr]`` 都指的是这40个字符。
+
+确保你的密码强度高
+------------------
+
+GnuPG 在将私钥存储到磁盘之前使用密码对其进行加密。这样,即使你的
+``.gnupg`` 目录全部泄露或被盗,攻击者在没有事先获取密码来解密的
+情况下也无法使用你的私钥。
+
+你的私钥受到强密码保护是绝对必要的。要设置或更改它,请使用::
+
+ $ gpg --change-passphrase [fpr]
+
+创建一个单独的签名子密钥
+------------------------
+
+我们的目的是通过将你的证书密钥移动到离线媒介来保护它,因此如果你只
+有组合的 **[SC]** 密钥,那么你应该创建一个单独的签名子密钥::
+
+ $ gpg --quick-addkey [fpr] ed25519 sign
+
+.. note:: GnuPG 中的 ECC 支持
+
+ 请注意,如果你打算使用不支持 ED25519 ECC 密钥的硬件密钥,则
+ 应选择“nistp256”或“ed25519”。请参阅下面有关推荐硬件设备的
+ 部分。
+
+
+备份你的证书密钥以进行灾难恢复
+------------------------------
+
+你的 PGP 密钥上来自其他开发者的签名越多,出于灾难恢复的原因,你就越
+有理由创建一个位于数字媒体之外的备份版本。
+
+创建私钥的可打印硬拷贝的最佳方法是使用 ``paperkey`` 为此目的编写
+的软件。有关输出格式及其相对于其他解决方案的优势的更多详细信息,请参
+阅 ``paperkey`` 参考资料。大多数发行版都应该已经打包了 Paperkey。
+
+运行以下命令来创建私钥的硬拷贝备份::
+
+ $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
+
+打印出该文件(或将输出直接传输到 lpr),然后用笔在纸的边缘写下你的密
+码。 **强烈建议这样做**,因为密钥打印输出仍然使用该密码进行加密,并且
+如果你更改了它,你将不记得创建备份时它曾经是什么 - *保证*。
+
+将生成的打印输出和手写密码放入信封中,并存放在安全且受到良好保护的地
+方,最好远离你的家,例如银行保险柜。
+
+.. note::
+
+ 你的打印机可能不再是连接到并行端口的简单哑设备,但由于输出仍然使
+ 用你的密码进行加密,因此即使“云端打印”的现代打印机也应该保持相
+ 对安全的操作
+
+备份整个 GnuPG 目录
+-------------------
+
+.. warning::
+
+ **!!!不要跳过这个步骤!!!**
+
+如果你需要恢复 PGP 密钥,拥有一个随时可用的备份非常重要。这与我们
+所做的灾难级准备不同 ``paperkey`` 。每当你需要使用你的证书密钥时,
+例如在会议和峰会后更改你自己的密钥或签署其他人的密钥时,你还将依赖
+这些外部副本。
+
+首先获取一个小型 USB “拇指” 驱动器(最好是两个!),用于备份目的。
+你需要使用 LUKS 对其进行加密——请参阅你的发行版文档以了解如何完成
+此操作。
+
+对于加密密码,你可以使用与 PGP 密钥相同的密码。
+
+加密过程完成后,重新插入 USB 驱动器并确保其正确安装。将整个 ``.gnupg``
+目录复制到加密存储::
+
+ $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
+
+你现在应该测试一下,确保一切依然能正常工作::
+
+ $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
+
+如果没有出现任何错误,那么就可以开始了。卸下 USB 驱动器,给它贴上
+明显的标签,这样下次需要使用随机 USB 驱动器时就不会把它吹走,然后
+放在安全的地方 - 但不要太远,因为你每次都需要使用它时不时地用于诸
+如编辑身份、添加或撤销子密钥或签署其他人的密钥之类的事情。
+
+从你的 homedir 中删除 Certify 密钥
+----------------------------------
+
+我们的主目录中的文件并没有我们想象的那么受到保护。它们可以通过多种
+不同的方式泄露或被盗:
+
+- 在制作快速主目录备份以设置新工作站时意外发生
+- 系统管理员的疏忽或恶意
+- 通过不安全的备份
+- 通过桌面应用程序(浏览器、pdf 查看器等)中的恶意软件
+- 跨越国界时通过胁迫
+
+使用良好的密码短语保护你的密钥极大地有助于降低上述任何风险,但密码
+短语可以通过键盘记录器、肩窥或任何其他方式发现。因此,建议的设置是
+从主目录中删除你的证书密钥并将其存储在离线存储中。
+
+.. warning::
+
+ 请参阅上一节并确保你已完整备份 GnuPG 目录。如果你没有可用的
+ 备份,我们要做的事情将使你的密钥毫无用处!
+
+首先,确定你的证书密钥的keygrip::
+
+ $ gpg --with-keygrip --list-key [fpr]
+
+输出将是这样的::
+
+ pub ed25519 2022-12-20 [SC] [expires: 2022-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ Keygrip = 1111000000000000000000000000000000000000
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ sub cv25519 2022-12-20 [E] [expires: 2022-12-19]
+ Keygrip = 2222000000000000000000000000000000000000
+ sub ed25519 2022-12-20 [S]
+ Keygrip = 3333000000000000000000000000000000000000
+
+找到该线 ``pub`` 下方的keygrip项 (位于“认证密钥指纹”的正下方)。
+这将直接对应于你``~/.gnupg`` 目录中的一个文件::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ ls
+ 1111000000000000000000000000000000000000.key
+ 2222000000000000000000000000000000000000.key
+ 3333000000000000000000000000000000000000.key
+
+你所要做的只是删除与证书密钥 keygrip 对应的 .key 文件::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ rm 1111000000000000000000000000000000000000.key
+
+现在,如果你发出命令 ``--list-secret-keys`` ,它将显示证书密钥丢
+失( 表示 ``#`` 它不可用)::
+
+ $ gpg --list-secret-keys
+ sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb cv25519 2022-12-20 [E] [expires: 2024-12-19]
+ ssb ed25519 2022-12-20 [S]
+
+你还应该删除 ``~/.gnupg``目录中的所有 ``secring.gpg`` 文件 ,这些
+文件可能是以前版本的 GnuPG 留下的。
+
+如果你没有“private-keys-v1.d”目录
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+如果你没有 ``~/.gnupg/private-keys-v1.d`` 目录,那么你的密钥仍存
+储在 GnuPG v1 使用的旧文件 ``secring.gpg`` 中。对密钥进行任何更改
+(例如更改密码或添加子密钥)应该会自动转换旧 ``secring.gpg`` 格式以
+供使用 ``private-keys-v1.d`` 。
+
+完成此操作后,请确保删除过时的 ``secring.gpg`` 文件,其中仍然包含你
+的私钥。
+
+
+将子密钥移至专用加密设备
+========================
+
+尽管 Certify 密钥现在不会被泄露或被盗,但子密钥仍然位于你的主目录中。
+任何设法获得这些内容的人都将能够解密你的通信或伪造你的签名(如果他们知
+道密码)。此外,每次执行 GnuPG 操作时,密钥都会加载到系统内存中,并
+可能被足够高级的恶意软件(例如 Meltdown 和 Spectre)从那里窃取。
+
+完全保护密钥的最佳方法是将它们转移到能够进行智能卡操作的专用硬件设备上。
+
+智能卡的好处
+------------
+
+智能卡包含一个加密芯片,能够存储私钥并直接在卡本身上执行加密操作。由于
+密钥内容永远不会离开智能卡,因此插入硬件设备的计算机的操作系统无法自行
+检索私钥。这与我们之前用于备份目的的加密 USB 存储设备有很大不同——当
+USB 设备插入并安装时,操作系统能够访问私钥内容。
+
+使用外部加密 USB 介质并不能替代具有智能卡功能的设备。
+
+可用的智能卡设备
+----------------
+
+除非你的所有笔记本电脑和工作站都有智能卡读卡器,否则最简单的方法是获
+取实现智能卡功能的专用 USB 设备。有多种选择::
+
+- `Nitrokey Start`_: 开放硬件和免费软件,日本基于FSI的 `Gnuk` 。
+ 少数支持 ED25519 ECC 密钥的商用设备之一,但提供的安全功能最少
+ (例如防篡改或某些旁路攻击)。
+- `Nitrokey Pro 2`_: 与 Nitrokey Start 类似,但更防篡改并提供
+ 更多安全功能。Pro 2 支持 ECC 加密 (NISTP)。
+- `Yubikey 5`_: 专有硬件和软件,但比 Nitrokey Pro 便宜,并且以
+ USB-C 形式提供,对于较新的笔记本电脑更有用。提供额外的安全功能,
+ 例如 FIDO U2F 等,现在终于支持 NISTP 和 ED25519 ECC 密钥。
+
+你的选择将取决于成本、你所在地理区域的货运便利性以及开放/专有硬件考虑
+因素。
+
+.. note::
+
+ 如果你位列于 MAINTAINERS 中或在 kernel.org 上拥有帐户,则你有
+ 资格获得Linux 基金会提供的_`qualify for a free Nitrokey Start` 。
+
+.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
+.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nkpr2-nitrokey-pro-2-3
+.. _`Yubikey 5`: https://www.yubico.com/products/yubikey-5-overview/
+.. _Gnuk: https://www.fsij.org/doc-gnuk/
+.. _`qualify for a free Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
+
+配置你的智能卡设备
+------------------
+
+当你将智能卡设备插入任何现代 Linux 工作站时,它就应该可以正常工作
+(TM)。你可以通过运行来验证它::
+
+ $ gpg --card-status
+
+如果你看到完整的智能卡详细信息,那么你就可以开始了。不幸的是,对所有
+可能无法正常工作的原因进行故障排除超出了本指南的范围。如果你在使该卡
+与 GnuPG 配合使用时遇到问题,请通过常规支持渠道寻求帮助。
+
+要配置你的智能卡,你需要使用 GnuPG 菜单系统,因为没有方便的命令行开
+关::
+
+ $ gpg --card-edit
+ [...omitted...]
+ gpg/card> admin
+ Admin commands are allowed
+ gpg/card> passwd
+
+你应该设置用户 PIN (1)、管理员 PIN (3) 和重置代码 (4)。请确保将
+这些信息记录并存储在安全的地方,尤其是管理员 PIN 码和重置代码(它允
+许你完全擦除智能卡)。你很少需要使用管理员 PIN 码,如果你不记录它,
+你将不可避免地忘记它是什么。
+
+回到主卡菜单,你还可以设置其他值(例如姓名、性别、登录数据等),但这
+不是必需的,并且如果你丢失智能卡,还会泄露有关智能卡的信息。
+
+.. note::
+
+ 尽管名称为“PIN”,但卡上的用户 PIN 和管理员 PIN 都不需要是数字。
+
+.. warning::
+
+ 某些设备可能要求你将子密钥移至设备上,然后才能更改密码。请检查设
+ 备制造商提供的文档。
+
+将子密钥移至你的智能卡
+----------------------
+
+退出卡菜单(使用“q”)并保存所有更改。接下来,让我们将子密钥移至智能卡
+上。对于大多数操作,你将需要 PGP 密钥密码和卡的管理员 PIN::
+
+ $ gpg --edit-key [fpr]
+
+ Secret subkeys are available.
+
+ pub ed25519/AAAABBBBCCCCDDDD
+ created: 2022-12-20 expires: 2024-12-19 usage: SC
+ trust: ultimate validity: ultimate
+ ssb cv25519/1111222233334444
+ created: 2022-12-20 expires: never usage: E
+ ssb ed25519/5555666677778888
+ created: 2017-12-07 expires: never usage: S
+ [ultimate] (1). Alice Dev <adev@kernel.org>
+
+ gpg>
+
+使用 ``--edit-key`` 使我们再次进入菜单模式,你会注意到按键列表有点
+不同。从现在开始,所有命令都在此菜单模式内完成,如 所示 ``gpg>``。
+
+首先,让我们选择要放入卡上的密钥 - 你可以通过键入 ``key 1`` (它是
+列表中的第一个, **[E]** 子密钥)来完成此操作:
+
+ gpg> key 1
+
+在输出中,你现在在 **[E]** 子密钥应该看到 ``ssb*`` 。意味着这个子
+密钥当前被选中。它用作切换键,这意味着如果你再次输入 ``key 1`` ,
+``*`` 将会消失并且该键将不再被选择。
+
+现在,让我们将该密钥移至智能卡上::
+
+ gpg> keytocard
+ Please select where to store the key:
+ (2) Encryption key
+ Your selection? 2
+
+由于它是我们的 **[E]** 密钥,因此将其放入加密槽中是有意义的。当你提
+交选择时,系统将首先提示你输入 PGP 密钥密码,然后输入管理员 PIN 码。
+如果命令返回且没有错误,则你的密钥已被移动。
+
+**重要提示**:现在再次键入 ``key 1`` 以取消选择第一个键,并 ``key 2``
+选择 **[S]** 密钥::
+
+ gpg> key 1
+ gpg> key 2
+ gpg> keytocard
+ Please select where to store the key:
+ (1) Signature key
+ (3) Authentication key
+ Your selection? 1
+
+你可以使用 **[S]** 密钥进行签名和身份验证,但我们希望确保它位于签名槽中,
+因此选择 (1)。跟之前一样,如果你的命令返回且没有错误,则操作成功::
+
+ gpg> q
+ Save changes? (y/N) y
+
+保存更改将删除你从主目录移动到卡上的密钥(但这没关系,因为我们还有备份,
+让我们需要替换智能卡时再次执行此操作)。
+
+验证密钥是否已移动
+~~~~~~~~~~~~~~~~~~
+
+如果你现在执行 ``--list-secret-keys`` ,你将看到输出中存在细微的差异::
+
+ $ gpg --list-secret-keys
+ sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19]
+ 000000000000000000000000AAAABBBBCCCCDDDD
+ uid [ultimate] Alice Dev <adev@kernel.org>
+ ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19]
+ ssb> ed25519 2022-12-20 [S]
+
+在 ``ssb>``中的 ``>`` 输出意味着子密钥只能在智能卡上可用,如果你返回
+密钥目录并查看那里的内容,你会注意到 ``.key`` 那里的文件已被存根替换::
+
+ $ cd ~/.gnupg/private-keys-v1.d
+ $ strings *.key | grep 'private-key'
+
+输出应包含 ``shadowed-private-key`` 指示这些文件只是存根,实际内容
+位于智能卡上。
+
+验证智能卡是否正常工作
+~~~~~~~~~~~~~~~~~~~~~~
+
+要验证智能卡是否按预期工作,你可以创建签名::
+
+ $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
+ $ gpg --verify /tmp/test.asc
+
+在你的第一条命令执行时,应该会询问你智能卡的PIN,然后在你运行
+``gpg --verify`` 后显示"Good signature"。
+
+恭喜,你已成功使窃取你的数字开发者身份变得极其困难!
+
+其他常见的 GnuPG 操作
+---------------------
+
+以下是你需要使用 PGP 密钥执行的一些常见操作的快速参考。
+
+安装你的安全离线存储
+~~~~~~~~~~~~~~~~~~~~
+
+你将需要你的证书密钥来执行以下任何操作,因此你首先需要安装备份离线存储
+并告诉 GnuPG 使用它::
+
+ $ export GNUPGHOME=/media/disk/foo/gnupg-backup
+ $ gpg --list-secret-keys
+
+你需要确保你看到 ``sec`` 而不是 ``sec#`` 在输出中( ``#`` 意味着
+密钥不可用并且你仍在使用常规主目录位置)。
+
+延长密钥有效期
+~~~~~~~~~~~~~~
+
+证书密钥的默认到期日期为自创建之日起 2 年。这样做既是出于安全原因,也
+是为了使过时的密钥最终从密钥服务器中消失。
+
+要将密钥的有效期从当前日期延长一年,只需运行::
+
+ $ gpg --quick-set-expire [fpr] 1y
+
+如果更容易记住,你也可以使用特定日期(例如你的生日、1 月 1 日或加拿大
+国庆日)::
+
+ $ gpg --quick-set-expire [fpr] 2025-07-01
+
+请记住将更新后的密钥发送回密钥服务器::
+
+ $ gpg --send-key [fpr]
+
+进行任何更改后更新你的工作目录
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+使用离线存储对密钥进行任何更改后,你需要将这些更改导入回常规工作目录
+中::
+
+ $ gpg --export | gpg --homedir ~/.gnupg --import
+ $ unset GNUPGHOME
+
+通过 ssh 使用 gpg-agent
+~~~~~~~~~~~~~~~~~~~~~~~
+
+如果你需要在远程系统上签署标签或提交,你可以通过 ssh 转发你的
+gpg-agent。
+
+请参考 GnuPG wiki 上提供的说明:
+
+- `Agent通过SSH转发`_
+
+如果你可以修改远程端的 sshd 服务器设置,则工作会更顺利。
+
+.. _`Agent通过SSH转发`: https://wiki.gnupg.org/AgentForwarding
+
+将 PGP 与 Git 结合使用
+======================
+
+Git 的核心功能之一是它的分散性——一旦将仓库克隆到你的系统,你就拥有该
+项目的完整历史记录,包括其所有标签、提交和分支。然而,随着数百个克隆仓
+库的出现,人们如何验证他们的 linux.git 副本没有被恶意第三方篡改?
+
+或者,如果在代码中发现后门,并且提交中的“Author”行表示它是由你完成的,
+而你非常确定 `自己与它无关`_ ,会发生什么?
+
+为了解决这两个问题,Git 引入了 PGP 集成。签名的标签通过确保其内容与创
+建标签的开发人员的工作站上的内容完全相同来证明仓库的完整性,而签名的提
+交使其他人几乎不可能在无法访问你的 PGP 密钥的情况下冒充你。
+
+.. _`自己与它无关`: https://github.com/jayphelps/git-blame-someone-else
+
+配置 git 使用你的 PGP 密钥
+--------------------------
+
+如果你的密钥环中只有一个密钥,那么你实际上不需要执行任何额外操作,因为
+它会成为你的默认密钥。但是,如果你碰巧有多个密钥,你可以告诉 git 应该
+使用哪个密钥(``[fpr]`` 是你密钥的指纹)::
+
+ $ git config --global user.signingKey [fpr]
+
+如何使用签名标签
+----------------
+
+要创建签名标签,只需将 ``-s`` 开关传递给 tag 命令::
+
+ $ git tag -s [tagname]
+
+我们的建议是始终签署 git 标签,因为这可以让其他开发人员确保他们从中提
+取的 git 仓库没有被恶意更改。
+
+如何验证签名标签
+~~~~~~~~~~~~~~~~
+
+要验证签名标签,只需使用以下 ``verify-tag`` 命令::
+
+ $ git verify-tag [tagname]
+
+如果你从项目仓库的另一个分支中拉取标签,git 应该自动验证你拉取的顶
+部的签名,并在合并操作期间向你显示结果::
+
+ $ git pull [url] tags/sometag
+
+合并消息将包含如下内容::
+
+ Merge tag 'sometag' of [url]
+
+ [Tag message]
+
+ # gpg: Signature made [...]
+ # gpg: Good signature from [...]
+
+如果你正在验证其他人的 git 标签,那么你将需要导入他们的 PGP 密钥。
+请参阅下面的":ref:`身份验证`"部分。
+
+配置 git 始终对带注释的标签(annotated tags)进行签名annotated tags
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+如果你要创建带注释的标签,你很可能会想要对其进行签名。要强制 git 始终签
+署带注释的标签,你可以设置一个全局配置选项::
+
+ $ git config --global tag.forceSignAnnotated true
+
+如何使用签名的提交
+------------------
+
+创建签名提交很容易,但在 Linux 内核开发中使用它们要困难得多,因为它依赖
+于发送到邮件列表的补丁,并且此工作流程不保留 PGP 提交签名。此外,当重新
+调整仓库以匹配上游时,甚至你自己的 PGP 提交签名最终也会被丢弃。因此,大
+多数内核开发人员不会费心签署他们的提交,并且会忽略他们在工作中依赖的任何
+外部仓库中的签名提交。
+
+但是,如果你的工作 git 树在某些 git 托管服务(kernel.org、
+infradead.org、ozlabs.org 或其他)上公开可用,那么建议你签署所有 git
+提交,即使上游开发人员不直接受益于这种做法。
+
+我们推荐这样做的原因如下:
+
+1. 如果需要执行代码取证或跟踪代码来源,即使是外部维护的带有 PGP 提交签名
+ 的树对于此类问题也很有价值。
+2. 如果你需要重新克隆本地仓库(例如,在磁盘故障后),这可以让你在恢复工
+ 作之前轻松验证仓库的完整性。
+3. 如果有人需要挑选你的提交,这可以让他们在应用之前快速验证其完整性。
+
+创建签名提交
+~~~~~~~~~~~~
+
+要创建签名提交,你只需将 ``-S`` 标志传递给 ``git commit`` 命令(由于
+与另一个标志冲突,所以它是大写的 ``-S`` )::
+
+ $ git commit -S
+
+配置 git 始终对提交进行签名
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+你可以告诉 git 总是签署提交::
+
+ git config --global commit.gpgSign true
+
+.. note::
+
+ 确保 ``gpg-agent`` 在打开此功能之前进行配置。
+
+.. _身份验证:
+
+
+如何使用签名补丁
+----------------
+
+可以使用你的 PGP 密钥来签署发送到内核开发人员邮件列表的补丁。由于现有的
+电子邮件签名机制(PGP-Mime 或 PGP-inline)往往会导致常规代码审查任务
+出现问题,因此你应该使用为此创建的 kernel.org 工具,该工具将加密证明签
+名放入消息标头中(a-la DKIM):
+
+- `Patatt Patch Attestation`_
+
+.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/
+
+安装和配置 patatt
+~~~~~~~~~~~~~~~~~
+
+Patatt 已针对许多发行版进行了打包,因此请先检查那里。你还可以使用
+“ ``pip install patatt`` ”从 pypi 安装它。
+
+如果你已经使用 git 配置了 PGP 密钥(通过``user.signingKey`` 配置参数),
+则 patatt 不需要进一步配置。你可以通过在所需的仓库中安装 git-send-email
+钩子来开始签署补丁::
+
+ patatt install-hook
+
+现在,你使用 ``git send-email`` 发送的任何补丁都将自动使用你的加密签
+名进行签名
+
+检查 patatt 签名
+~~~~~~~~~~~~~~~~
+
+如果你用于 ``b4`` 检索和应用补丁,那么它将自动尝试验证它遇到的所有
+DKIM 和 patatt 签名,例如::
+
+ $ b4 am 20220720205013.890942-1-broonie@kernel.org
+ [...]
+ Checking attestation on all messages, may take a moment...
+ ---
+ ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
+ ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
+ ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
+ ---
+ ✓ Signed: openpgp/broonie@kernel.org
+ ✓ Signed: DKIM/kernel.org
+
+.. note::
+
+ Patatt 和 b4 仍在积极开发中,你应该检查这些项目的最新文档以了解任
+ 何新功能或更新功能。
+
+如何验证内核开发者身份
+======================
+
+签署标签和提交很容易,但是如何验证用于签署某项内容的密钥是否属于实际的内
+核开发人员而不是恶意冒名顶替者?
+
+使用 WKD 和 DANE 配置auto-key-locate(自动密钥检索)
+----------------------------------------------------
+
+如果你还没有广泛收集其他开发人员的公钥,那么你可以依靠密钥自动发现和自动
+检索来快速启动你的密钥环。如果从头开始创建自己的信任 Web 的预期太令人畏
+惧, GnuPG 可以借助其他委托信任技术(即 DNSSEC 和 TLS)来帮助你继续前
+进。
+
+将以下内容添加到你的 ``~/.gnupg/gpg.conf``::
+
+ auto-key-locate wkd,dane,local
+ auto-key-retrieve
+
+基于 DNS 的命名实体身份验证(“DANE”)是一种在 DNS 中发布公钥并使用
+DNSSEC 签名区域保护它们的方法。Web 密钥目录(“WKD”)是使用 https
+查找来达到相同目的的替代方法。当使用 DANE 或 WKD 查找公钥时,GnuPG
+将分别验证 DNSSEC 或 TLS 证书,然后将自动检索的公钥添加到本地密钥环。
+
+Kernel.org 为所有拥有 kernel.org 帐户的开发人员发布 WKD。一旦你的
+``gpg.conf`` 中进行了上述更改,你就可以自动检索 Linus Torvalds 和
+Greg Kroah-Hartman 的密钥(如果你还没有它们)::
+
+ $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
+
+如果你有 kernel.org 帐户,那么你应该 `添加 kernel.org UID 到你的密钥中`_
+添加到你的密钥中,以使 WKD 对其他内核开发人员更有用。
+
+.. _`添加 kernel.org UID 到你的密钥中`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
+
+信任网 (WOT) 与首次使用信任 (TOFU)
+-----------------------------------
+
+PGP 结合了称为“信任网”的信任委托机制。从本质上讲,这是一次尝试取代
+HTTPS/TLS 世界对集中式证书颁发机构的需求。PGP 将这一责任留给每个
+用户,而不是由各种软件制造商规定谁应该是你值得信赖的认证实体。
+
+不幸的是,很少有人了解信任网是如何运作的。虽然它仍然是 OpenPGP 规
+范的一个重要方面,但最新版本的 GnuPG(2.2 及更高版本)已经实现了
+一种称为“首次使用信任”(TOFU) 的替代机制。你可以将 TOFU 视为“类似
+SSH 的信任方法”。使用 SSH,第一次连接到远程系统时,其密钥指纹会被
+记录并记住。如果将来密钥发生变化,SSH 客户端将向你发出警报并拒绝连
+接,迫使你决定是否选择信任更改后的密钥。同样,第一次导入某人的 PGP
+密钥时,它被认为是有效的。如果将来的任何时候 GnuPG 遇到具有相同标
+识的另一个密钥,则先前导入的密钥和新密钥都将被标记为无效,你将需要手
+动确定保留哪一个。
+
+我们建议你使用 TOFU+PGP 组合信任模型(这是 GnuPG v2 中新默认的)。
+若要设置它,在 ``~/.gnupg/gpg.conf`` 中添加(或修改)
+``trust-model`` 设置::
+
+ trust-model tofu+pgp
+
+使用 kernel.org 信任网仓库
+--------------------------
+
+Kernel.org 维护着一个包含开发人员公钥的 git 仓库,作为复制密钥服
+务器网络的替代品,而在过去几年中,该网络几乎已经陷入黑暗。有关如何将
+该仓库设置为公钥来源的完整文档可以在此处找到:
+
+- `内核开发者密钥环`_
+
+如果你是内核开发人员,请考虑提交你的密钥以将其包含到该密钥环中。
+
+.. _`内核开发者密钥环`: https://korg.docs.kernel.org/pgpkeys.html
diff --git a/Documentation/translations/zh_CN/userspace-api/index.rst b/Documentation/translations/zh_CN/userspace-api/index.rst
index 5dc0f2e69c17..5b14721c8264 100644
--- a/Documentation/translations/zh_CN/userspace-api/index.rst
+++ b/Documentation/translations/zh_CN/userspace-api/index.rst
@@ -17,11 +17,8 @@ Linux 内核用户空间API指南
在代码树中仍然可以找到有关用户空间的部分信息。这个手册意在成为这些信息
聚集的地方。
-.. class:: toc-title
-
- 目录
-
.. toctree::
+ :caption: 目录
:maxdepth: 2
no_new_privs