Loading .mailmap +20 −1 Original line number Diff line number Diff line Loading @@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com> Adam Radford <aradford@gmail.com> Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com> Adrian Bunk <bunk@stusta.de> Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com> Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org> Alan Cox <alan@lxorguk.ukuu.org.uk> Alan Cox <root@hraefn.swansea.linux.org.uk> Loading @@ -36,6 +37,17 @@ Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org> Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com> Alexei Starovoitov <ast@kernel.org> <ast@fb.com> Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com> Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com> Alex Elder <elder@kernel.org> Alex Elder <elder@kernel.org> <aelder@sgi.com> Alex Elder <elder@kernel.org> <alex.elder@linaro.org> Alex Elder <elder@kernel.org> <alex.elder@linary.org> Alex Elder <elder@kernel.org> <elder@dreamhost.com> Alex Elder <elder@kernel.org> <elder@dreawmhost.com> Alex Elder <elder@kernel.org> <elder@ieee.org> Alex Elder <elder@kernel.org> <elder@inktank.com> Alex Elder <elder@kernel.org> <elder@linaro.org> Alex Elder <elder@kernel.org> <elder@newdream.net> Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com> Alex Shi <alexs@kernel.org> <alex.shi@intel.com> Alex Shi <alexs@kernel.org> <alex.shi@linaro.org> Loading Loading @@ -96,6 +108,8 @@ Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net> Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com> Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com> Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de> Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@gmail.com> Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@redhat.com> Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se> Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org> Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com> Loading @@ -110,6 +124,7 @@ Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com> Brian Avery <b.avery@hp.com> Brian King <brking@us.ibm.com> Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com> Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com> Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com> Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org> Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org> Loading Loading @@ -443,7 +458,8 @@ Mythri P K <mythripk@ti.com> Nadav Amit <nadav.amit@gmail.com> <namit@vmware.com> Nadav Amit <nadav.amit@gmail.com> <namit@cs.technion.ac.il> Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com> Naoya Horiguchi <naoya.horiguchi@nec.com> <n-horiguchi@ah.jp.nec.com> Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com> Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com> Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com> Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org> Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com> Loading Loading @@ -521,6 +537,7 @@ Rémi Denis-Courmont <rdenis@simphalempin.com> Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com> Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org> Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com> Richard Genoud <richard.genoud@bootlin.com> <richard.genoud@gmail.com> Richard Leitner <richard.leitner@linux.dev> <dev@g0hl1n.net> Richard Leitner <richard.leitner@linux.dev> <me@g0hl1n.net> Richard Leitner <richard.leitner@linux.dev> <richard.leitner@skidata.com> Loading @@ -529,6 +546,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rjliao@codeaurora.org> Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com> Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com> Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru> Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com> Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com> Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com> Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com> Loading Loading @@ -651,6 +669,7 @@ Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com> Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com> Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org> Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com> Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com> Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org> Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com> Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com> Loading CREDITS +4 −0 Original line number Diff line number Diff line Loading @@ -3146,6 +3146,10 @@ S: Triftstra=DFe 55 S: 13353 Berlin S: Germany N: Gustavo Pimental E: gustavo.pimentel@synopsys.com D: PCI driver for Synopsys DesignWare N: Emanuel Pirker E: epirker@edu.uni-klu.ac.at D: AIC5800 IEEE 1394, RAW I/O on 1394 Loading Documentation/admin-guide/hw-vuln/spectre.rst +38 −6 Original line number Diff line number Diff line Loading @@ -138,11 +138,10 @@ associated with the source address of the indirect branch. Specifically, the BHB might be shared across privilege levels even in the presence of Enhanced IBRS. Currently the only known real-world BHB attack vector is via unprivileged eBPF. Therefore, it's highly recommended to not enable unprivileged eBPF, especially when eIBRS is used (without retpolines). For a full mitigation against BHB attacks, it's recommended to use retpolines (or eIBRS combined with retpolines). Previously the only known real-world BHB attack vector was via unprivileged eBPF. Further research has found attacks that don't require unprivileged eBPF. For a full mitigation against BHB attacks it is recommended to set BHI_DIS_S or use the BHB clearing sequence. Attack scenarios ---------------- Loading Loading @@ -430,6 +429,23 @@ The possible values in this file are: 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB =========================== ======================================================= - Branch History Injection (BHI) protection status: .. list-table:: * - BHI: Not affected - System is not affected * - BHI: Retpoline - System is protected by retpoline * - BHI: BHI_DIS_S - System is protected by BHI_DIS_S * - BHI: SW loop, KVM SW loop - System is protected by software clearing sequence * - BHI: Vulnerable - System is vulnerable to BHI * - BHI: Vulnerable, KVM: SW loop - System is vulnerable; KVM is protected by software clearing sequence Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. Loading Loading @@ -484,7 +500,11 @@ Spectre variant 2 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against Spectre v2 variant attacks. some Spectre v2 variant attacks. The BHB can still influence the choice of indirect branch predictor entry, and although branch predictor entries are isolated between modes when eIBRS is enabled, the BHB itself is not isolated between modes. Systems which support BHI_DIS_S will set it to protect against BHI attacks. On Intel's enhanced IBRS systems, this includes cross-thread branch target injections on SMT systems (STIBP). In other words, Intel eIBRS enables Loading Loading @@ -638,6 +658,18 @@ kernel command line. spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. spectre_bhi= [X86] Control mitigation of Branch History Injection (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. on (default) Enable the HW or SW mitigation as needed. off Disable the mitigation. For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt Mitigation selection guide Loading Documentation/admin-guide/kernel-parameters.txt +14 −1 Original line number Diff line number Diff line Loading @@ -3423,6 +3423,9 @@ arch-independent options, each of which is an aggregation of existing arch-specific options. Note, "mitigations" is supported if and only if the kernel was built with CPU_MITIGATIONS=y. off Disable all optional CPU mitigations. This improves system performance, but it may also Loading @@ -3444,6 +3447,7 @@ retbleed=off [X86] spec_rstack_overflow=off [X86] spec_store_bypass_disable=off [X86,PPC] spectre_bhi=off [X86] spectre_v2_user=off [X86] srbds=off [X86,INTEL] ssbd=force-off [ARM64] Loading Loading @@ -6063,6 +6067,15 @@ sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/admin-guide/laptops/sonypi.rst spectre_bhi= [X86] Control mitigation of Branch History Injection (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. on - (default) Enable the HW or SW mitigation as needed. off - Disable the mitigation. spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. The default operation protects the kernel from Loading Loading @@ -6599,7 +6612,7 @@ To turn off having tracepoints sent to printk, echo 0 > /proc/sys/kernel/tracepoint_printk Note, echoing 1 into this file without the tracepoint_printk kernel cmdline option has no effect. tp_printk kernel cmdline option has no effect. The tp_printk_stop_on_boot (see below) can also be used to stop the printing of events to console at Loading Documentation/admin-guide/mm/zswap.rst +2 −2 Original line number Diff line number Diff line Loading @@ -155,7 +155,7 @@ Setting this parameter to 100 will disable the hysteresis. Some users cannot tolerate the swapping that comes with zswap store failures and zswap writebacks. Swapping can be disabled entirely (without disabling zswap itself) on a cgroup-basis as follows: zswap itself) on a cgroup-basis as follows:: echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback Loading @@ -166,7 +166,7 @@ writeback (because the same pages might be rejected again and again). When there is a sizable amount of cold memory residing in the zswap pool, it can be advantageous to proactively write these cold pages to swap and reclaim the memory for other use cases. By default, the zswap shrinker is disabled. User can enable it as follows: User can enable it as follows:: echo Y > /sys/module/zswap/parameters/shrinker_enabled Loading Loading
.mailmap +20 −1 Original line number Diff line number Diff line Loading @@ -20,6 +20,7 @@ Adam Oldham <oldhamca@gmail.com> Adam Radford <aradford@gmail.com> Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com> Adrian Bunk <bunk@stusta.de> Ajay Kaher <ajay.kaher@broadcom.com> <akaher@vmware.com> Akhil P Oommen <quic_akhilpo@quicinc.com> <akhilpo@codeaurora.org> Alan Cox <alan@lxorguk.ukuu.org.uk> Alan Cox <root@hraefn.swansea.linux.org.uk> Loading @@ -36,6 +37,17 @@ Alexei Avshalom Lazar <quic_ailizaro@quicinc.com> <ailizaro@codeaurora.org> Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com> Alexei Starovoitov <ast@kernel.org> <ast@fb.com> Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com> Alexey Makhalov <alexey.amakhalov@broadcom.com> <amakhalov@vmware.com> Alex Elder <elder@kernel.org> Alex Elder <elder@kernel.org> <aelder@sgi.com> Alex Elder <elder@kernel.org> <alex.elder@linaro.org> Alex Elder <elder@kernel.org> <alex.elder@linary.org> Alex Elder <elder@kernel.org> <elder@dreamhost.com> Alex Elder <elder@kernel.org> <elder@dreawmhost.com> Alex Elder <elder@kernel.org> <elder@ieee.org> Alex Elder <elder@kernel.org> <elder@inktank.com> Alex Elder <elder@kernel.org> <elder@linaro.org> Alex Elder <elder@kernel.org> <elder@newdream.net> Alex Hung <alexhung@gmail.com> <alex.hung@canonical.com> Alex Shi <alexs@kernel.org> <alex.shi@intel.com> Alex Shi <alexs@kernel.org> <alex.shi@linaro.org> Loading Loading @@ -96,6 +108,8 @@ Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net> Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com> Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com> Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de> Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@gmail.com> Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@redhat.com> Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se> Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org> Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com> Loading @@ -110,6 +124,7 @@ Brendan Higgins <brendan.higgins@linux.dev> <brendanhiggins@google.com> Brian Avery <b.avery@hp.com> Brian King <brking@us.ibm.com> Brian Silverman <bsilver16384@gmail.com> <brian.silverman@bluerivertech.com> Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com> Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com> Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org> Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org> Loading Loading @@ -443,7 +458,8 @@ Mythri P K <mythripk@ti.com> Nadav Amit <nadav.amit@gmail.com> <namit@vmware.com> Nadav Amit <nadav.amit@gmail.com> <namit@cs.technion.ac.il> Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy.com> Naoya Horiguchi <naoya.horiguchi@nec.com> <n-horiguchi@ah.jp.nec.com> Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com> Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com> Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com> Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org> Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com> Loading Loading @@ -521,6 +537,7 @@ Rémi Denis-Courmont <rdenis@simphalempin.com> Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com> Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org> Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com> Richard Genoud <richard.genoud@bootlin.com> <richard.genoud@gmail.com> Richard Leitner <richard.leitner@linux.dev> <dev@g0hl1n.net> Richard Leitner <richard.leitner@linux.dev> <me@g0hl1n.net> Richard Leitner <richard.leitner@linux.dev> <richard.leitner@skidata.com> Loading @@ -529,6 +546,7 @@ Rocky Liao <quic_rjliao@quicinc.com> <rjliao@codeaurora.org> Roman Gushchin <roman.gushchin@linux.dev> <guro@fb.com> Roman Gushchin <roman.gushchin@linux.dev> <guroan@gmail.com> Roman Gushchin <roman.gushchin@linux.dev> <klamm@yandex-team.ru> Ronak Doshi <ronak.doshi@broadcom.com> <doshir@vmware.com> Muchun Song <muchun.song@linux.dev> <songmuchun@bytedance.com> Muchun Song <muchun.song@linux.dev> <smuchun@gmail.com> Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com> Loading Loading @@ -651,6 +669,7 @@ Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com> Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com> Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.org> Viresh Kumar <viresh.kumar@linaro.org> <viresh.kumar@linaro.com> Vishnu Dasa <vishnu.dasa@broadcom.com> <vdasa@vmware.com> Vivek Aknurwar <quic_viveka@quicinc.com> <viveka@codeaurora.org> Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com> Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com> Loading
CREDITS +4 −0 Original line number Diff line number Diff line Loading @@ -3146,6 +3146,10 @@ S: Triftstra=DFe 55 S: 13353 Berlin S: Germany N: Gustavo Pimental E: gustavo.pimentel@synopsys.com D: PCI driver for Synopsys DesignWare N: Emanuel Pirker E: epirker@edu.uni-klu.ac.at D: AIC5800 IEEE 1394, RAW I/O on 1394 Loading
Documentation/admin-guide/hw-vuln/spectre.rst +38 −6 Original line number Diff line number Diff line Loading @@ -138,11 +138,10 @@ associated with the source address of the indirect branch. Specifically, the BHB might be shared across privilege levels even in the presence of Enhanced IBRS. Currently the only known real-world BHB attack vector is via unprivileged eBPF. Therefore, it's highly recommended to not enable unprivileged eBPF, especially when eIBRS is used (without retpolines). For a full mitigation against BHB attacks, it's recommended to use retpolines (or eIBRS combined with retpolines). Previously the only known real-world BHB attack vector was via unprivileged eBPF. Further research has found attacks that don't require unprivileged eBPF. For a full mitigation against BHB attacks it is recommended to set BHI_DIS_S or use the BHB clearing sequence. Attack scenarios ---------------- Loading Loading @@ -430,6 +429,23 @@ The possible values in this file are: 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB =========================== ======================================================= - Branch History Injection (BHI) protection status: .. list-table:: * - BHI: Not affected - System is not affected * - BHI: Retpoline - System is protected by retpoline * - BHI: BHI_DIS_S - System is protected by BHI_DIS_S * - BHI: SW loop, KVM SW loop - System is protected by software clearing sequence * - BHI: Vulnerable - System is vulnerable to BHI * - BHI: Vulnerable, KVM: SW loop - System is vulnerable; KVM is protected by software clearing sequence Full mitigation might require a microcode update from the CPU vendor. When the necessary microcode is not available, the kernel will report vulnerability. Loading Loading @@ -484,7 +500,11 @@ Spectre variant 2 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at boot, by setting the IBRS bit, and they're automatically protected against Spectre v2 variant attacks. some Spectre v2 variant attacks. The BHB can still influence the choice of indirect branch predictor entry, and although branch predictor entries are isolated between modes when eIBRS is enabled, the BHB itself is not isolated between modes. Systems which support BHI_DIS_S will set it to protect against BHI attacks. On Intel's enhanced IBRS systems, this includes cross-thread branch target injections on SMT systems (STIBP). In other words, Intel eIBRS enables Loading Loading @@ -638,6 +658,18 @@ kernel command line. spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. spectre_bhi= [X86] Control mitigation of Branch History Injection (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. on (default) Enable the HW or SW mitigation as needed. off Disable the mitigation. For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt Mitigation selection guide Loading
Documentation/admin-guide/kernel-parameters.txt +14 −1 Original line number Diff line number Diff line Loading @@ -3423,6 +3423,9 @@ arch-independent options, each of which is an aggregation of existing arch-specific options. Note, "mitigations" is supported if and only if the kernel was built with CPU_MITIGATIONS=y. off Disable all optional CPU mitigations. This improves system performance, but it may also Loading @@ -3444,6 +3447,7 @@ retbleed=off [X86] spec_rstack_overflow=off [X86] spec_store_bypass_disable=off [X86,PPC] spectre_bhi=off [X86] spectre_v2_user=off [X86] srbds=off [X86,INTEL] ssbd=force-off [ARM64] Loading Loading @@ -6063,6 +6067,15 @@ sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/admin-guide/laptops/sonypi.rst spectre_bhi= [X86] Control mitigation of Branch History Injection (BHI) vulnerability. This setting affects the deployment of the HW BHI control and the SW BHB clearing sequence. on - (default) Enable the HW or SW mitigation as needed. off - Disable the mitigation. spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability. The default operation protects the kernel from Loading Loading @@ -6599,7 +6612,7 @@ To turn off having tracepoints sent to printk, echo 0 > /proc/sys/kernel/tracepoint_printk Note, echoing 1 into this file without the tracepoint_printk kernel cmdline option has no effect. tp_printk kernel cmdline option has no effect. The tp_printk_stop_on_boot (see below) can also be used to stop the printing of events to console at Loading
Documentation/admin-guide/mm/zswap.rst +2 −2 Original line number Diff line number Diff line Loading @@ -155,7 +155,7 @@ Setting this parameter to 100 will disable the hysteresis. Some users cannot tolerate the swapping that comes with zswap store failures and zswap writebacks. Swapping can be disabled entirely (without disabling zswap itself) on a cgroup-basis as follows: zswap itself) on a cgroup-basis as follows:: echo 0 > /sys/fs/cgroup/<cgroup-name>/memory.zswap.writeback Loading @@ -166,7 +166,7 @@ writeback (because the same pages might be rejected again and again). When there is a sizable amount of cold memory residing in the zswap pool, it can be advantageous to proactively write these cold pages to swap and reclaim the memory for other use cases. By default, the zswap shrinker is disabled. User can enable it as follows: User can enable it as follows:: echo Y > /sys/module/zswap/parameters/shrinker_enabled Loading