mirror/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2025-04-09 14:45:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

It has been a reasonably busy cycle for docs...

Browse Source 
- Significant changes throughout the tree to bring Python code up to
   current standards and raise the minimum Python required to 3.9.  Much of
   this is preparatory to replacing the ancient Perl scripts/kernel-doc
   horror with a slightly less horrifying Python implementation, expected
   for 6.16.
 
 - Update the minimum Sphinx required to 3.4.3, allowing us to remove a
   bunch of older compatibility code.
 
 - Rework and improve the generation of the ABI documentation.
 
   (All of the above done by Mauro)
 
 - Lots of translation updates.  Alex Shi and Yanteng Si are taking on
   responsibility for the Chinese translations going forward; that work will
   still get to you via docs-next
 
 - Try to standardize the format for indicating a developer's affiliation in
   commit tags.
 
 - Clarify the TAB's role in CoC enforcement actions.
 
 - Try to spell out the rules for when a commit tag can name another
   developer without their explicit permission.
 
 Plus lots of other typo fixes and updates.
 -----BEGIN PGP SIGNATURE-----
 
 iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmfccxwPHGNvcmJldEBs
 d24ubmV0AAoJEBdDWhNsDH5YoYcH/jL/nS8YAiJ3awF5PH5tR3m5ddt9l+fKXWJx
 PB3KcHtDORbWltTA+Tvo2aP1jxGY9wqsIIvl+nvjJyUcfd72g4HNfTDUDXwP3OFU
 wTkaEAQp3n/hqnLXtJ2AzV3Ir5cIfEL2d7F6QsN1Gnof8iu2OuMk5iMeb0iexUX6
 FYjJq+jknh30VdAp2hxHy8q17R7h7PySh5OsjeAYJJroLv60n3DwQgnzHjXC/FT2
 Qq1UuEzlSpRoso2o2NwVTND6OVW081umo6YrioqD7ZC2G2fhRgLFJJtJGXDNcyUl
 gQv9xLSaTD97V4zaWPm28ObNBpY/GnAd4hMjB17wAH5xUfVS5Aw=
 =Gvdp
 -----END PGP SIGNATURE-----

Merge tag 'docs-6.15' of git://git.lwn.net/linux

Pull documentation updates from Jonathan Corbet:
 "It has been a reasonably busy cycle for docs...

   - Significant changes throughout the tree to bring Python code up to
     current standards and raise the minimum Python required to 3.9

     Much of this is preparatory to replacing the ancient Perl
     scripts/kernel-doc horror with a slightly less horrifying Python
     implementation, expected for 6.16

   - Update the minimum Sphinx required to 3.4.3, allowing us to remove
     a bunch of older compatibility code

   - Rework and improve the generation of the ABI documentation

  (All of the above done by Mauro)

   - Lots of translation updates. Alex Shi and Yanteng Si are taking on
     responsibility for the Chinese translations going forward; that
     work will still get to you via docs-next

   - Try to standardize the format for indicating a developer's
     affiliation in commit tags

   - Clarify the TAB's role in CoC enforcement actions

   - Try to spell out the rules for when a commit tag can name another
     developer without their explicit permission

  Plus lots of other typo fixes and updates"

* tag 'docs-6.15' of git://git.lwn.net/linux: (98 commits)
  docs/zh_CN: fix spelling mistake
  docs/Chinese: change the disclaimer words
  docs/zh_CN: Add snp-tdx-threat-model index Chinese translation
  docs: driver-api: firmware: clarify userspace requirements
  docs: clarify rules wrt tagging other people
  docs: Remove outdated highuid.rst documentation
  Documentation: dma-buf: heaps: Add heap name definitions
  docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README
  docs: Correct installation instruction
  Documentation: kcsan: fix "Plain Accesses and Data Races" URL in kcsan.rst
  Documentation/CoC: Spell out the TAB role in enforcement decisions
  Documentation: ocxl.rst: Update consortium site
  scripts: get_feat.pl: substitute s390x with s390
  scripts/kernel-doc: drop dead code for Wcontents_before_sections
  scripts/kernel-doc: don't add not needed new lines
  docs: driver-api/infiniband.rst: fix Kerneldoc markup
  drivers: firewire: firewire-cdev.h: fix identation on a kernel-doc markup
  drivers: media: intel-ipu3.h: fix identation on a kernel-doc markup
  include/asm-generic/io.h: fix kerneldoc markup
  Docs/arch/arm64: Fix spelling in amu.rst
  ...
This commit is contained in:
Linus Torvalds 2025-03-24 18:42:27 -07:00
commit f81c2b8150
125 changed files with 3802 additions and 1919 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Documentation/ABI/README
View File

@ -1,4 +1,5 @@
This directory attempts to document the ABI between the Linux kernel and
This part of the documentation inside Documentation/ABI directory
attempts to document the ABI between the Linux kernel and
userspace, and the relative stability of these interfaces. Due to the
everchanging nature of Linux, and the differing maturity levels, these
interfaces should be used by userspace programs in different ways.

2
Documentation/ABI/removed/sysfs-class-rfkill
View File

@ -4,7 +4,7 @@ For details to this subsystem look at Documentation/driver-api/rfkill.rst.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file was deprecated because there no longer was a way to
claim just control over a single rfkill instance.

12
Documentation/ABI/stable/sysfs-class-rfkill
View File

@ -16,7 +16,7 @@ Description: The rfkill class subsystem folder.
What: /sys/class/rfkill/rfkill[0-9]+/name
Date: 09-Jul-2007
KernelVersion v2.6.22
KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Name assigned by driver to this key (interface or driver name).
Values: arbitrary string.
@ -24,7 +24,7 @@ Values: arbitrary string.
What: /sys/class/rfkill/rfkill[0-9]+/type
Date: 09-Jul-2007
KernelVersion v2.6.22
KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Driver type string ("wlan", "bluetooth", etc).
Values: See include/linux/rfkill.h.
@ -32,7 +32,7 @@ Values: See include/linux/rfkill.h.
What: /sys/class/rfkill/rfkill[0-9]+/persistent
Date: 09-Jul-2007
KernelVersion v2.6.22
KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Whether the soft blocked state is initialised from non-volatile
storage at startup.
@ -44,7 +44,7 @@ Values: A numeric value:
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
KernelVersion: v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
@ -67,7 +67,7 @@ Values: A numeric value.
What: /sys/class/rfkill/rfkill[0-9]+/hard
Date: 12-March-2010
KernelVersion v2.6.34
KernelVersion: v2.6.34
Contact: linux-wireless@vger.kernel.org
Description: Current hardblock state. This file is read only.
Values: A numeric value.
@ -81,7 +81,7 @@ Values: A numeric value.
What: /sys/class/rfkill/rfkill[0-9]+/soft
Date: 12-March-2010
KernelVersion v2.6.34
KernelVersion: v2.6.34
Contact: linux-wireless@vger.kernel.org
Description: Current softblock state. This file is read and write.
Values: A numeric value.

10
Documentation/ABI/stable/sysfs-devices-system-cpu
View File

@ -24,12 +24,6 @@ Description: Default value for the Data Stream Control Register (DSCR) on
If set by a process it will be inherited by child processes.
Values: 64 bit unsigned integer (bit field)
What: /sys/devices/system/cpu/cpuX/topology/physical_package_id
Description: physical package id of cpuX. Typically corresponds to a physical
socket number, but the actual value is architecture and platform
dependent.
Values: integer
What: /sys/devices/system/cpu/cpuX/topology/die_id
Description: the CPU die ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
@ -86,10 +80,6 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus
Description: internal kernel map of CPUs within the same die.
Values: hexadecimal bitmask.
What: /sys/devices/system/cpu/cpuX/topology/ppin
Description: per-socket protected processor inventory number
Values: hexadecimal.
What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list
Description: human-readable list of CPUs within the same die.
The format is like 0-3, 8-11, 14,17.

4
Documentation/ABI/stable/sysfs-driver-dma-idxd
View File

@ -246,14 +246,14 @@ Description: Controls whether PRS disable is turned on for the workqueue.
capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
Date May 25, 2021
Date: May 25, 2021
KernelVersion: 5.14.0
Contact: dmaengine@vger.kernel.org
Description: Show the current number of entries in this WQ if WQ Occupancy
Support bit WQ capabilities is 1.
What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries
Date Oct 29, 2021
Date: Oct 29, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Indicate the number of retires for an enqcmds submission on a sharedwq.

2
Documentation/ABI/testing/configfs-usb-gadget-midi2
View File

@ -47,7 +47,7 @@ Description:
midi1_first_group The first UMP Group number for MIDI 1.0 (0-15)
midi1_num_groups The number of groups for MIDI 1.0 (0-16)
ui_hint 0: unknown, 1: receiver, 2: sender, 3: both
midi_ci_verison Supported MIDI-CI version number (8 bit)
midi_ci_version Supported MIDI-CI version number (8 bit)
is_midi1 Legacy MIDI 1.0 device (0, 1 or 2)
sysex8_streams Max number of SysEx8 streams (8 bit)
active Active FB flag (0 or 1)

78
Documentation/ABI/testing/sysfs-bus-coresight-devices-cti
View File

@ -1,241 +1,241 @@
What: /sys/bus/coresight/devices/<cti-name>/enable
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable/Disable the CTI hardware.
What: /sys/bus/coresight/devices/<cti-name>/powered
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Indicate if the CTI hardware is powered.
What: /sys/bus/coresight/devices/<cti-name>/ctmid
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Display the associated CTM ID
What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Number of devices connected to triggers on this CTI
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Name of connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Input trigger signals from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Functional types for the input trigger signals
from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Output trigger signals to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Functional types for the output trigger signals
to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Select the index for inen and outen registers.
What: /sys/bus/coresight/devices/<cti-name>/regs/inen
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIINEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/outen
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/gate
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write CTIGATE register.
What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write ASICCTL register.
What: /sys/bus/coresight/devices/<cti-name>/regs/intack
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write the INTACK register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appset
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appclear
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write APPCLEAR register to deactivate channel.
What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Write APPPULSE to pulse a channel active for one clock
cycle.
What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read current status of channel inputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of channel outputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of input trigger signals
What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) read current status of output trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Attach a CTI input trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Detach a CTI input trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Attach a CTI output trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Detach a CTI output trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable CTIGATE for single channel (Write) or list enabled
channels through the gate (R).
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Disable CTIGATE for single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Activate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Deactivate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Pulse a single channel - activate for a single clock cycle.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) List of output triggers filtered across all connections.
What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable or disable trigger output signal filtering.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) show channels with at least one attached trigger signal.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) show channels with no attached trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Write channel number to select a channel to view, read to
see selected channel number.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read to see input triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Read) Read to see output triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date: March 2020
KernelVersion 5.7
KernelVersion: 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (Write) Clear all channel / trigger programming.

52
Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
View File

@ -1,6 +1,6 @@
What: /sys/bus/coresight/devices/<tpdm-name>/integration_test
Date: January 2023
KernelVersion 6.2
KernelVersion: 6.2
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Run integration test for tpdm. Integration test
@ -14,7 +14,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/reset_dataset
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Reset the dataset of the tpdm.
@ -24,7 +24,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_type
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger type of the DSB for tpdm.
@ -35,7 +35,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_ts
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger timestamp of the DSB for tpdm.
@ -46,7 +46,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_mode
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the programming mode of the DSB for tpdm.
@ -60,7 +60,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_idx
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the index number of the edge detection for the DSB
@ -69,7 +69,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_val
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Write a data to control the edge detection corresponding to
@ -85,7 +85,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/ctrl_mask
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Write a data to mask the edge detection corresponding to the index
@ -97,21 +97,21 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcr[0:15]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Read a set of the edge control value of the DSB in TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_edge/edcmr[0:7]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
Read a set of the edge control mask of the DSB in TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpr[0:7]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the trigger pattern for the DSB
@ -119,7 +119,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_trig_patt/xpmr[0:7]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the trigger pattern for the DSB
@ -127,21 +127,21 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:7]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the pattern for the DSB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:7]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the pattern for the DSB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/enable_ts
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern timestamp of DSB tpdm. Read
@ -153,7 +153,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/set_type
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern type of DSB tpdm. Read
@ -165,7 +165,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_msr/msr[0:31]
Date: March 2023
KernelVersion 6.7
KernelVersion: 6.7
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the MSR(mux select register) for the DSB subunit
@ -173,7 +173,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_mode
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description: (Write) Set the data collection mode of CMB tpdm. Continuous
change creates CMB data set elements on every CMBCLK edge.
@ -187,7 +187,7 @@ Description: (Write) Set the data collection mode of CMB tpdm. Continuous
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpr[0:1]
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the trigger pattern for the CMB
@ -195,7 +195,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_patt/xpmr[0:1]
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the trigger pattern for the CMB
@ -203,21 +203,21 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpr[0:1]
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the value of the pattern for the CMB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/dsb_patt/tpmr[0:1]
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the mask of the pattern for the CMB subunit TPDM.
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_patt/enable_ts
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(Write) Set the pattern timestamp of CMB tpdm. Read
@ -229,7 +229,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_trig_ts
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the trigger timestamp of the CMB for tpdm.
@ -240,7 +240,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_ts_all
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Read or write the status of timestamp upon all interface.
@ -252,7 +252,7 @@ Description:
What: /sys/bus/coresight/devices/<tpdm-name>/cmb_msr/msr[0:31]
Date: January 2024
KernelVersion 6.9
KernelVersion: 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Set/Get the MSR(mux select register) for the CMB subunit

4
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -347,7 +347,7 @@ Description: Used to control configure extension list:
- [c] means add/del cold file extension
What: /sys/fs/f2fs/<disk>/unusable
Date April 2019
Date: April 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: If checkpoint=disable, it displays the number of blocks that
are unusable.
@ -355,7 +355,7 @@ Description: If checkpoint=disable, it displays the number of blocks that
would be unusable if checkpoint=disable were to be set.
What: /sys/fs/f2fs/<disk>/encoding
Date July 2019
Date: July 2019
Contact: "Daniel Rosenberg" <drosen@google.com>
Description: Displays name and version of the encoding set for the filesystem.
If no encoding is set, displays (none)

2
Documentation/ABI/testing/sysfs-power
View File

@ -131,7 +131,7 @@ Description:
CAUTION: Using it will cause your machine's real-time (CMOS)
clock to be set to a random invalid time after a resume.
What; /sys/power/pm_trace_dev_match
What: /sys/power/pm_trace_dev_match
Date: October 2010
Contact: James Hogan <jhogan@kernel.org>
Description:

2
Documentation/Makefile
View File

@ -12,7 +12,7 @@ endif
# Check for broken ABI files
ifeq ($(CONFIG_WARN_ABI_ERRORS),y)
$(shell $(srctree)/scripts/get_abi.pl validate --dir $(srctree)/Documentation/ABI)
$(shell $(srctree)/scripts/get_abi.py --dir $(srctree)/Documentation/ABI validate)
endif
# You can set these variables from the command line.

2
Documentation/admin-guide/README.rst
View File

@ -165,7 +165,7 @@ Configuring the kernel
"make xconfig" Qt based configuration tool.
"make gconfig" GTK+ based configuration tool.
"make gconfig" GTK based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about

7
Documentation/admin-guide/abi-obsolete-files.rst Normal file
View File

@ -0,0 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
Obsolete ABI Files
==================
.. kernel-abi:: obsolete
:no-symbols:

6
Documentation/admin-guide/abi-obsolete.rst
View File

@ -1,3 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
ABI obsolete symbols
====================
@ -7,5 +9,5 @@ marked to be removed at some later point in time.
The description of the interface will document the reason why it is
obsolete and when it can be expected to be removed.
.. kernel-abi:: ABI/obsolete
:rst:
.. kernel-abi:: obsolete
:no-files:

7
Documentation/admin-guide/abi-removed-files.rst Normal file
View File

@ -0,0 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
Removed ABI Files
=================
.. kernel-abi:: removed
:no-symbols:

6
Documentation/admin-guide/abi-removed.rst
View File

@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
ABI removed symbols
===================
.. kernel-abi:: ABI/removed
:rst:
.. kernel-abi:: removed
:no-files:

7
Documentation/admin-guide/abi-stable-files.rst Normal file
View File

@ -0,0 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
Stable ABI Files
================
.. kernel-abi:: stable
:no-symbols:

6
Documentation/admin-guide/abi-stable.rst
View File

@ -1,3 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
ABI stable symbols
==================
@ -10,5 +12,5 @@ for at least 2 years.
Most interfaces (like syscalls) are expected to never change and always
be available.
.. kernel-abi:: ABI/stable
:rst:
.. kernel-abi:: stable
:no-files:

7
Documentation/admin-guide/abi-testing-files.rst Normal file
View File

@ -0,0 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
Testing ABI Files
=================
.. kernel-abi:: testing
:no-symbols:

6
Documentation/admin-guide/abi-testing.rst
View File

@ -1,3 +1,5 @@
.. SPDX-License-Identifier: GPL-2.0
ABI testing symbols
===================
@ -16,5 +18,5 @@ Programs that use these interfaces are strongly encouraged to add their
name to the description of these interfaces, so that the kernel
developers can easily notify them if any changes occur.
.. kernel-abi:: ABI/testing
:rst:
.. kernel-abi:: testing
:no-files:

18
Documentation/admin-guide/abi.rst
View File

@ -1,7 +1,14 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
Linux ABI description
=====================
.. kernel-abi:: README
ABI symbols
-----------
.. toctree::
:maxdepth: 2
@ -9,3 +16,14 @@ Linux ABI description
abi-testing
abi-obsolete
abi-removed
ABI files
---------
.. toctree::
:maxdepth: 2
abi-stable-files
abi-testing-files
abi-obsolete-files
abi-removed-files

2
Documentation/admin-guide/gpio/gpio-sim.rst
View File

@ -71,7 +71,7 @@ specific lines. The name of those subdirectories must take the form of:
``'line<offset>'`` (e.g. ``'line0'``, ``'line20'``, etc.) as the name will be
used by the module to assign the config to the specific line at given offset.
Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in
Once the configuration is complete, the ``'live'`` attribute must be set to 1 in
order to instantiate the chip. It can be set back to 0 to destroy the simulated
chip. The module will synchronously wait for the new simulated device to be
successfully probed and if this doesn't happen, writing to ``'live'`` will

2
Documentation/admin-guide/gpio/gpio-virtuser.rst
View File

@ -92,7 +92,7 @@ struct. The first two take string values as arguments:
Activating GPIO consumers
-------------------------
Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in
Once the configuration is complete, the ``'live'`` attribute must be set to 1 in
order to instantiate the consumer. It can be set back to 0 to destroy the
virtual device. The module will synchronously wait for the new simulated device
to be successfully probed and if this doesn't happen, writing to ``'live'`` will

80
Documentation/admin-guide/highuid.rst
View File

@ -1,80 +0,0 @@
===================================================
Notes on the change from 16-bit UIDs to 32-bit UIDs
===================================================
:Author: Chris Wing <wingc@umich.edu>
:Last updated: January 11, 2000
- kernel code MUST take into account __kernel_uid_t and __kernel_uid32_t
when communicating between user and kernel space in an ioctl or data
structure.
- kernel code should use uid_t and gid_t in kernel-private structures and
code.
What's left to be done for 32-bit UIDs on all Linux architectures:
- Disk quotas have an interesting limitation that is not related to the
maximum UID/GID. They are limited by the maximum file size on the
underlying filesystem, because quota records are written at offsets
corresponding to the UID in question.
Further investigation is needed to see if the quota system can cope
properly with huge UIDs. If it can deal with 64-bit file offsets on all
architectures, this should not be a problem.
- Decide whether or not to keep backwards compatibility with the system
accounting file, or if we should break it as the comments suggest
(currently, the old 16-bit UID and GID are still written to disk, and
part of the former pad space is used to store separate 32-bit UID and
GID)
- Need to validate that OS emulation calls the 16-bit UID
compatibility syscalls, if the OS being emulated used 16-bit UIDs, or
uses the 32-bit UID system calls properly otherwise.
This affects at least:
- iBCS on Intel
- sparc32 emulation on sparc64
(need to support whatever new 32-bit UID system calls are added to
sparc32)
- Validate that all filesystems behave properly.
At present, 32-bit UIDs _should_ work for:
- ext2
- ufs
- isofs
- nfs
- coda
- udf
Ioctl() fixups have been made for:
- ncpfs
- smbfs
Filesystems with simple fixups to prevent 16-bit UID wraparound:
- minix
- sysv
- qnx4
Other filesystems have not been checked yet.
- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in
all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but
more are needed. (as well as new user<->kernel data structures)
- The ELF core dump format only supports 16-bit UIDs on arm, i386, m68k,
sh, and sparc32. Fixing this is probably not that important, but would
require adding a new ELF section.
- The ioctl()s used to control the in-kernel NFS server only support
16-bit UIDs on arm, i386, m68k, sh, and sparc32.
- make sure that the UID mapping feature of AX25 networking works properly
(it should be safe because it's always used a 32-bit integer to
communicate between user and kernel)

1
Documentation/admin-guide/index.rst
View File

@ -187,7 +187,6 @@ A few hard-to-categorize and generally obsolete documents.
.. toctree::
:maxdepth: 1
highuid
ldm
unicode

75
Documentation/admin-guide/iostats.rst
View File

@ -2,62 +2,39 @@
I/O statistics fields
=====================
Since 2.4.20 (and some versions before, with patches), and 2.5.45,
more extensive disk statistics have been introduced to help measure disk
activity. Tools such as ``sar`` and ``iostat`` typically interpret these and do
the work for you, but in case you are interested in creating your own
tools, the fields are explained here.
The kernel exposes disk statistics via ``/proc/diskstats`` and
``/sys/block/<device>/stat``. These stats are usually accessed via tools
such as ``sar`` and ``iostat``.
In 2.4 now, the information is found as additional fields in
``/proc/partitions``. In 2.6 and upper, the same information is found in two
places: one is in the file ``/proc/diskstats``, and the other is within
the sysfs file system, which must be mounted in order to obtain
the information. Throughout this document we'll assume that sysfs
is mounted on ``/sys``, although of course it may be mounted anywhere.
Both ``/proc/diskstats`` and sysfs use the same source for the information
and so should not differ.
Here are examples using a disk with two partitions::
Here are examples of these different formats::
/proc/diskstats:
259 0 nvme0n1 255999 814 12369153 47919 996852 81 36123024 425995 0 301795 580470 0 0 0 0 60602 106555
259 1 nvme0n1p1 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0
259 2 nvme0n1p2 255401 1 12343477 47799 996004 0 36014736 425784 0 344336 473584 0 0 0 0 0 0
2.4:
3 0 39082680 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
3 1 9221278 hda1 35486 0 35496 38030 0 0 0 0 0 38030 38030
/sys/block/nvme0n1/stat:
255999 814 12369153 47919 996858 81 36123056 426009 0 301809 580491 0 0 0 0 60605 106562
2.6+ sysfs:
446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
35486 38030 38030 38030
/sys/block/nvme0n1/nvme0n1p1/stat:
492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0
2.6+ diskstats:
3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160
3 1 hda1 35486 38030 38030 38030
Both files contain the same 17 statistics. ``/sys/block/<device>/stat``
contains the fields for ``<device>``. In ``/proc/diskstats`` the fields
are prefixed with the major and minor device numbers and the device
name. In the example above, the first stat value for ``nvme0n1`` is
255999 in both files.
4.18+ diskstats:
3 0 hda 446216 784926 9550688 4382310 424847 312726 5922052 19310380 0 3376340 23705160 0 0 0 0
The sysfs ``stat`` file is efficient for monitoring a small, known set
of disks. If you're tracking a large number of devices,
``/proc/diskstats`` is often the better choice since it avoids the
overhead of opening and closing multiple files for each snapshot.
On 2.4 you might execute ``grep 'hda ' /proc/partitions``. On 2.6+, you have
a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``.
The advantage of one over the other is that the sysfs choice works well
if you are watching a known, small set of disks. ``/proc/diskstats`` may
be a better choice if you are watching a large number of disks because
you'll avoid the overhead of 50, 100, or 500 or more opens/closes with
each snapshot of your disk statistics.
In 2.4, the statistics fields are those after the device name. In
the above example, the first field of statistics would be 446216.
By contrast, in 2.6+ if you look at ``/sys/block/hda/stat``, you'll
find just the 15 fields, beginning with 446216. If you look at
``/proc/diskstats``, the 15 fields will be preceded by the major and
minor device numbers, and device name. Each of these formats provides
15 fields of statistics, each meaning exactly the same things.
All fields except field 9 are cumulative since boot. Field 9 should
go to zero as I/Os complete; all others only increase (unless they
overflow and wrap). Wrapping might eventually occur on a very busy
or long-lived system; so applications should be prepared to deal with
it. Regarding wrapping, the types of the fields are either unsigned
int (32 bit) or unsigned long (32-bit or 64-bit, depending on your
machine) as noted per-field below. Unless your observations are very
spread in time, these fields should not wrap twice before you notice it.
All fields are cumulative, monotonic counters, except for field 9, which
resets to zero as I/Os complete. The remaining fields reset at boot, on
device reattachment or reinitialization, or when the underlying counter
overflows. Applications reading these counters should detect and handle
resets when comparing stat snapshots.
Each set of stats only applies to the indicated device; if you want
system-wide stats you'll have to find all the devices and sum them all up.

2
Documentation/admin-guide/kernel-parameters.txt
View File

@ -6084,7 +6084,7 @@
is assumed to be I/O ports; otherwise it is memory.
reserve_mem= [RAM]
Format: nn[KNG]:<align>:<label>
Format: nn[KMG]:<align>:<label>
Reserve physical memory and label it with a name that
other subsystems can use to access it. This is typically
used for systems that do not wipe the RAM, and this command

2
Documentation/admin-guide/thunderbolt.rst
View File

@ -28,7 +28,7 @@ should be a userspace tool that handles all the low-level details, keeps
a database of the authorized devices and prompts users for new connections.
More details about the sysfs interface for Thunderbolt devices can be
found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``.
found in Documentation/ABI/testing/sysfs-bus-thunderbolt.
Those users who just want to connect any device without any sort of
manual work can add following line to

2
Documentation/admin-guide/workload-tracing.rst
View File

@ -82,7 +82,7 @@ Install tools to build Linux kernel and tools in kernel repository.
scripts/ver_linux is a good way to check if your system already has
the necessary tools::
sudo apt-get build-essentials flex bison yacc
sudo apt-get install build-essential flex bison yacc
sudo apt install libelf-dev systemtap-sdt-dev libslang2-dev libperl-dev libdw-dev
cscope is a good tool to browse kernel sources. Let's install it now::

2
Documentation/arch/arm64/amu.rst
View File

@ -80,7 +80,7 @@ bypass the setting of AMUSERENR_EL0 to trap accesses from EL0 (userspace) to
EL1 (kernel). Therefore, firmware should still ensure accesses to AMU registers
are not trapped in EL2/EL3.
The fixed counters of AMUv1 are accessible though the following system
The fixed counters of AMUv1 are accessible through the following system
register definitions:
- SYS_AMEVCNTR0_CORE_EL0

2
Documentation/arch/arm64/asymmetric-32bit.rst
View File

@ -55,7 +55,7 @@ sysfs
The subset of CPUs capable of running 32-bit tasks is described in
``/sys/devices/system/cpu/aarch32_el0`` and is documented further in
``Documentation/ABI/testing/sysfs-devices-system-cpu``.
Documentation/ABI/testing/sysfs-devices-system-cpu.
**Note:** CPUs are advertised by this file as they are detected and so
late-onlining of 32-bit-capable CPUs can result in the file contents

2
Documentation/conf.py
View File

@ -47,7 +47,7 @@ from load_config import loadConfig
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
needs_sphinx = '2.4.4'
needs_sphinx = '3.4.3'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom

4
Documentation/core-api/min_heap.rst
View File

@ -47,8 +47,8 @@ Example:
#define MIN_HEAP_PREALLOCATED(_type, _name, _nr)
struct _name {
int nr; /* Number of elements in the heap */
int size; /* Maximum number of elements that can be held */
size_t nr; /* Number of elements in the heap */
size_t size; /* Maximum number of elements that can be held */
_type *data; /* Pointer to the heap data */
_type preallocated[_nr]; /* Static preallocated array */
}

2
Documentation/dev-tools/kcsan.rst
View File

@ -203,7 +203,7 @@ they happen concurrently in different threads, and at least one of them is a
least one is a write. For a more thorough discussion and definition, see `"Plain
Accesses and Data Races" in the LKMM`_.
.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt#n1922
.. _"Plain Accesses and Data Races" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/explanation.txt?id=8f6629c004b193d23612641c3607e785819e97ab#n2164
Relationship with the Linux-Kernel Memory Consistency Model (LKMM)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2
Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
View File

@ -40,7 +40,7 @@ properties:
microchip,rx-int-gpios:
description:
GPIO phandle of GPIO connected to to INT1 pin of the MCP251XFD, which
GPIO phandle of GPIO connected to INT1 pin of the MCP251XFD, which
signals a pending RX interrupt.
maxItems: 1

5
Documentation/driver-api/firmware/firmware-usage-guidelines.rst
View File

@ -42,3 +42,8 @@ then of course these rules will not apply strictly.)
deprecating old major versions, then this should only be done as a
last option, and be stated clearly in all communications.
* Firmware files that affect the User API (UAPI) shall not introduce
changes that break existing userspace programs. Updates to such firmware
must ensure backward compatibility with existing userspace applications.
This includes maintaining consistent interfaces and behaviors that
userspace programs rely on.

4
Documentation/driver-api/generic-counter.rst
View File

@ -467,7 +467,7 @@ Counter sysfs
Translates counter data to the standard Counter sysfs interface format
and vice versa.
Please refer to the ``Documentation/ABI/testing/sysfs-bus-counter`` file
Please refer to the Documentation/ABI/testing/sysfs-bus-counter file
for a detailed breakdown of the available Generic Counter interface
sysfs attributes.
@ -483,7 +483,7 @@ Sysfs Interface
Several sysfs attributes are generated by the Generic Counter interface,
and reside under the ``/sys/bus/counter/devices/counterX`` directory,
where ``X`` is to the respective counter device id. Please see
``Documentation/ABI/testing/sysfs-bus-counter`` for detailed information
Documentation/ABI/testing/sysfs-bus-counter for detailed information
on each Generic Counter interface sysfs attribute.
Through these sysfs attributes, programs and scripts may interact with

2
Documentation/driver-api/iio/core.rst
View File

@ -60,7 +60,7 @@ directory. Common attributes are:
* :file:`sampling_frequency_available`, available discrete set of sampling
frequency values for device.
* Available standard attributes for IIO devices are described in the
:file:`Documentation/ABI/testing/sysfs-bus-iio` file in the Linux kernel
:file:Documentation/ABI/testing/sysfs-bus-iio file in the Linux kernel
sources.
IIO device channels

16
Documentation/driver-api/infiniband.rst
View File

@ -77,14 +77,14 @@ iSCSI Extensions for RDMA (iSER)
:internal:
.. kernel-doc:: drivers/infiniband/ulp/iser/iscsi_iser.c
:functions: iscsi_iser_pdu_alloc iser_initialize_task_headers \
iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit \
iscsi_iser_cleanup_task iscsi_iser_check_protection \
iscsi_iser_conn_create iscsi_iser_conn_bind \
iscsi_iser_conn_start iscsi_iser_conn_stop \
iscsi_iser_session_destroy iscsi_iser_session_create \
iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll \
iscsi_iser_ep_disconnect
:functions: iscsi_iser_pdu_alloc iser_initialize_task_headers
iscsi_iser_task_init iscsi_iser_mtask_xmit iscsi_iser_task_xmit
iscsi_iser_cleanup_task iscsi_iser_check_protection
iscsi_iser_conn_create iscsi_iser_conn_bind
iscsi_iser_conn_start iscsi_iser_conn_stop
iscsi_iser_session_destroy iscsi_iser_session_create
iscsi_iser_set_param iscsi_iser_ep_connect iscsi_iser_ep_poll
iscsi_iser_ep_disconnect
.. kernel-doc:: drivers/infiniband/ulp/iser/iser_initiator.c
:internal:

2
Documentation/driver-api/media/drivers/zoran.rst
View File

@ -222,7 +222,7 @@ The CCIR - I uses the PAL colorsystem, and is used in Great Britain, Hong Kong,
Ireland, Nigeria, South Africa.
The CCIR - N uses the PAL colorsystem and PAL frame size but the NTSC framerate,
and is used in Argentinia, Uruguay, an a few others
and is used in Argentina, Uruguay, an a few others
We do not talk about how the audio is broadcast !

2
Documentation/driver-api/media/maintainer-entry-profile.rst
View File

@ -116,7 +116,7 @@ CEC drivers ``cec-compliance``
.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
V4L2 drivers.
Other compilance tools are under development to check other parts of the
Other compliance tools are under development to check other parts of the
subsystem.
Those tests need to pass before the patches go upstream.

6
Documentation/driver-api/nvdimm/nvdimm.rst
View File

@ -535,12 +535,12 @@ internally with a static identifier::
char devname[50];
snprintf(devname, sizeof(devname), "namespace%d.%d",
ndctl_region_get_id(region), paramaters->id);
ndctl_region_get_id(region), parameters->id);
ndctl_namespace_set_alt_name(ndns, devname);
/* 'uuid' must be set prior to setting size! */
ndctl_namespace_set_uuid(ndns, paramaters->uuid);
ndctl_namespace_set_size(ndns, paramaters->size);
ndctl_namespace_set_uuid(ndns, parameters->uuid);
ndctl_namespace_set_size(ndns, parameters->size);
/* unlike pmem namespaces, blk namespaces have a sector size */
if (parameters->lbasize)
ndctl_namespace_set_sector_size(ndns, parameters->lbasize);

2
Documentation/driver-api/pm/devices.rst
View File

@ -358,7 +358,7 @@ the phases are: ``prepare``, ``suspend``, ``suspend_late``, ``suspend_noirq``.
is probed against the device in question by passing them to the
:c:func:`dev_pm_set_driver_flags` helper function.] If the first of
these flags is set, the PM core will not apply the direct-complete
procedure described above to the given device and, consequenty, to any
procedure described above to the given device and, consequently, to any
of its ancestors. The second flag, when set, informs the middle layer
code (bus types, device types, PM domains, classes) that it should take
the return value of the ``->prepare`` callback provided by the driver

2
Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
View File

@ -20,7 +20,7 @@
| openrisc: | TODO |
| parisc: | ok |
| powerpc: | ok |
| riscv: | ok |
| riscv: | TODO |
| s390: | ok |
| sh: | TODO |
| sparc: | TODO |

2
Documentation/features/list-arch.sh
View File

@ -6,6 +6,6 @@
# (If no arguments are given then it will print the host architecture's status.)
#
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/' | sed 's/s390x/s390/')}
$(dirname $0)/../../scripts/get_feat.pl list --arch $ARCH

2
Documentation/filesystems/9p.rst
View File

@ -90,7 +90,7 @@ Just start the 9pfs capable network server like diod/nfs-ganesha e.g.::
$ diod -f -n -d 0 -S -l 0.0.0.0:9999 -e $PWD
Optionaly scan your bus if there are more then one usbg gadgets to find their path::
Optionally scan your bus if there are more then one usbg gadgets to find their path::
$ python $kernel_dir/tools/usb/p9_fwd.py list

4
Documentation/filesystems/bcachefs/SubmittingPatches.rst
View File

@ -30,7 +30,7 @@ CI:
===
Instead of running your tests locally, when running the full test suite it's
prefereable to let a server farm do it in parallel, and then have the results
preferable to let a server farm do it in parallel, and then have the results
in a nice test dashboard (which can tell you which failures are new, and
presents results in a git log view, avoiding the need for most bisecting).
@ -68,7 +68,7 @@ Other things to think about:
land - use them. Use them judiciously, and not as a replacement for proper
error handling, but use them.
- Does it need to be performance tested? Should we add new peformance counters?
- Does it need to be performance tested? Should we add new performance counters?
bcachefs has a set of persistent runtime counters which can be viewed with
the 'bcachefs fs top' command; this should give users a basic idea of what

2
Documentation/filesystems/coda.rst
View File

@ -141,7 +141,7 @@ kernel support.
a process P which accessing a Coda file. It makes a system call which
traps to the OS kernel. Examples of such calls trapping to the kernel
are ``read``, ``write``, ``open``, ``close``, ``create``, ``mkdir``,
``rmdir``, ``chmod`` in a Unix ontext. Similar calls exist in the Win32
``rmdir``, ``chmod`` in a Unix context. Similar calls exist in the Win32
environment, and are named ``CreateFile``.
Generally the operating system handles the request in a virtual

2
Documentation/filesystems/debugfs.rst
View File

@ -220,7 +220,7 @@ There are a couple of other directory-oriented helper functions::
A call to debugfs_change_name() will give a new name to an existing debugfs
file, always in the same directory. The new_name must not exist prior
to the call; the return value is 0 on success and -E... on failuer.
to the call; the return value is 0 on success and -E... on failure.
Symbolic links can be created with debugfs_create_symlink().
There is one important thing that all debugfs users must take into account:

2
Documentation/filesystems/netfs_library.rst
View File

@ -515,7 +515,7 @@ The methods defined in the table are:
the cache to expand a request in either direction. This allows the cache to
size the request appropriately for the cache granularity.
The function is passed poiners to the start and length in its parameters,
The function is passed pointers to the start and length in its parameters,
plus the size of the file for reference, and adjusts the start and length
appropriately. It should return one of:

2
Documentation/filesystems/xfs/xfs-delayed-logging-design.rst
View File

@ -219,7 +219,7 @@ The log is circular, so the positions in the log are defined by the combination
of a cycle number - the number of times the log has been overwritten - and the
offset into the log. A LSN carries the cycle in the upper 32 bits and the
offset in the lower 32 bits. The offset is in units of "basic blocks" (512
bytes). Hence we can do realtively simple LSN based math to keep track of
bytes). Hence we can do relatively simple LSN based math to keep track of
available space in the log.
Log space accounting is done via a pair of constructs called "grant heads". The

2
Documentation/filesystems/xfs/xfs-maintainer-entry-profile.rst
View File

@ -93,7 +93,7 @@ others on a regular basis about burnout.
sponsoring work on any part of XFS.
- **LTS Maintainer**: Someone who backports and tests bug fixes from
uptream to the LTS kernels.
upstream to the LTS kernels.
There tend to be six separate LTS trees at any given time.
The maintainer for a given LTS release should identify themselves with an

4
Documentation/filesystems/xfs/xfs-online-fsck-design.rst
View File

@ -4521,8 +4521,8 @@ Both online and offline repair can use this strategy.
| For this second effort, the ondisk parent pointer format as originally |
| proposed was ``(parent_inum, parent_gen, dirent_pos) → (dirent_name)``. |
| The format was changed during development to eliminate the requirement |
| of repair tools needing to to ensure that the ``dirent_pos`` field |
| always matched when reconstructing a directory. |
| of repair tools needing to ensure that the ``dirent_pos`` field always |
| matched when reconstructing a directory. |
| |
| There were a few other ways to have solved that problem: |
| |

2
Documentation/iio/iio_devbuf.rst
View File

@ -148,5 +148,5 @@ applied), however there are corner cases in which the buffered data may be found
in a processed form. Please note that these corner cases are not addressed by
this documentation.
Please see ``Documentation/ABI/testing/sysfs-bus-iio`` for a complete
Please see Documentation/ABI/testing/sysfs-bus-iio for a complete
description of the attributes.

2
Documentation/input/devices/elantech.rst
View File

@ -556,7 +556,7 @@ Note on debounce:
In case the box has unstable power supply or other electricity issues, or
when number of finger changes, F/W would send "debounce packet" to inform
driver that the hardware is in debounce status.
The debouce packet has the following signature::
The debounce packet has the following signature::
byte 0: 0xc4
byte 1: 0xff

19
Documentation/input/input-programming.rst
View File

@ -346,3 +346,22 @@ driver can handle these events, it has to set the respective bits in evbit,
This callback routine can be called from an interrupt or a BH (although that
isn't a rule), and thus must not sleep, and must not take too long to finish.
Polled input devices
~~~~~~~~~~~~~~~~~~~~
Input polling is set up by passing an input device struct and a callback to
the function::
int input_setup_polling(struct input_dev *dev,
void (*poll_fn)(struct input_dev *dev))
Within the callback, devices should use the regular input_report_* functions
and input_sync as is used by other devices.
There is also the function::
void input_set_poll_interval(struct input_dev *dev, unsigned int interval)
which is used to configure the interval, in milliseconds, that the device will
be polled at.

2
Documentation/mm/split_page_table_lock.rst
View File

@ -4,7 +4,7 @@ Split page table lock
Originally, mm->page_table_lock spinlock protected all page tables of the
mm_struct. But this approach leads to poor page fault scalability of
multi-threaded applications due high contention on the lock. To improve
multi-threaded applications due to high contention on the lock. To improve
scalability, split page table lock was introduced.
With split page table lock we have separate per-table lock to serialize

2
Documentation/networking/statistics.rst
View File

@ -143,7 +143,7 @@ reading multiple stats as it internally performs a full dump of
and reports only the stat corresponding to the accessed file.
Sysfs files are documented in
`Documentation/ABI/testing/sysfs-class-net-statistics`.
Documentation/ABI/testing/sysfs-class-net-statistics.
netlink

2
Documentation/nvme/nvme-pci-endpoint-target.rst
View File

@ -86,7 +86,7 @@ configurable through configfs before starting the controller. To avoid issues
with excessive local memory usage for executing commands, MDTS defaults to 512
KB and is limited to a maximum of 2 MB (arbitrary limit).
Mimimum number of PCI Address Mapping Windows Required
Minimum number of PCI Address Mapping Windows Required
------------------------------------------------------
Most PCI endpoint controllers provide a limited number of mapping windows for

13
Documentation/process/5.Posting.rst
View File

@ -268,10 +268,15 @@ The tags in common use are:
- Cc: the named person received a copy of the patch and had the
opportunity to comment on it.
Be careful in the addition of tags to your patches, as only Cc: is appropriate
for addition without the explicit permission of the person named; using
Reported-by: is fine most of the time as well, but ask for permission if
the bug was reported in private.
Be careful in the addition of the aforementioned tags to your patches, as all
except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the
person named. For those three implicit permission is sufficient if the person
contributed to the Linux kernel using that name and email address according
to the lore archives or the commit history -- and in case of Reported-by:
and Suggested-by: did the reporting or suggestion in public. Note,
bugzilla.kernel.org is a public place in this sense, but email addresses
used there are private; so do not expose them in tags, unless the person
used them in earlier contributions.
Sending the patch

4
Documentation/process/changes.rst
View File

@ -58,11 +58,11 @@ mcelog 0.6 mcelog --version
iptables 1.4.2 iptables -V
openssl & libcrypto 1.0.0 openssl version
bc 1.06.95 bc --version
Sphinx\ [#f1]_ 2.4.4 sphinx-build --version
Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
GNU tar 1.28 tar --version
gtags (optional) 6.6.5 gtags --version
mkimage (optional) 2017.01 mkimage --version
Python (optional) 3.5.x python3 --version
Python (optional) 3.9.x python3 --version
GNU AWK (optional) 5.1.0 gawk --version
====================== =============== ========================================

17
Documentation/process/code-of-conduct-interpretation.rst
View File

@ -145,13 +145,16 @@ kernel community.
Any decisions regarding enforcement recommendations will be brought to
the TAB for implementation of enforcement with the relevant maintainers
if needed. A decision by the Code of Conduct Committee can be overturned
by the TAB by a two-thirds vote.
if needed. Once the TAB approves one or more of the measures outlined
in the scope of the ban by two-thirds of the members voting for the
measures, the Code of Conduct Committee will enforce the TAB approved
measures. Any Code of Conduct Committee members serving on the TAB will
not vote on the measures.
At quarterly intervals, the Code of Conduct Committee and TAB will
provide a report summarizing the anonymised reports that the Code of
Conduct committee has received and their status, as well details of any
overridden decisions including complete and identifiable voting details.
TAB approved decisions including complete and identifiable voting details.
Because how we interpret and enforce the Code of Conduct will evolve over
time, this document will be updated when necessary to reflect any
@ -227,9 +230,11 @@ The scope of the ban for a period of time could include:
such as mailing lists and social media sites
Once the TAB approves one or more of the measures outlined in the scope of
the ban by a two-thirds vote, the Code of Conduct Committee will enforce
the TAB approved measure(s) in collaboration with the community, maintainers,
sub-maintainers, and kernel.org administrators.
the ban by two-thirds of the members voting for the measures, the Code of
Conduct Committee will enforce the TAB approved measure(s) in collaboration
with the community, maintainers, sub-maintainers, and kernel.org
administrators. Any Code of Conduct Committee members serving on the TAB
will not vote on the measures.
The Code of Conduct Committee is mindful of the negative impact of seeking
public apology and instituting ban could have on individuals. It is also

11
Documentation/process/kernel-docs.rst
View File

@ -75,6 +75,17 @@ On-line docs
Published books
---------------
* Title: **The Linux Memory Manager**
:Author: Lorenzo Stoakes
:Publisher: No Starch Press
:Date: February 2025
:Pages: 1300
:ISBN: 978-1718504462
:Notes: Memory management. Full draft available as early access for
pre-order, full release scheduled for Fall 2025. See
https://nostarch.com/linux-memory-manager for further info.
* Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
:Author: Kenneth Hess

12
Documentation/process/submit-checklist.rst
View File

@ -52,7 +52,8 @@ Provide documentation
4) All new module parameters are documented with ``MODULE_PARM_DESC()``
5) All new userspace interfaces are documented in ``Documentation/ABI/``.
See ``Documentation/ABI/README`` for more information.
See Documentation/admin-guide/abi.rst (or ``Documentation/ABI/README``)
for more information.
Patches that change userspace interfaces should be CCed to
linux-api@vger.kernel.org.
@ -91,9 +92,12 @@ Build your code
fix any issues.
2) Builds on multiple CPU architectures by using local cross-compile tools
or some other build farm. Note that ppc64 is a good architecture for
cross-compilation checking because it tends to use ``unsigned long`` for
64-bit quantities.
or some other build farm.
Note that testing against architectures of different word sizes
(32- and 64-bit) and different endianness (big- and little-) is effective
in catching various portability issues due to false assumptions on
representable quantity range, data alignment, or endianness, among
others.
3) Newly-added code has been compiled with ``gcc -W`` (use
``make KCFLAGS=-W``). This will generate lots of noise, but is good

45
Documentation/process/submitting-patches.rst
View File

@ -495,10 +495,10 @@ list archives. A "# Suffix" may also be used in this case to clarify.
If a person has had the opportunity to comment on a patch, but has not
provided such comments, you may optionally add a ``Cc:`` tag to the patch.
This is the only tag which might be added without an explicit action by the
person it names - but it should indicate that this person was copied on the
patch. This tag documents that potentially interested parties
have been included in the discussion.
This tag documents that potentially interested parties have been included in
the discussion. Note, this is one of only three tags you might be able to use
without explicit permission of the person named (see 'Tagging people requires
permission' below for details).
Co-developed-by: states that the patch was co-created by multiple developers;
it is used to give attribution to co-authors (in addition to the author
@ -544,9 +544,9 @@ hopefully inspires them to help us again in the future. The tag is intended for
bugs; please do not use it to credit feature requests. The tag should be
followed by a Closes: tag pointing to the report, unless the report is not
available on the web. The Link: tag can be used instead of Closes: if the patch
fixes a part of the issue(s) being reported. Please note that if the bug was
reported in private, then ask for permission first before using the Reported-by
tag.
fixes a part of the issue(s) being reported. Note, the Reported-by tag is one
of only three tags you might be able to use without explicit permission of the
person named (see 'Tagging people requires permission' below for details).
A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named. This tag informs maintainers that
@ -596,11 +596,11 @@ Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
in the patch changelog (after the '---' separator).
A Suggested-by: tag indicates that the patch idea is suggested by the person
named and ensures credit to the person for the idea. Please note that this
tag should not be added without the reporter's permission, especially if the
idea was not posted in a public forum. That said, if we diligently credit our
idea reporters, they will, hopefully, be inspired to help us again in the
future.
named and ensures credit to the person for the idea: if we diligently credit
our idea reporters, they will, hopefully, be inspired to help us again in the
future. Note, this is one of only three tags you might be able to use without
explicit permission of the person named (see 'Tagging people requires
permission' below for details).
A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
is used to make it easy to determine where a bug originated, which can help
@ -618,6 +618,21 @@ Finally, while providing tags is welcome and typically very appreciated, please
note that signers (i.e. submitters and maintainers) may use their discretion in
applying offered tags.
.. _tagging_people:
Tagging people requires permission
----------------------------------
Be careful in the addition of the aforementioned tags to your patches, as all
except for Cc:, Reported-by:, and Suggested-by: need explicit permission of the
person named. For those three implicit permission is sufficient if the person
contributed to the Linux kernel using that name and email address according
to the lore archives or the commit history -- and in case of Reported-by:
and Suggested-by: did the reporting or suggestion in public. Note,
bugzilla.kernel.org is a public place in this sense, but email addresses
used there are private; so do not expose them in tags, unless the person
used them in earlier contributions.
.. _the_canonical_patch_format:
The canonical patch format
@ -717,6 +732,12 @@ patch in the permanent changelog. If the ``from`` line is missing,
then the ``From:`` line from the email header will be used to determine
the patch author in the changelog.
The author may indicate their affiliation or the sponsor of the work
by adding the name of an organization to the ``from`` and ``SoB`` lines,
e.g.:
From: Patch Author (Company) <author@example.com>
Explanation Body
^^^^^^^^^^^^^^^^

2
Documentation/scheduler/sched-bwc.rst
View File

@ -59,7 +59,7 @@ At the same time, we can say that the worst case deadline miss, will be
\Sum e_i; that is, there is a bounded tardiness (under the assumption
that x+e is indeed WCET).
The interferenece when using burst is valued by the possibilities for
The interference when using burst is valued by the possibilities for
missing the deadline and the average WCET. Test results showed that when
there many cgroups or CPU is under utilized, the interference is
limited. More details are shown in:

2
Documentation/sound/soc/machine.rst
View File

@ -75,7 +75,7 @@ In the above struct, dai’s are registered using names but you can pass
either dai name or device tree node but not both. Also, names used here
for cpu/codec/platform dais should be globally unique.
Additionaly below example macro can be used to register cpu, codec and
Additionally below example macro can be used to register cpu, codec and
platform dai::
SND_SOC_DAILINK_DEFS(wm2200_cpu_dsp,

82
Documentation/sphinx/automarkup.py
View File

@ -11,13 +11,7 @@ from sphinx.errors import NoUri
import re
from itertools import chain
#
# Python 2 lacks re.ASCII...
#
try:
ascii_p3 = re.ASCII
except AttributeError:
ascii_p3 = 0
from kernel_abi import get_kernel_abi
#
# Regex nastiness. Of course.
@ -26,28 +20,30 @@ except AttributeError:
# :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last
# bit tries to restrict matches to things that won't create trouble.
#
RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3)
RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII)
#
# Sphinx 2 uses the same :c:type role for struct, union, enum and typedef
#
RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)',
flags=ascii_p3)
flags=re.ASCII)
#
# Sphinx 3 uses a different C role for each one of struct, union, enum and
# typedef
#
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3)
RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII)
#
# Detects a reference to a documentation page of the form Documentation/... with
# an optional extension
#
RE_doc = re.compile(r'(\bDocumentation/)?((\.\./)*[\w\-/]+)\.(rst|txt)')
RE_abi_file = re.compile(r'(\bDocumentation/ABI/[\w\-/]+)')
RE_abi_symbol = re.compile(r'(\b/(sys|config|proc)/[\w\-/]+)')
RE_namespace = re.compile(r'^\s*..\s*c:namespace::\s*(\S+)\s*$')
@ -83,11 +79,10 @@ def markup_refs(docname, app, node):
#
# Associate each regex with the function that will markup its matches
#
markup_func_sphinx2 = {RE_doc: markup_doc_ref,
RE_function: markup_c_ref,
RE_generic_type: markup_c_ref}
markup_func_sphinx3 = {RE_doc: markup_doc_ref,
markup_func = {RE_doc: markup_doc_ref,
RE_abi_file: markup_abi_file_ref,
RE_abi_symbol: markup_abi_ref,
RE_function: markup_func_ref_sphinx3,
RE_struct: markup_c_ref,
RE_union: markup_c_ref,
@ -95,11 +90,6 @@ def markup_refs(docname, app, node):
RE_typedef: markup_c_ref,
RE_git: markup_git}
if sphinx.version_info[0] >= 3:
markup_func = markup_func_sphinx3
else:
markup_func = markup_func_sphinx2
match_iterators = [regex.finditer(t) for regex in markup_func]
#
# Sort all references by the starting position in text
@ -270,6 +260,54 @@ def markup_doc_ref(docname, app, match):
else:
return nodes.Text(match.group(0))
#
# Try to replace a documentation reference for ABI symbols and files
# with a cross reference to that page
#
def markup_abi_ref(docname, app, match, warning=False):
stddom = app.env.domains['std']
#
# Go through the dance of getting an xref out of the std domain
#
kernel_abi = get_kernel_abi()
fname = match.group(1)
target = kernel_abi.xref(fname)
# Kernel ABI doesn't describe such file or symbol
if not target:
if warning:
kernel_abi.log.warning("%s not found", fname)
return nodes.Text(match.group(0))
pxref = addnodes.pending_xref('', refdomain = 'std', reftype = 'ref',
reftarget = target, modname = None,
classname = None, refexplicit = False)
#
# XXX The Latex builder will throw NoUri exceptions here,
# work around that by ignoring them.
#
try:
xref = stddom.resolve_xref(app.env, docname, app.builder, 'ref',
target, pxref, None)
except NoUri:
xref = None
#
# Return the xref if we got it; otherwise just return the plain text.
#
if xref:
return xref
else:
return nodes.Text(match.group(0))
#
# Variant of markup_abi_ref() that warns whan a reference is not found
#
def markup_abi_file_ref(docname, app, match):
return markup_abi_ref(docname, app, match, warning=True)
def get_c_namespace(app, docname):
source = app.env.doc2path(docname)
with open(source) as f:

7
Documentation/sphinx/cdomain.py
View File

@ -1,6 +1,6 @@
# -*- coding: utf-8; mode: python -*-
# pylint: disable=W0141,C0113,C0103,C0325
u"""
"""
cdomain
~~~~~~~
@ -45,9 +45,6 @@ import re
__version__ = '1.1'
# Get Sphinx version
major, minor, patch = sphinx.version_info[:3]
# Namespace to be prepended to the full name
namespace = None
@ -145,7 +142,7 @@ class CObject(Base_CObject):
}
def handle_func_like_macro(self, sig, signode):
u"""Handles signatures of function-like macros.
"""Handles signatures of function-like macros.
If the objtype is 'function' and the signature ``sig`` is a
function-like macro, the name of the macro is returned. Otherwise

164
Documentation/sphinx/kernel_abi.py
View File

@ -2,7 +2,7 @@
# coding=utf-8
# SPDX-License-Identifier: GPL-2.0
#
u"""
"""
kernel-abi
~~~~~~~~~~
@ -14,7 +14,7 @@ u"""
:license: GPL Version 2, June 1991 see Linux/COPYING for details.
The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the
scripts/get_abi.pl script to parse the Kernel ABI files.
scripts/get_abi.py script to parse the Kernel ABI files.
Overview of directive's argument and options.
@ -32,107 +32,137 @@ u"""
"""
import codecs
import os
import subprocess
import sys
import re
import kernellog
import sys
from docutils import nodes, statemachine
from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
from docutils.utils.error_reporting import ErrorString
from sphinx.util.docutils import switch_source_input
from sphinx.util import logging
__version__ = '1.0'
srctree = os.path.abspath(os.environ["srctree"])
sys.path.insert(0, os.path.join(srctree, "scripts/lib/abi"))
from abi_parser import AbiParser
__version__ = "1.0"
logger = logging.getLogger('kernel_abi')
path = os.path.join(srctree, "Documentation/ABI")
_kernel_abi = None
def get_kernel_abi():
"""
Initialize kernel_abi global var, if not initialized yet.
This is needed to avoid warnings during Sphinx module initialization.
"""
global _kernel_abi
if not _kernel_abi:
# Parse ABI symbols only once
_kernel_abi = AbiParser(path, logger=logger)
_kernel_abi.parse_abi()
_kernel_abi.check_issues()
return _kernel_abi
def setup(app):
app.add_directive("kernel-abi", KernelCmd)
return dict(
version = __version__
, parallel_read_safe = True
, parallel_write_safe = True
)
return {
"version": __version__,
"parallel_read_safe": True,
"parallel_write_safe": True
}
class KernelCmd(Directive):
u"""KernelABI (``kernel-abi``) directive"""
"""KernelABI (``kernel-abi``) directive"""
required_arguments = 1
optional_arguments = 2
optional_arguments = 3
has_content = False
final_argument_whitespace = True
parser = None
option_spec = {
"debug" : directives.flag,
"rst" : directives.unchanged
"debug": directives.flag,
"no-symbols": directives.flag,
"no-files": directives.flag,
}
def run(self):
kernel_abi = get_kernel_abi()
doc = self.state.document
if not doc.settings.file_insertion_enabled:
raise self.warning("docutils: file insertion disabled")
srctree = os.path.abspath(os.environ["srctree"])
args = [
os.path.join(srctree, 'scripts/get_abi.pl'),
'rest',
'--enable-lineno',
'--dir', os.path.join(srctree, 'Documentation', self.arguments[0]),
]
if 'rst' in self.options:
args.append('--rst-source')
lines = subprocess.check_output(args, cwd=os.path.dirname(doc.current_source)).decode('utf-8')
nodeList = self.nestedParse(lines, self.arguments[0])
return nodeList
def nestedParse(self, lines, fname):
env = self.state.document.settings.env
content = ViewList()
node = nodes.section()
if "debug" in self.options:
code_block = "\n\n.. code-block:: rst\n :linenos:\n"
for l in lines.split("\n"):
code_block += "\n " + l
lines = code_block + "\n\n"
abi_type = self.arguments[0]
line_regex = re.compile(r"^\.\. LINENO (\S+)\#([0-9]+)$")
ln = 0
if "no-symbols" in self.options:
show_symbols = False
else:
show_symbols = True
if "no-files" in self.options:
show_file = False
else:
show_file = True
tab_width = self.options.get('tab-width',
self.state.document.settings.tab_width)
old_f = None
n = 0
f = fname
for line in lines.split("\n"):
n = n + 1
match = line_regex.search(line)
if match:
new_f = match.group(1)
# Sphinx parser is lazy: it stops parsing contents in the
# middle, if it is too big. So, handle it per input file
if new_f != f and content:
self.do_parse(content, node)
content = ViewList()
# Add the file to Sphinx build dependencies
env.note_dependency(os.path.abspath(f))
f = new_f
# sphinx counts lines from 0
ln = int(match.group(2)) - 1
n_sym = 0
for msg, f, ln in kernel_abi.doc(show_file=show_file,
show_symbols=show_symbols,
filter_path=abi_type):
n_sym += 1
msg_list = statemachine.string2lines(msg, tab_width,
convert_whitespace=True)
if "debug" in self.options:
lines = [
"", "", ".. code-block:: rst",
" :linenos:", ""
]
for m in msg_list:
lines.append(" " + m)
else:
content.append(line, f, ln)
lines = msg_list
kernellog.info(self.state.document.settings.env.app, "%s: parsed %i lines" % (fname, n))
for line in lines:
# sphinx counts lines from 0
content.append(line, f, ln - 1)
n += 1
if content:
self.do_parse(content, node)
if f != old_f:
# Add the file to Sphinx build dependencies
env.note_dependency(os.path.abspath(f))
old_f = f
# Sphinx doesn't like to parse big messages. So, let's
# add content symbol by symbol
if content:
self.do_parse(content, node)
content = ViewList()
if show_symbols and not show_file:
logger.verbose("%s ABI: %i symbols (%i ReST lines)" % (abi_type, n_sym, n))
elif not show_symbols and show_file:
logger.verbose("%s ABI: %i files (%i ReST lines)" % (abi_type, n_sym, n))
else:
logger.verbose("%s ABI: %i data (%i ReST lines)" % (abi_type, n_sym, n))
return node.children

4
Documentation/sphinx/kernel_feat.py
View File

@ -1,7 +1,7 @@
# coding=utf-8
# SPDX-License-Identifier: GPL-2.0
#
u"""
"""
kernel-feat
~~~~~~~~~~~
@ -56,7 +56,7 @@ def setup(app):
class KernelFeat(Directive):
u"""KernelFeat (``kernel-feat``) directive"""
"""KernelFeat (``kernel-feat``) directive"""
required_arguments = 1
optional_arguments = 2

4
Documentation/sphinx/kernel_include.py
View File

@ -2,7 +2,7 @@
# -*- coding: utf-8; mode: python -*-
# pylint: disable=R0903, C0330, R0914, R0912, E0401
u"""
"""
kernel-include
~~~~~~~~~~~~~~
@ -56,7 +56,7 @@ def setup(app):
class KernelInclude(Include):
# ==============================================================================
u"""KernelInclude (``kernel-include``) directive"""
"""KernelInclude (``kernel-include``) directive"""
def run(self):
env = self.state.document.settings.env

19
Documentation/sphinx/kerneldoc.py
View File

@ -39,7 +39,7 @@ from docutils.statemachine import ViewList
from docutils.parsers.rst import directives, Directive
import sphinx
from sphinx.util.docutils import switch_source_input
import kernellog
from sphinx.util import logging
__version__ = '1.0'
@ -56,16 +56,12 @@ class KernelDocDirective(Directive):
'functions': directives.unchanged,
}
has_content = False
logger = logging.getLogger('kerneldoc')
def run(self):
env = self.state.document.settings.env
cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
# Pass the version string to kernel-doc, as it needs to use a different
# dialect, depending what the C domain supports for each specific
# Sphinx versions
cmd += ['-sphinx-version', sphinx.__version__]
filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
export_file_patterns = []
@ -109,8 +105,7 @@ class KernelDocDirective(Directive):
cmd += [filename]
try:
kernellog.verbose(env.app,
'calling kernel-doc \'%s\'' % (" ".join(cmd)))
self.logger.verbose("calling kernel-doc '%s'" % (" ".join(cmd)))
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
out, err = p.communicate()
@ -120,8 +115,8 @@ class KernelDocDirective(Directive):
if p.returncode != 0:
sys.stderr.write(err)
kernellog.warn(env.app,
'kernel-doc \'%s\' failed with return code %d' % (" ".join(cmd), p.returncode))
self.logger.warning("kernel-doc '%s' failed with return code %d"
% (" ".join(cmd), p.returncode))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
elif env.config.kerneldoc_verbosity > 0:
sys.stderr.write(err)
@ -148,8 +143,8 @@ class KernelDocDirective(Directive):
return node.children
except Exception as e: # pylint: disable=W0703
kernellog.warn(env.app, 'kernel-doc \'%s\' processing failed with: %s' %
(" ".join(cmd), str(e)))
self.logger.warning("kernel-doc '%s' processing failed with: %s" %
(" ".join(cmd), str(e)))
return [nodes.error(None, nodes.paragraph(text = "kernel-doc missing"))]
def do_parse(self, result, node):

22
Documentation/sphinx/kernellog.py
View File

@ -1,22 +0,0 @@
# SPDX-License-Identifier: GPL-2.0
#
# Sphinx has deprecated its older logging interface, but the replacement
# only goes back to 1.6. So here's a wrapper layer to keep around for
# as long as we support 1.4.
#
# We don't support 1.4 anymore, but we'll keep the wrappers around until
# we change all the code to not use them anymore :)
#
import sphinx
from sphinx.util import logging
logger = logging.getLogger('kerneldoc')
def warn(app, message):
logger.warning(message)
def verbose(app, message):
logger.verbose(message)
def info(app, message):
logger.info(message)

91
Documentation/sphinx/kfigure.py
View File

@ -1,6 +1,6 @@
# -*- coding: utf-8; mode: python -*-
# pylint: disable=C0103, R0903, R0912, R0915
u"""
"""
scalable figure and image handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -59,12 +59,14 @@ from docutils.parsers.rst import directives
from docutils.parsers.rst.directives import images
import sphinx
from sphinx.util.nodes import clean_astext
import kernellog
from sphinx.util import logging
Figure = images.Figure
__version__ = '1.0.0'
logger = logging.getLogger('kfigure')
# simple helper
# -------------
@ -163,14 +165,14 @@ def setup(app):
def setupTools(app):
u"""
"""
Check available build tools and log some *verbose* messages.
This function is called once, when the builder is initiated.
"""
global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603
global inkscape_cmd, inkscape_ver_one # pylint: disable=W0603
kernellog.verbose(app, "kfigure: check installed tools ...")
logger.verbose("kfigure: check installed tools ...")
dot_cmd = which('dot')
convert_cmd = which('convert')
@ -178,7 +180,7 @@ def setupTools(app):
inkscape_cmd = which('inkscape')
if dot_cmd:
kernellog.verbose(app, "use dot(1) from: " + dot_cmd)
logger.verbose("use dot(1) from: " + dot_cmd)
try:
dot_Thelp_list = subprocess.check_output([dot_cmd, '-Thelp'],
@ -190,10 +192,11 @@ def setupTools(app):
dot_Tpdf_ptn = b'pdf'
dot_Tpdf = re.search(dot_Tpdf_ptn, dot_Thelp_list)
else:
kernellog.warn(app, "dot(1) not found, for better output quality install "
"graphviz from https://www.graphviz.org")
logger.warning(
"dot(1) not found, for better output quality install graphviz from https://www.graphviz.org"
)
if inkscape_cmd:
kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd)
logger.verbose("use inkscape(1) from: " + inkscape_cmd)
inkscape_ver = subprocess.check_output([inkscape_cmd, '--version'],
stderr=subprocess.DEVNULL)
ver_one_ptn = b'Inkscape 1'
@ -204,26 +207,27 @@ def setupTools(app):
else:
if convert_cmd:
kernellog.verbose(app, "use convert(1) from: " + convert_cmd)
logger.verbose("use convert(1) from: " + convert_cmd)
else:
kernellog.verbose(app,
logger.verbose(
"Neither inkscape(1) nor convert(1) found.\n"
"For SVG to PDF conversion, "
"install either Inkscape (https://inkscape.org/) (preferred) or\n"
"ImageMagick (https://www.imagemagick.org)")
"For SVG to PDF conversion, install either Inkscape (https://inkscape.org/) (preferred) or\n"
"ImageMagick (https://www.imagemagick.org)"
)
if rsvg_convert_cmd:
kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd)
kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion")
logger.verbose("use rsvg-convert(1) from: " + rsvg_convert_cmd)
logger.verbose("use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion")
dot_Tpdf = False
else:
kernellog.verbose(app,
logger.verbose(
"rsvg-convert(1) not found.\n"
" SVG rendering of convert(1) is done by ImageMagick-native renderer.")
" SVG rendering of convert(1) is done by ImageMagick-native renderer."
)
if dot_Tpdf:
kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion")
logger.verbose("use 'dot -Tpdf' for DOT -> PDF conversion")
else:
kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion")
logger.verbose("use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion")
# integrate conversion tools
@ -257,13 +261,12 @@ def convert_image(img_node, translator, src_fname=None):
# in kernel builds, use 'make SPHINXOPTS=-v' to see verbose messages
kernellog.verbose(app, 'assert best format for: ' + img_node['uri'])
logger.verbose('assert best format for: ' + img_node['uri'])
if in_ext == '.dot':
if not dot_cmd:
kernellog.verbose(app,
"dot from graphviz not available / include DOT raw.")
logger.verbose("dot from graphviz not available / include DOT raw.")
img_node.replace_self(file2literal(src_fname))
elif translator.builder.format == 'latex':
@ -290,10 +293,11 @@ def convert_image(img_node, translator, src_fname=None):
if translator.builder.format == 'latex':
if not inkscape_cmd and convert_cmd is None:
kernellog.warn(app,
"no SVG to PDF conversion available / include SVG raw."
"\nIncluding large raw SVGs can cause xelatex error."
"\nInstall Inkscape (preferred) or ImageMagick.")
logger.warning(
"no SVG to PDF conversion available / include SVG raw.\n"
"Including large raw SVGs can cause xelatex error.\n"
"Install Inkscape (preferred) or ImageMagick."
)
img_node.replace_self(file2literal(src_fname))
else:
dst_fname = path.join(translator.builder.outdir, fname + '.pdf')
@ -306,15 +310,14 @@ def convert_image(img_node, translator, src_fname=None):
_name = dst_fname[len(str(translator.builder.outdir)) + 1:]
if isNewer(dst_fname, src_fname):
kernellog.verbose(app,
"convert: {out}/%s already exists and is newer" % _name)
logger.verbose("convert: {out}/%s already exists and is newer" % _name)
else:
ok = False
mkdir(path.dirname(dst_fname))
if in_ext == '.dot':
kernellog.verbose(app, 'convert DOT to: {out}/' + _name)
logger.verbose('convert DOT to: {out}/' + _name)
if translator.builder.format == 'latex' and not dot_Tpdf:
svg_fname = path.join(translator.builder.outdir, fname + '.svg')
ok1 = dot2format(app, src_fname, svg_fname)
@ -325,7 +328,7 @@ def convert_image(img_node, translator, src_fname=None):
ok = dot2format(app, src_fname, dst_fname)
elif in_ext == '.svg':
kernellog.verbose(app, 'convert SVG to: {out}/' + _name)
logger.verbose('convert SVG to: {out}/' + _name)
ok = svg2pdf(app, src_fname, dst_fname)
if not ok:
@ -354,7 +357,7 @@ def dot2format(app, dot_fname, out_fname):
with open(out_fname, "w") as out:
exit_code = subprocess.call(cmd, stdout = out)
if exit_code != 0:
kernellog.warn(app,
logger.warning(
"Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
return bool(exit_code == 0)
@ -388,13 +391,14 @@ def svg2pdf(app, svg_fname, pdf_fname):
pass
if exit_code != 0:
kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
logger.warning("Error #%d when calling: %s" %
(exit_code, " ".join(cmd)))
if warning_msg:
kernellog.warn(app, "Warning msg from %s: %s"
% (cmd_name, str(warning_msg, 'utf-8')))
logger.warning( "Warning msg from %s: %s" %
(cmd_name, str(warning_msg, 'utf-8')))
elif warning_msg:
kernellog.verbose(app, "Warning msg from %s (likely harmless):\n%s"
% (cmd_name, str(warning_msg, 'utf-8')))
logger.verbose("Warning msg from %s (likely harmless):\n%s" %
(cmd_name, str(warning_msg, 'utf-8')))
return bool(exit_code == 0)
@ -418,7 +422,8 @@ def svg2pdf_by_rsvg(app, svg_fname, pdf_fname):
# use stdout and stderr from parent
exit_code = subprocess.call(cmd)
if exit_code != 0:
kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd)))
logger.warning("Error #%d when calling: %s" %
(exit_code, " ".join(cmd)))
ok = bool(exit_code == 0)
return ok
@ -440,7 +445,7 @@ class kernel_image(nodes.image):
pass
class KernelImage(images.Image):
u"""KernelImage directive
"""KernelImage directive
Earns everything from ``.. image::`` directive, except *remote URI* and
*glob* pattern. The KernelImage wraps a image node into a
@ -476,7 +481,7 @@ class kernel_figure(nodes.figure):
"""Node for ``kernel-figure`` directive."""
class KernelFigure(Figure):
u"""KernelImage directive
"""KernelImage directive
Earns everything from ``.. figure::`` directive, except *remote URI* and
*glob* pattern. The KernelFigure wraps a figure node into a kernel_figure
@ -513,15 +518,15 @@ def visit_kernel_render(self, node):
app = self.builder.app
srclang = node.get('srclang')
kernellog.verbose(app, 'visit kernel-render node lang: "%s"' % (srclang))
logger.verbose('visit kernel-render node lang: "%s"' % srclang)
tmp_ext = RENDER_MARKUP_EXT.get(srclang, None)
if tmp_ext is None:
kernellog.warn(app, 'kernel-render: "%s" unknown / include raw.' % (srclang))
logger.warning( 'kernel-render: "%s" unknown / include raw.' % srclang)
return
if not dot_cmd and tmp_ext == '.dot':
kernellog.verbose(app, "dot from graphviz not available / include raw.")
logger.verbose("dot from graphviz not available / include raw.")
return
literal_block = node[0]
@ -552,7 +557,7 @@ class kernel_render(nodes.General, nodes.Inline, nodes.Element):
pass
class KernelRender(Figure):
u"""KernelRender directive
"""KernelRender directive
Render content by external tool. Has all the options known from the
*figure* directive, plus option ``caption``. If ``caption`` has a

2
Documentation/sphinx/load_config.py
View File

@ -9,7 +9,7 @@ from sphinx.util.osutil import fs_encoding
def loadConfig(namespace):
# ------------------------------------------------------------------------------
u"""Load an additional configuration file into *namespace*.
"""Load an additional configuration file into *namespace*.
The name of the configuration file is taken from the environment
``SPHINX_CONF``. The external configuration file extends (or overwrites) the

4
Documentation/sphinx/maintainers_include.py
View File

@ -3,7 +3,7 @@
# -*- coding: utf-8; mode: python -*-
# pylint: disable=R0903, C0330, R0914, R0912, E0401
u"""
"""
maintainers-include
~~~~~~~~~~~~~~~~~~~
@ -37,7 +37,7 @@ def setup(app):
)
class MaintainersInclude(Include):
u"""MaintainersInclude (``maintainers-include``) directive"""
"""MaintainersInclude (``maintainers-include``) directive"""
required_arguments = 0
def parse_maintainers(self, path):

10
Documentation/sphinx/rstFlatTable.py
View File

@ -2,7 +2,7 @@
# -*- coding: utf-8; mode: python -*-
# pylint: disable=C0330, R0903, R0912
u"""
"""
flat-table
~~~~~~~~~~
@ -99,7 +99,7 @@ class colSpan(nodes.General, nodes.Element): pass # pylint: disable=C0103,C0321
class FlatTable(Table):
# ==============================================================================
u"""FlatTable (``flat-table``) directive"""
"""FlatTable (``flat-table``) directive"""
option_spec = {
'name': directives.unchanged
@ -135,7 +135,7 @@ class FlatTable(Table):
class ListTableBuilder(object):
# ==============================================================================
u"""Builds a table from a double-stage list"""
"""Builds a table from a double-stage list"""
def __init__(self, directive):
self.directive = directive
@ -212,7 +212,7 @@ class ListTableBuilder(object):
raise SystemMessagePropagation(error)
def parseFlatTableNode(self, node):
u"""parses the node from a :py:class:`FlatTable` directive's body"""
"""parses the node from a :py:class:`FlatTable` directive's body"""
if len(node) != 1 or not isinstance(node[0], nodes.bullet_list):
self.raiseError(
@ -225,7 +225,7 @@ class ListTableBuilder(object):
self.roundOffTableDefinition()
def roundOffTableDefinition(self):
u"""Round off the table definition.
"""Round off the table definition.
This method rounds off the table definition in :py:member:`rows`.

2
Documentation/trace/postprocess/decode_msr.py
View File

@ -32,6 +32,6 @@ for j in sys.stdin:
break
if r:
j = j.replace(" " + m.group(2), " " + r + "(" + m.group(2) + ")")
print j,
print(j)

7
Documentation/translations/it_IT/process/submit-checklist.rst
View File

@ -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``.

105
Documentation/translations/ja_JP/SubmitChecklist
View File

@ -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 およびその他のサブシステムに関する様々な変更と、現時点でも共存
できることを確認するテストを行ってください。

24
Documentation/translations/ja_JP/disclaimer-ja_JP.rst Normal file
View File

@ -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 に記載の維持管理者に知らせてください。
翻訳が原文の更新に追いついていない場合は、それを日本語版に反映するパッチの
投稿も歓迎です。
なお、この翻訳の目的は非英語 (ここでは日本語) 話者への便宜提供であり、
フォークを意図したものではない事を念頭においてください。したがって、
このファイルの内容に対するコメントや更新すべきことがあれば、先に原文の
更新を検討してください。

2
Documentation/translations/ja_JP/index.rst
View File

@ -11,7 +11,9 @@
.. toctree::
:maxdepth: 1
disclaimer-ja_JP
process/howto
process/submit-checklist
.. raw:: latex

37
Documentation/translations/ja_JP/process/howto.rst
View File

@ -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
カーネル開発コミュニティと共に活動するやり方を学ぶ方法が含まれています。

163
Documentation/translations/ja_JP/process/submit-checklist.rst Normal file
View File

@ -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、その他のサブシステム内のすべての変更と組み合わせての
動作を確認済み。

7
Documentation/translations/sp_SP/process/submit-checklist.rst
View File

@ -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/``.

2
Documentation/translations/zh_CN/admin-guide/README.rst
View File

@ -146,7 +146,7 @@ Linux内核6.x版本 <http://kernel.org/>
"make xconfig" 基于Qt的配置工具。
"make gconfig" 基于GTK+的配置工具。
"make gconfig" 基于GTK的配置工具。
"make oldconfig" 基于现有的 ./.config 文件选择所有选项，并询问
新配置选项。

33
Documentation/translations/zh_CN/dev-tools/ubsan.rst
View File

@ -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=y
使用如下内核配置检查整个内核::
CONFIG_UBSAN_SANITIZE_ALL=y
为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容:
- 单文件（如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报告。

8
Documentation/translations/zh_CN/disclaimer-zh_CN.rst
View File

@ -1,9 +1,7 @@
:orphan:
.. warning::
.. note::
此文件的目的是为让中文读者更容易阅读和理解，而不是作为一个分支。 因此，
如果您对此文件有任何意见或更新，请先尝试更新原始英文文件。
.. note::
如果您发现本文档与原始文件有任何不同或者有翻译问题，请联系该文件的译者，
或者请求时奎亮的帮助：<alexs@kernel.org>。
如果您发现本文档与原始文件有任何不同或者有翻译问题，请发建议或者补丁给
该文件的译者，或者请求中文文档维护者和审阅者的帮助。

8
Documentation/translations/zh_CN/index.rst
View File

@ -26,7 +26,13 @@
顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文
的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时，
中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将
补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。
补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试，确保
在 ``make htmldocs/pdfdocs`` 中不增加新的告警，最后，安装检查你生成的
html/pdf 文件，确认它们看起来是正常的。
提交之前请确认你的补丁可以正常提交到中文文档维护库:
https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git/
如果你的补丁依赖于其他人的补丁, 可以与其他人商量后由某一个人合并提交。
与Linux 内核社区一起工作
------------------------

2
Documentation/translations/zh_CN/mm/balance.rst
View File

@ -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被设置时，页面分配请求将尝试释放该区域的一些页面（如果

4
Documentation/translations/zh_CN/process/submit-checklist.rst
View File

@ -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/`` 。
如果新代码是实质性的，那么添加子系统特定的故障注入可能是合适的。

479
Documentation/translations/zh_CN/security/credentials.rst Normal file
View File

@ -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.

8
Documentation/translations/zh_CN/security/index.rst
View File

@ -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

22
Documentation/translations/zh_CN/security/keys/index.rst Normal file
View File

@ -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

17
Documentation/translations/zh_CN/security/secrets/index.rst Normal file
View File

@ -0,0 +1,17 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: ../../disclaimer-zh_CN.rst
:Original: Documentation/security/secrets/index.rst
:翻译:
=====================
密钥文档
=====================
.. toctree::
TODOLIST:
* coco

271
Documentation/translations/zh_CN/security/self-protection.rst Normal file
View File

@ -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文件），则应该自
动审查敏感值。

209
Documentation/translations/zh_CN/security/snp-tdx-threat-model.rst Normal file
View File

@ -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客户虚拟机与宿主机管理的物理或虚拟设备之间传输的数
据拥有完全控制权。这使得宿主机可以对这类数据的保密性、完整性和新鲜性进行任何攻击。
* - 格式错误的运行时输入
- 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入格式错误的输入。
如果代码没有正确处理这些输入，这可能导致从宿主机到客户机内核的特权提升。这包
括传统的侧信道攻击和/或瞬态执行攻击路径。
* - 恶意运行时输入
- 一个行为不当的宿主机通过客户机内核代码使用的任意通信接口注入特定的输入值。与之前
的攻击向量（格式错误的运行时输入）不同，这个输入并非格式错误，而是其值被精心设
计以影响客户机内核的安全性。这类输入的例子包括向客户机提供恶意的时间或向客户机
的随机数生成器提供熵值。此外，如果它导致客户机内核执行特定操作（例如处理主机注
入的中断），此类事件的时序本身也可能成为一种攻击路径。这种攻击是对提供的宿主机输
入具有抵抗性的一种方式。

20
Documentation/translations/zh_CN/security/tpm/index.rst Normal file
View File

@ -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

151
Documentation/translations/zh_CN/security/tpm/tpm-security.rst Normal file
View File

@ -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/

Some files were not shown because too many files have changed in this diff Show More