Loading .mailmap +6 −0 Original line number Diff line number Diff line Loading @@ -73,6 +73,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com> Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com> André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com> Andy Adamson <andros@citi.umich.edu> Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com> Andy Chiu <andybnac@gmail.com> <taochiu@synology.com> Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua> Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com> Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org> Loading Loading @@ -203,12 +205,16 @@ Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com> Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net> Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com> Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com> Fangrui Song <i@maskray.me> <maskray@google.com> Felipe W Damasio <felipewd@terra.com.br> Felix Kuhling <fxkuehl@gmx.de> Felix Moeller <felix@derklecks.de> Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org> Filipe Lautert <filipe@icewall.org> Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au> Fiona Behrens <me@kloenk.dev> Fiona Behrens <me@kloenk.dev> <me@kloenk.de> Fiona Behrens <me@kloenk.dev> <fin@nyantec.com> Franck Bui-Huu <vagabon.xyz@gmail.com> Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com> Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com> Loading CREDITS +27 −27 Original line number Diff line number Diff line Loading @@ -1358,10 +1358,6 @@ D: Major kbuild rework during the 2.5 cycle D: ISDN Maintainer S: USA N: Gerrit Renker E: gerrit@erg.abdn.ac.uk D: DCCP protocol support. N: Philip Gladstone E: philip@gladstonefamily.net D: Kernel / timekeeping stuff Loading Loading @@ -1677,11 +1673,6 @@ W: http://www.carumba.com/ D: bug toaster (A1 sauce makes all the difference) D: Random linux hacker N: James Hogan E: jhogan@kernel.org D: Metag architecture maintainer D: TZ1090 SoC maintainer N: Tim Hockin E: thockin@hockin.org W: http://www.hockin.org/~thockin Loading @@ -1697,6 +1688,11 @@ D: hwmon subsystem maintainer D: i2c-sis96x and i2c-stub SMBus drivers S: USA N: James Hogan E: jhogan@kernel.org D: Metag architecture maintainer D: TZ1090 SoC maintainer N: Dirk Hohndel E: hohndel@suse.de D: The XFree86[tm] Project Loading Loading @@ -1872,6 +1868,10 @@ S: K osmidomkum 723 S: 160 00 Praha 6 S: Czech Republic N: Seth Jennings E: sjenning@redhat.com D: Creation and maintenance of zswap N: Jeremy Kerr D: Maintainer of SPU File System Loading Loading @@ -2188,19 +2188,6 @@ N: Mike Kravetz E: mike.kravetz@oracle.com D: Maintenance and development of the hugetlb subsystem N: Seth Jennings E: sjenning@redhat.com D: Creation and maintenance of zswap N: Dan Streetman E: ddstreet@ieee.org D: Maintenance and development of zswap D: Creation and maintenance of the zpool API N: Vitaly Wool E: vitaly.wool@konsulko.com D: Maintenance and development of zswap N: Andreas S. Krebs E: akrebs@altavista.net D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards Loading Loading @@ -3191,6 +3178,11 @@ N: Ken Pizzini E: ken@halcyon.com D: CDROM driver "sonycd535" (Sony CDU-535/531) N: Mathieu Poirier E: mathieu.poirier@linaro.org D: CoreSight kernel subsystem, Maintainer 2014-2022 D: Perf tool support for CoreSight N: Stelian Pop E: stelian@popies.net P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147 Loading Loading @@ -3300,6 +3292,10 @@ S: Schlossbergring 9 S: 79098 Freiburg S: Germany N: Gerrit Renker E: gerrit@erg.abdn.ac.uk D: DCCP protocol support. N: Thomas Renninger E: trenn@suse.de D: cpupowerutils Loading Loading @@ -3576,11 +3572,6 @@ D: several improvements to system programs S: Oldenburg S: Germany N: Mathieu Poirier E: mathieu.poirier@linaro.org D: CoreSight kernel subsystem, Maintainer 2014-2022 D: Perf tool support for CoreSight N: Robert Schwebel E: robert@schwebel.de W: https://www.schwebel.de Loading Loading @@ -3771,6 +3762,11 @@ S: Chr. Winthersvej 1 B, st.th. S: DK-1860 Frederiksberg C S: Denmark N: Dan Streetman E: ddstreet@ieee.org D: Maintenance and development of zswap D: Creation and maintenance of the zpool API N: Drew Sullivan E: drew@ss.org W: http://www.ss.org/ Loading Loading @@ -4286,6 +4282,10 @@ S: Pipers Way S: Swindon. SN3 1RJ S: England N: Vitaly Wool E: vitaly.wool@konsulko.com D: Maintenance and development of zswap N: Chris Wright E: chrisw@sous-sol.org D: hacking on LSM framework and security modules. Loading Documentation/admin-guide/LSM/ipe.rst +5 −2 Original line number Diff line number Diff line Loading @@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of authorization of the policies (prohibiting an attacker from gaining unconstrained root, and deploying an "allow all" policy). These policies must be signed by a certificate that chains to the ``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by:: ``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if ``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or ``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively. With openssl, the policy can be signed by:: openssl smime -sign \ -in "$MY_POLICY" \ Loading Loading @@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed policy. Two checks will always be performed on this policy: First, the ``policy_names`` must match with the updated version and the existing version. Second the updated policy must have a policy version greater than or equal to the currently-running version. This is to prevent rollback attacks. the currently-running version. This is to prevent rollback attacks. The ``delete`` file is used to remove a policy that is no longer needed. This file is write-only and accepts a value of ``1`` to delete the policy. Loading Documentation/core-api/protection-keys.rst +30 −8 Original line number Diff line number Diff line Loading @@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on: * Intel server CPUs, Skylake and later * Intel client CPUs, Tiger Lake (11th Gen Core) and later * Future AMD CPUs * arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE) x86_64 ====== Pkeys work by dedicating 4 previously Reserved bits in each page table entry to a "protection key", giving 16 possible keys. Loading @@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is theoretically space in the PAE PTEs. These permissions are enforced on data access only and have no effect on instruction fetches. arm64 ===== Pkeys use 3 bits in each page table entry, to encode a "protection key index", giving 8 possible keys. Protections for each key are defined with a per-CPU user-writable system register (POR_EL0). This is a 64-bit register encoding read, write and execute overlay permissions for each protection key index. Being a CPU register, POR_EL0 is inherently thread-local, potentially giving each thread a different set of protections from every other thread. Unlike x86_64, the protection key permissions also apply to instruction fetches. Syscalls ======== Loading @@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys:: int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); Before a pkey can be used, it must first be allocated with pkey_alloc(). An application calls the WRPKRU instruction directly in order to change access permissions to memory covered with a key. In this example WRPKRU is wrapped by a C function called pkey_set(). Before a pkey can be used, it must first be allocated with pkey_alloc(). An application writes to the architecture specific CPU register directly in order to change access permissions to memory covered with a key. In this example this is wrapped by a C function called pkey_set(). :: int real_prot = PROT_READ|PROT_WRITE; Loading @@ -64,9 +82,9 @@ is no longer in use:: munmap(ptr, PAGE_SIZE); pkey_free(pkey); .. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. An example implementation can be found in tools/testing/selftests/x86/protection_keys.c. .. note:: pkey_set() is a wrapper around writing to the CPU register. Example implementations can be found in tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h Behavior ======== Loading Loading @@ -96,3 +114,7 @@ with a read():: The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. Note that kernel accesses from a kthread (such as io_uring) will use a default value for the protection key register and so will not be consistent with userspace's value of the register or mprotect(). Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml 0 → 100644 +54 −0 Original line number Diff line number Diff line # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Elgin JG10309-01 SPI-controlled display maintainers: - Fabio Estevam <festevam@gmail.com> description: | The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1 board and is a custom display. allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: const: elgin,jg10309-01 reg: maxItems: 1 spi-max-frequency: maximum: 24000000 spi-cpha: true spi-cpol: true required: - compatible - reg - spi-cpha - spi-cpol additionalProperties: false examples: - | spi { #address-cells = <1>; #size-cells = <0>; display@0 { compatible = "elgin,jg10309-01"; reg = <0>; spi-max-frequency = <24000000>; spi-cpha; spi-cpol; }; }; Loading
.mailmap +6 −0 Original line number Diff line number Diff line Loading @@ -73,6 +73,8 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <aryabinin@virtuozzo.com> Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com> André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com> Andy Adamson <andros@citi.umich.edu> Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com> Andy Chiu <andybnac@gmail.com> <taochiu@synology.com> Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua> Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com> Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org> Loading Loading @@ -203,12 +205,16 @@ Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> <ezequiel@collabora.com> Faith Ekstrand <faith.ekstrand@collabora.com> <jason@jlekstrand.net> Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@intel.com> Faith Ekstrand <faith.ekstrand@collabora.com> <jason.ekstrand@collabora.com> Fangrui Song <i@maskray.me> <maskray@google.com> Felipe W Damasio <felipewd@terra.com.br> Felix Kuhling <fxkuehl@gmx.de> Felix Moeller <felix@derklecks.de> Fenglin Wu <quic_fenglinw@quicinc.com> <fenglinw@codeaurora.org> Filipe Lautert <filipe@icewall.org> Finn Thain <fthain@linux-m68k.org> <fthain@telegraphics.com.au> Fiona Behrens <me@kloenk.dev> Fiona Behrens <me@kloenk.dev> <me@kloenk.de> Fiona Behrens <me@kloenk.dev> <fin@nyantec.com> Franck Bui-Huu <vagabon.xyz@gmail.com> Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com> Frank Rowand <frowand.list@gmail.com> <frank.rowand@sony.com> Loading
CREDITS +27 −27 Original line number Diff line number Diff line Loading @@ -1358,10 +1358,6 @@ D: Major kbuild rework during the 2.5 cycle D: ISDN Maintainer S: USA N: Gerrit Renker E: gerrit@erg.abdn.ac.uk D: DCCP protocol support. N: Philip Gladstone E: philip@gladstonefamily.net D: Kernel / timekeeping stuff Loading Loading @@ -1677,11 +1673,6 @@ W: http://www.carumba.com/ D: bug toaster (A1 sauce makes all the difference) D: Random linux hacker N: James Hogan E: jhogan@kernel.org D: Metag architecture maintainer D: TZ1090 SoC maintainer N: Tim Hockin E: thockin@hockin.org W: http://www.hockin.org/~thockin Loading @@ -1697,6 +1688,11 @@ D: hwmon subsystem maintainer D: i2c-sis96x and i2c-stub SMBus drivers S: USA N: James Hogan E: jhogan@kernel.org D: Metag architecture maintainer D: TZ1090 SoC maintainer N: Dirk Hohndel E: hohndel@suse.de D: The XFree86[tm] Project Loading Loading @@ -1872,6 +1868,10 @@ S: K osmidomkum 723 S: 160 00 Praha 6 S: Czech Republic N: Seth Jennings E: sjenning@redhat.com D: Creation and maintenance of zswap N: Jeremy Kerr D: Maintainer of SPU File System Loading Loading @@ -2188,19 +2188,6 @@ N: Mike Kravetz E: mike.kravetz@oracle.com D: Maintenance and development of the hugetlb subsystem N: Seth Jennings E: sjenning@redhat.com D: Creation and maintenance of zswap N: Dan Streetman E: ddstreet@ieee.org D: Maintenance and development of zswap D: Creation and maintenance of the zpool API N: Vitaly Wool E: vitaly.wool@konsulko.com D: Maintenance and development of zswap N: Andreas S. Krebs E: akrebs@altavista.net D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards Loading Loading @@ -3191,6 +3178,11 @@ N: Ken Pizzini E: ken@halcyon.com D: CDROM driver "sonycd535" (Sony CDU-535/531) N: Mathieu Poirier E: mathieu.poirier@linaro.org D: CoreSight kernel subsystem, Maintainer 2014-2022 D: Perf tool support for CoreSight N: Stelian Pop E: stelian@popies.net P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147 Loading Loading @@ -3300,6 +3292,10 @@ S: Schlossbergring 9 S: 79098 Freiburg S: Germany N: Gerrit Renker E: gerrit@erg.abdn.ac.uk D: DCCP protocol support. N: Thomas Renninger E: trenn@suse.de D: cpupowerutils Loading Loading @@ -3576,11 +3572,6 @@ D: several improvements to system programs S: Oldenburg S: Germany N: Mathieu Poirier E: mathieu.poirier@linaro.org D: CoreSight kernel subsystem, Maintainer 2014-2022 D: Perf tool support for CoreSight N: Robert Schwebel E: robert@schwebel.de W: https://www.schwebel.de Loading Loading @@ -3771,6 +3762,11 @@ S: Chr. Winthersvej 1 B, st.th. S: DK-1860 Frederiksberg C S: Denmark N: Dan Streetman E: ddstreet@ieee.org D: Maintenance and development of zswap D: Creation and maintenance of the zpool API N: Drew Sullivan E: drew@ss.org W: http://www.ss.org/ Loading Loading @@ -4286,6 +4282,10 @@ S: Pipers Way S: Swindon. SN3 1RJ S: England N: Vitaly Wool E: vitaly.wool@konsulko.com D: Maintenance and development of zswap N: Chris Wright E: chrisw@sous-sol.org D: hacking on LSM framework and security modules. Loading
Documentation/admin-guide/LSM/ipe.rst +5 −2 Original line number Diff line number Diff line Loading @@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of authorization of the policies (prohibiting an attacker from gaining unconstrained root, and deploying an "allow all" policy). These policies must be signed by a certificate that chains to the ``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by:: ``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if ``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or ``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively. With openssl, the policy can be signed by:: openssl smime -sign \ -in "$MY_POLICY" \ Loading Loading @@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed policy. Two checks will always be performed on this policy: First, the ``policy_names`` must match with the updated version and the existing version. Second the updated policy must have a policy version greater than or equal to the currently-running version. This is to prevent rollback attacks. the currently-running version. This is to prevent rollback attacks. The ``delete`` file is used to remove a policy that is no longer needed. This file is write-only and accepts a value of ``1`` to delete the policy. Loading
Documentation/core-api/protection-keys.rst +30 −8 Original line number Diff line number Diff line Loading @@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on: * Intel server CPUs, Skylake and later * Intel client CPUs, Tiger Lake (11th Gen Core) and later * Future AMD CPUs * arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE) x86_64 ====== Pkeys work by dedicating 4 previously Reserved bits in each page table entry to a "protection key", giving 16 possible keys. Loading @@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is theoretically space in the PAE PTEs. These permissions are enforced on data access only and have no effect on instruction fetches. arm64 ===== Pkeys use 3 bits in each page table entry, to encode a "protection key index", giving 8 possible keys. Protections for each key are defined with a per-CPU user-writable system register (POR_EL0). This is a 64-bit register encoding read, write and execute overlay permissions for each protection key index. Being a CPU register, POR_EL0 is inherently thread-local, potentially giving each thread a different set of protections from every other thread. Unlike x86_64, the protection key permissions also apply to instruction fetches. Syscalls ======== Loading @@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys:: int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); Before a pkey can be used, it must first be allocated with pkey_alloc(). An application calls the WRPKRU instruction directly in order to change access permissions to memory covered with a key. In this example WRPKRU is wrapped by a C function called pkey_set(). Before a pkey can be used, it must first be allocated with pkey_alloc(). An application writes to the architecture specific CPU register directly in order to change access permissions to memory covered with a key. In this example this is wrapped by a C function called pkey_set(). :: int real_prot = PROT_READ|PROT_WRITE; Loading @@ -64,9 +82,9 @@ is no longer in use:: munmap(ptr, PAGE_SIZE); pkey_free(pkey); .. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions. An example implementation can be found in tools/testing/selftests/x86/protection_keys.c. .. note:: pkey_set() is a wrapper around writing to the CPU register. Example implementations can be found in tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h Behavior ======== Loading Loading @@ -96,3 +114,7 @@ with a read():: The kernel will send a SIGSEGV in both cases, but si_code will be set to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when the plain mprotect() permissions are violated. Note that kernel accesses from a kthread (such as io_uring) will use a default value for the protection key register and so will not be consistent with userspace's value of the register or mprotect().
Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml 0 → 100644 +54 −0 Original line number Diff line number Diff line # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- $id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Elgin JG10309-01 SPI-controlled display maintainers: - Fabio Estevam <festevam@gmail.com> description: | The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1 board and is a custom display. allOf: - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: const: elgin,jg10309-01 reg: maxItems: 1 spi-max-frequency: maximum: 24000000 spi-cpha: true spi-cpol: true required: - compatible - reg - spi-cpha - spi-cpol additionalProperties: false examples: - | spi { #address-cells = <1>; #size-cells = <0>; display@0 { compatible = "elgin,jg10309-01"; reg = <0>; spi-max-frequency = <24000000>; spi-cpha; spi-cpol; }; };