#
905e8919 |
| 16-Mar-2025 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.82' into for/openbmc/dev-6.6
This is the 6.6.82 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfNV3AACgkQONu9yGCS # aT6JOQ//f9BSrRC
Merge tag 'v6.6.82' into for/openbmc/dev-6.6
This is the 6.6.82 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfNV3AACgkQONu9yGCS # aT6JOQ//f9BSrRC1JvkfJeUJ4sOjA7k/Lo22WSxTydbtNR64s/okTUxlE+nF910s # ZDs0E3UAPsZxnGimVVrgN612NFiylQYtESttM5wSCioqyvk76/WugQjz6MQegm1g # sGV8GhiC4dZDzqV5tiiWV0aAAW73H0kQRYepe1RqP/A5nfb5e0ikfY2iu/mFg1UG # 9hUX3iwPFi/Y4JN8UPjZcbJ5E9MlHFfLpmjvMEcBOZjRgjLFRYcMwbX0WSZl0HLJ # x+4Rahnfx2bF6zqoMff8vdxj6UvO9Fc1AucSNxdtWJUxF71NVeQ3GipzL0fEnxwV # SP6oQ0h6rEfwZpZoagtjVlGAgjSTQUMiiKyK2qgPne3JDMo8bx2OhzNZU3L9ltt2 # LmlMqOJR2qv2tFyAl+ei1jre/6OG+AEPC6pnmQc8tNuahIpYaFN5fybeFAxSPvbo # Jyv0pzI1th/kwd5bn8LHHca9OSA/PHT4DPIChVZdpSOuYi2lFVkpbvVocbgOi56S # BuUoV+QfeOrg+QBLPOeKL98UoJI5EJZuBFAQgs3XJH/IUy4MIFLdBzFPzB6alvNl # 8EuI54+IkArDil8YYUyZkH1odG7Ch3o48dZ0v71qZalraC2NhNgxxxj/nDpFNc+h # ZtzyOq96fK6GWtvmwYvUOH5nX7gHq6kjqDkXAj6+DakOedhLjJI= # =e2Yd # -----END PGP SIGNATURE----- # gpg: Signature made Sun 09 Mar 2025 19:25:12 ACDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal] # gpg: gregkh@kernel.org: Verified 11 signatures in the past 7 weeks. Encrypted # 0 messages. # gpg: Warning: you have yet to encrypt a message to this key! # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E
show more ...
|
Revision tags: v6.6.83, v6.6.82, v6.6.81, v6.6.80, v6.6.79, v6.6.78, v6.6.77, v6.6.76, v6.6.75, v6.6.74, v6.6.73, v6.6.72, v6.6.71, v6.12.9, v6.6.70, v6.12.8, v6.6.69, v6.12.7, v6.6.68, v6.12.6, v6.6.67, v6.12.5, v6.6.66, v6.6.65, v6.12.4, v6.6.64, v6.12.3, v6.12.2, v6.6.63, v6.12.1, v6.12, v6.6.62, v6.6.61, v6.6.60, v6.6.59, v6.6.58, v6.6.57, v6.6.56, v6.6.55, v6.6.54, v6.6.53, v6.6.52, v6.6.51, v6.6.50, v6.6.49, v6.6.48, v6.6.47, v6.6.46, v6.6.45, v6.6.44, v6.6.43, v6.6.42, v6.6.41, v6.6.40, v6.6.39, v6.6.38, v6.6.37, v6.6.36, v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
d4c860bb |
| 17-Oct-2023 |
Thomas Gleixner <tglx@linutronix.de> |
x86/microcode: Provide CONFIG_MICROCODE_INITRD32
commit fdbd43819400e74c1c20a646969ea8f71706eb2b upstream
Create an aggregate config switch which covers X86_32, MICROCODE and BLK_DEV_INITRD to avoi
x86/microcode: Provide CONFIG_MICROCODE_INITRD32
commit fdbd43819400e74c1c20a646969ea8f71706eb2b upstream
Create an aggregate config switch which covers X86_32, MICROCODE and BLK_DEV_INITRD to avoid lengthy #ifdeffery in upcoming code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231017211722.236208250@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
0f9b4c3c |
| 11-Mar-2025 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.81' into for/openbmc/dev-6.6
This is the 6.6.81 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfLFMMACgkQONu9yGCS # aT6riRAAjyTT+Ia
Merge tag 'v6.6.81' into for/openbmc/dev-6.6
This is the 6.6.81 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfLFMMACgkQONu9yGCS # aT6riRAAjyTT+IaZXhdNjx56GXicO4l4Spr9VmgecZWBJceNkDETDMof3dhhIHeV # u+wKZKyL/ZBfElLqvMbOUKUK5aw4odI5d1Ri8C3ViYYrCsSTJNXUZ27YnF2xHyql # Aw+otwwNTqDEJENFCLtdXhFBPinBXop5piv/eQeP5qHa1D8OGzl0Ntb1Lan5OIf3 # PIMoX7T5CQUd9cuUiJE9uX8t/VD18hqOrivOUGy7avyIOvaE7GaDt3xEz5Pw+b4l # D+VOaskhFoLcehDlOmLxbKmdUFYMG/h1eSVE9azd9scFRjU5EEbRtOfkMFb8XE6D # rgLY39Zol7dqdxBerqNvmbj1CRFIQfxoOSadKjiSRyZ2POttfSs3IADGOTRj/T/k # +Hj1kFs3wLFoQ5RDRKDrzCq91pC2RcXFe3zQZWxla19Dhx3DwZZa5WlfHzIuFEZX # mfJ7VR4k/ue9EFyvNGHZuAWfB0OcCCZ2WAlc8mXfvp3cIA5arEGvPGnffr/3/jCs # gXxt186um11iSNYzVT1Ia6b7xz33EtHjMXUAnixlyuDK9dUPg6m48KIcTta5WPoP # 7cqPNKDb59sua26TVyf91nb7r+7jp4Zfb9Be/7BxZoLTLxwPeD4gl7Sk7PYDycIk # xmWetnoFhE8aNHJ5hId2LC7zd6jxn8xYHJQffJJ4yCU2ZmRBKI8= # =VWtK # -----END PGP SIGNATURE----- # gpg: Signature made Sat 08 Mar 2025 02:16:11 ACDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal] # gpg: gregkh@kernel.org: Verified 10 signatures in the past 6 weeks. Encrypted # 0 messages. # gpg: Warning: you have yet to encrypt a message to this key! # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E
show more ...
|
#
bef83014 |
| 23-Jan-2025 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/microcode/AMD: Load only SHA256-checksummed patches
commit 50cef76d5cb0e199cda19f026842560f6eedc4f7 upstream
Load patches for which the driver carries a SHA256 checksum of the patch blob.
This
x86/microcode/AMD: Load only SHA256-checksummed patches
commit 50cef76d5cb0e199cda19f026842560f6eedc4f7 upstream
Load patches for which the driver carries a SHA256 checksum of the patch blob.
This can be disabled by adding "microcode.amd_sha_check=off" on the kernel cmdline. But it is highly NOT recommended.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
fba6e6fc |
| 17-Oct-2023 |
Thomas Gleixner <tglx@linutronix.de> |
x86/microcode: Prepare for minimal revision check
commit 9407bda845dd19756e276d4f3abc15a20777ba45 upstream
Applying microcode late can be fatal for the running kernel when the update changes functi
x86/microcode: Prepare for minimal revision check
commit 9407bda845dd19756e276d4f3abc15a20777ba45 upstream
Applying microcode late can be fatal for the running kernel when the update changes functionality which is in use already in a non-compatible way, e.g. by removing a CPUID bit.
There is no way for admins which do not have access to the vendors deep technical support to decide whether late loading of such a microcode is safe or not.
Intel has added a new field to the microcode header which tells the minimal microcode revision which is required to be active in the CPU in order to be safe.
Provide infrastructure for handling this in the core code and a command line switch which allows to enforce it.
If the update is considered safe the kernel is not tainted and the annoying warning message not emitted. If it's enforced and the currently loaded microcode revision is not safe for late loading then the load is aborted.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231017211724.079611170@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.5.7, v6.5.6 |
|
#
7412a65d |
| 02-Oct-2023 |
Thomas Gleixner <tglx@linutronix.de> |
x86/microcode: Handle "nosmt" correctly
commit 634ac23ad609b3ddd9e0e478bd5afbf49d3a2556 upstream
On CPUs where microcode loading is not NMI-safe the SMT siblings which are parked in one of the play
x86/microcode: Handle "nosmt" correctly
commit 634ac23ad609b3ddd9e0e478bd5afbf49d3a2556 upstream
On CPUs where microcode loading is not NMI-safe the SMT siblings which are parked in one of the play_dead() variants still react to NMIs.
So if an NMI hits while the primary thread updates the microcode the resulting behaviour is undefined. The default play_dead() implementation on modern CPUs is using MWAIT which is not guaranteed to be safe against a microcode update which affects MWAIT.
Take the cpus_booted_once_mask into account to detect this case and refuse to load late if the vendor specific driver does not advertise that late loading is NMI safe.
AMD stated that this is safe, so mark the AMD driver accordingly.
This requirement will be partially lifted in later changes.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20231002115903.087472735@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d37cf9b6 |
| 27-Feb-2025 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.80' into for/openbmc/dev-6.6
This is the 6.6.80 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfAV+kACgkQONu9yGCS # aT6Zmg/8CttkpI/
Merge tag 'v6.6.80' into for/openbmc/dev-6.6
This is the 6.6.80 stable release
# -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmfAV+kACgkQONu9yGCS # aT6Zmg/8CttkpI/jr/fq7mVbxHBmz06uZndOgjCt4Qocoy06hIYrV/zKCLXqEHSo # yPzPu6p57fQsJXKZbC6K3H4ZCjkArxT9xXy08jxxYmV091OhZi7fo+otAWgNu2ht # A8cjRkO4MjQ7WfWlPYL8FBuRgv2aPplhCxAtnQy+Lzos3Mk9PyIcgKKGeDQJ/XcE # ecIUxR8ftzAb6X0KDYcM0PhXtKTKZwAo1MiHa18TaXz3cIHmvYfTEOk7om7rtPC/ # n7WxJSM9i0NC0AcIpddlX9e6HqOgjk3sKOlj+aHPin2sl9cWgEKixIsb/PJmWVvi # zNPgfX2MFjX0287K0+TmTPy2rM07bnpv9e0iJDkbc411fEYb2XPxjvp4wPjf5Io3 # 6qOj9OrgRPfTama54j6Tis4cxAtk2gppOA8rxC16okMG39CwEEAbaiZvUezqK4ym # m8fiKccYMCgYxPXVgn0vLSnbzb+zXv0SB9rKuImZstOiiKbVz+xxBTh+0GFezhto # TFzmjEBdh2LYbtQRi/TWn+e6nEjE+LJZgmiq886NRSr9wNAGheYLKSRC1mzwyRKJ # yiA+ue7d1wB+clE+cAcbdVF5YSosV5TggH09Wq64O/pEemC9F2bNWL+oJXODf3NG # JYkjr7FzD1Ka/oCwDJeloDQqwUc4q5cyS+Fb3fK/zrAJZJ2YGTM= # =2PCM # -----END PGP SIGNATURE----- # gpg: Signature made Thu 27 Feb 2025 22:47:45 ACDT # gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E # gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal] # gpg: gregkh@kernel.org: Verified 9 signatures in the past 5 weeks. Encrypted # 0 messages. # gpg: Warning: you have yet to encrypt a message to this key! # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E
show more ...
|
#
60ba9b8a |
| 05-Feb-2025 |
Patrick Bellasi <derkling@google.com> |
x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit
commit 318e8c339c9a0891c389298bb328ed0762a9935e upstream.
In [1] the meaning of the synthetic IBPB flags has been redefined for a better sepa
x86/cpu/kvm: SRSO: Fix possible missing IBPB on VM-Exit
commit 318e8c339c9a0891c389298bb328ed0762a9935e upstream.
In [1] the meaning of the synthetic IBPB flags has been redefined for a better separation of concerns: - ENTRY_IBPB -- issue IBPB on entry only - IBPB_ON_VMEXIT -- issue IBPB on VM-Exit only and the Retbleed mitigations have been updated to match this new semantics.
Commit [2] was merged shortly before [1], and their interaction was not handled properly. This resulted in IBPB not being triggered on VM-Exit in all SRSO mitigation configs requesting an IBPB there.
Specifically, an IBPB on VM-Exit is triggered only when X86_FEATURE_IBPB_ON_VMEXIT is set. However:
- X86_FEATURE_IBPB_ON_VMEXIT is not set for "spec_rstack_overflow=ibpb", because before [1] having X86_FEATURE_ENTRY_IBPB was enough. Hence, an IBPB is triggered on entry but the expected IBPB on VM-exit is not.
- X86_FEATURE_IBPB_ON_VMEXIT is not set also when "spec_rstack_overflow=ibpb-vmexit" if X86_FEATURE_ENTRY_IBPB is already set.
That's because before [1] this was effectively redundant. Hence, e.g. a "retbleed=ibpb spec_rstack_overflow=bpb-vmexit" config mistakenly reports the machine still vulnerable to SRSO, despite an IBPB being triggered both on entry and VM-Exit, because of the Retbleed selected mitigation config.
- UNTRAIN_RET_VM won't still actually do anything unless CONFIG_MITIGATION_IBPB_ENTRY is set.
For "spec_rstack_overflow=ibpb", enable IBPB on both entry and VM-Exit and clear X86_FEATURE_RSB_VMEXIT which is made superfluous by X86_FEATURE_IBPB_ON_VMEXIT. This effectively makes this mitigation option similar to the one for 'retbleed=ibpb', thus re-order the code for the RETBLEED_MITIGATION_IBPB option to be less confusing by having all features enabling before the disabling of the not needed ones.
For "spec_rstack_overflow=ibpb-vmexit", guard this mitigation setting with CONFIG_MITIGATION_IBPB_ENTRY to ensure UNTRAIN_RET_VM sequence is effectively compiled in. Drop instead the CONFIG_MITIGATION_SRSO guard, since none of the SRSO compile cruft is required in this configuration. Also, check only that the required microcode is present to effectively enabled the IBPB on VM-Exit.
Finally, update the KConfig description for CONFIG_MITIGATION_IBPB_ENTRY to list also all SRSO config settings enabled by this guard.
Fixes: 864bcaa38ee4 ("x86/cpu/kvm: Provide UNTRAIN_RET_VM") [1] Fixes: d893832d0e1e ("x86/srso: Add IBPB on VMEXIT") [2] Reported-by: Yosry Ahmed <yosryahmed@google.com> Signed-off-by: Patrick Bellasi <derkling@google.com> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e50e86db |
| 03-Nov-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.59' into for/openbmc/dev-6.6
This is the 6.6.59 stable release
|
#
60a5ba56 |
| 23-Jan-2024 |
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> |
x86/lam: Disable ADDRESS_MASKING in most cases
commit 3267cb6d3a174ff83d6287dcd5b0047bbd912452 upstream.
Linear Address Masking (LAM) has a weakness related to transient execution as described in t
x86/lam: Disable ADDRESS_MASKING in most cases
commit 3267cb6d3a174ff83d6287dcd5b0047bbd912452 upstream.
Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable.
Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled.
There are no processors in market that support LAM yet, so currently nobody is affected by this issue.
[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/
[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ]
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/5373262886f2783f054256babdf5a98545dc986b.1706068222.git.pawan.kumar.gupta%40linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
b181f702 |
| 12-Jun-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.33' into dev-6.6
This is the 6.6.33 stable release
|
#
976b74fa |
| 19-Apr-2024 |
Sean Christopherson <seanjc@google.com> |
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
[ Upstream commit ce0abef6a1d540acef85068e0e82bdf1fbeeb0e9 ]
Explicitly disallow enabling mitigations at runtime for kernels that wer
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
[ Upstream commit ce0abef6a1d540acef85068e0e82bdf1fbeeb0e9 ]
Explicitly disallow enabling mitigations at runtime for kernels that were built with CONFIG_CPU_MITIGATIONS=n, as some architectures may omit code entirely if mitigations are disabled at compile time.
E.g. on x86, a large pile of Kconfigs are buried behind CPU_MITIGATIONS, and trying to provide sane behavior for retroactively enabling mitigations is extremely difficult, bordering on impossible. E.g. page table isolation and call depth tracking require build-time support, BHI mitigations will still be off without additional kernel parameters, etc.
[ bp: Touchups. ]
Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20240420000556.2645001-3-seanjc@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
c1e01cdb |
| 02-May-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.30' into dev-6.6
This is the 6.6.30 stable release
|
#
8292f4f8 |
| 19-Apr-2024 |
Sean Christopherson <seanjc@google.com> |
cpu: Re-enable CPU mitigations by default for !X86 architectures
commit fe42754b94a42d08cf9501790afc25c4f6a5f631 upstream.
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it o
cpu: Re-enable CPU mitigations by default for !X86 architectures
commit fe42754b94a42d08cf9501790afc25c4f6a5f631 upstream.
Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific.
Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution.
Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time.
Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Michael Ellerman <mpe@ellerman.id.au> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
aeddf9a2 |
| 17-Apr-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.28' into dev-6.6
This is the 6.6.28 stable release
|
#
09e6cbe9 |
| 11-Apr-2024 |
Josh Poimboeuf <jpoimboe@kernel.org> |
x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI
commit 4f511739c54b549061993b53fc0380f48dfca23b upstream.
For consistency with the other CONFIG_MITIGATION_* options
x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI
commit 4f511739c54b549061993b53fc0380f48dfca23b upstream.
For consistency with the other CONFIG_MITIGATION_* options, replace the CONFIG_SPECTRE_BHI_{ON,OFF} options with a single CONFIG_MITIGATION_SPECTRE_BHI option.
[ mingo: Fix ]
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Sean Christopherson <seanjc@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nikolay Borisov <nik.borisov@suse.com> Link: https://lore.kernel.org/r/3833812ea63e7fdbe36bf8b932e63f70d18e2a2a.1712813475.git.jpoimboe@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
a823da65 |
| 11-Apr-2024 |
Josh Poimboeuf <jpoimboe@kernel.org> |
x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto
commit 36d4fe147c870f6d3f6602befd7ef44393a1c87a upstream.
Unlike most other mitigations' "auto" options, spectre_bhi=auto only mitig
x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto
commit 36d4fe147c870f6d3f6602befd7ef44393a1c87a upstream.
Unlike most other mitigations' "auto" options, spectre_bhi=auto only mitigates newer systems, which is confusing and not particularly useful.
Remove it.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/412e9dc87971b622bbbaf64740ebc1f140bff343.1712813475.git.jpoimboe@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
86aa961b |
| 10-Apr-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.26' into dev-6.6
This is the 6.6.26 stable release
|
#
6d9ef0c3 |
| 09-Apr-2024 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
x86: set SPECTRE_BHI_ON as default
commit 2bb69f5fc72183e1c62547d900f560d0e9334925 upstream.
Part of a merge commit from Linus that adjusted the default setting of SPECTRE_BHI_ON.
Cc: Linus Torval
x86: set SPECTRE_BHI_ON as default
commit 2bb69f5fc72183e1c62547d900f560d0e9334925 upstream.
Part of a merge commit from Linus that adjusted the default setting of SPECTRE_BHI_ON.
Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d414b401 |
| 11-Mar-2024 |
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> |
x86/bhi: Add BHI mitigation knob
commit ec9404e40e8f36421a2b66ecb76dc2209fe7f3ef upstream.
Branch history clearing software sequences and hardware control BHI_DIS_S were defined to mitigate Branch
x86/bhi: Add BHI mitigation knob
commit ec9404e40e8f36421a2b66ecb76dc2209fe7f3ef upstream.
Branch history clearing software sequences and hardware control BHI_DIS_S were defined to mitigate Branch History Injection (BHI).
Add cmdline spectre_bhi={on|off|auto} to control BHI mitigation:
auto - Deploy the hardware mitigation BHI_DIS_S, if available. on - Deploy the hardware mitigation BHI_DIS_S, if available, otherwise deploy the software sequence at syscall entry and VMexit. off - Turn off BHI mitigation.
The default is auto mode which does not deploy the software sequence mitigation. This is because of the hardening done in the syscall dispatch path, which is the likely target of BHI.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
46eeaa11 |
| 03-Apr-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.24' into dev-6.6
This is the 6.6.24 stable release
|
#
ecd16da3 |
| 02-Feb-2024 |
Borislav Petkov (AMD) <bp@alien8.de> |
x86/Kconfig: Remove CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
commit 29956748339aa8757a7e2f927a8679dd08f24bb6 upstream.
It was meant well at the time but nothing's using it so get rid of it.
Signed
x86/Kconfig: Remove CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
commit 29956748339aa8757a7e2f927a8679dd08f24bb6 upstream.
It was meant well at the time but nothing's using it so get rid of it.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20240202163510.GDZb0Zvj8qOndvFOiZ@fat_crate.local Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
f8b04488 |
| 17-Mar-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.22' into dev-6.6
Linux 6.6.22
|
#
77018fb9 |
| 11-Mar-2024 |
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> |
x86/rfds: Mitigate Register File Data Sampling (RFDS)
commit 8076fcde016c9c0e0660543e67bff86cb48a7c9c upstream.
RFDS is a CPU vulnerability that may allow userspace to infer kernel stale data previ
x86/rfds: Mitigate Register File Data Sampling (RFDS)
commit 8076fcde016c9c0e0660543e67bff86cb48a7c9c upstream.
RFDS is a CPU vulnerability that may allow userspace to infer kernel stale data previously used in floating point registers, vector registers and integer registers. RFDS only affects certain Intel Atom processors.
Intel released a microcode update that uses VERW instruction to clear the affected CPU buffers. Unlike MDS, none of the affected cores support SMT.
Add RFDS bug infrastructure and enable the VERW based mitigation by default, that clears the affected buffers just before exiting to userspace. Also add sysfs reporting and cmdline parameter "reg_file_data_sampling" to control the mitigation.
For details see: Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
3386ee82 |
| 10-Feb-2024 |
Andrew Jeffery <andrew@codeconstruct.com.au> |
Merge tag 'v6.6.10' into dev-6.6
This is the 6.6.10 stable release
|