Age | Commit message (Collapse) | Author |
|
This is the 5.4.275 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYzoYAACgkQONu9yGCS
# aT5Gog/8DiBn13NgIqTvlQucOpiKcQrFS6ghuLjWUj+H+toaBPCoiAaSNzDgk3a6
# Vc7aW+/H6035Wpt6qmA9nr9VljS4JgHRlxPbp442zcXoaQabxXstt80s05EgC+ue
# MamCnirQwtkSaHYTQDHwumyr+J73b/EM6w0MHinmKJKbmLOpF6ejt87bBN8i1i4N
# 0/atD79jq6l3wOIwNpJI5hIdc/OwNKnCd0M1lQL60XQgN+4Yc5Gup/BazSnVzTHN
# PvkyqJOPSHcOcTkaDsS6t6RRJ5fQcHDihEPILwQuyqDbasyVULaNWxuZjVUeXbIS
# rcgrlPTsJB1KjtZuGSkSCmj3FrmBBhs9Fd2HBEGE2UfShJa1c4O/Hbmq3sHvijUQ
# i8Oaakkx0Z4XKiXf5djwG0QNm4vT8M+nBDNTxw+/pzWg2L0uzlpVh87YwODsrtT2
# /WHQ0B1MFXncCDebweXqlxTWKRCoqR183MjMedDJt25smCKp1RZZR7pJb9c065Mn
# bg2benOfKUr/+Us5oiQboV3XZkZiPc39V/E6J9NjYE62EPht6Gb/yoblFKp9t+/f
# 8MYPXqyAjGGXIzkqD7e1+YyOH6N/96EOZ2TrLhZiMb/3W6+dCjc1YeFtquNmaN9b
# pdYhzG3qlneflRNTz/30YKIyMQE5Zv+1DMR2mpBSD4hvSEYCmE4=
# =yaox
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 02 May 2024 10:21:52 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 5.4.274 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmYaZJMACgkQONu9yGCS
# aT4fYxAAwlCrdAhIzqVcOGR9fgr0spXmY9c85YpqOtBGQJO4OTr/wvbNpBx3/kqo
# 6Va+R1sebIIHMSz84R7wy0C63Kzm5FdpKto0cEOTOZUuUPLueFb1cVNuPFRvn2iF
# g0PrRepX1jxAHBGiI5eE6vxFzSfx5RfS5tU3AWbpQ/7j9ytIoowxfrb3hi5c3nS5
# 2OHhWtg9TvA5S+l+I4m42aJUeK70vJfFCWQNnufD6RJNT6aukke2AqgemzKof3R7
# UWDLRvcuCEx0oSQZvXtAJJQ6+4sL9DVRUsff1bS2BNDeI26G93AhbahX1FhsHFNq
# iJ4AMVRECwyjlsMjm9WhsU2p28EHa2Y4QA8oz2BdbUrmKSaSf7FkWsy0T4cs4TXe
# bWrqLMp63yjXiiEQFOWtgjFCq4M8jMBHRvnDM/3FcFyTvRXw8mDo2DH9WwLNmGxG
# 9gMJW36J/jN3hDB/aMzno8RqvnGBsZGioXsB1QO+vtLSedGknITZeX3g5PnqqA8N
# Ebb6VXR5kmX+Abm6odMFDjnBSEHVvGQap6jGvJqWuXV1hR8zsblBrvbeA+SEuoX7
# FX5E+5dGkc9EKdrQa9LpFnbHLCQQ4jmLTzzjJ0xxB3kLzCeKigsyoltLSlRE/0tt
# j8upZAXWBBDIBJHFwG7luoZA3rU42pLgWWAfjq/0Rerl3olYxEc=
# =HbFv
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 13 Apr 2024 06:55:15 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 9543f6e26634537997b6e909c20911b7bf4876de ]
Fix cpuid_deps[] to list the correct dependencies for GFNI, VAES, and
VPCLMULQDQ. These features don't depend on AVX512, and there exist CPUs
that support these features but not AVX512. GFNI actually doesn't even
depend on AVX.
This prevents GFNI from being unnecessarily disabled if AVX is disabled
to mitigate the GDS vulnerability.
This also prevents all three features from being unnecessarily disabled
if AVX512VL (or its dependency AVX512F) were to be disabled, but it
looks like there isn't any case where this happens anyway.
Fixes: c128dbfa0f87 ("x86/cpufeatures: Enable new SSE/AVX/AVX512 CPU features")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20240417060434.47101-1-ebiggers@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 3ddf944b32f88741c303f0b21459dbb3872b8bc5 upstream.
Modifying a MCA bank's MCA_CTL bits which control which error types to
be reported is done over
/sys/devices/system/machinecheck/
├── machinecheck0
│ ├── bank0
│ ├── bank1
│ ├── bank10
│ ├── bank11
...
sysfs nodes by writing the new bit mask of events to enable.
When the write is accepted, the kernel deletes all current timers and
reinits all banks.
Doing that in parallel can lead to initializing a timer which is already
armed and in the timer wheel, i.e., in use already:
ODEBUG: init active (active state 0) object: ffff888063a28000 object
type: timer_list hint: mce_timer_fn+0x0/0x240 arch/x86/kernel/cpu/mce/core.c:2642
WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
does.
Reported by: Yue Sun <samsun1006219@gmail.com>
Reported by: xingwei lee <xrivendell7@gmail.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/CAEkJfYNiENwQY8yV1LYJ9LjJs%2Bx_-PqMv98gKig55=2vbzffRw@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fd470a8beed88440b160d690344fbae05a0b9b1b upstream.
Unlike Intel's Enhanced IBRS feature, AMD's Automatic IBRS does not
provide protection to processes running at CPL3/user mode, see section
"Extended Feature Enable Register (EFER)" in the APM v2 at
https://bugzilla.kernel.org/attachment.cgi?id=304652
Explicitly enable STIBP to protect against cross-thread CPL3
branch target injections on systems with Automatic IBRS enabled.
Also update the relevant documentation.
Fixes: e7862eda309e ("x86/cpu: Support AMD Automatic IBRS")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230720194727.67022-1-kim.phillips@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 5c84b051bd4e777cf37aaff983277e58c99618d5 ]
Update them to the correct revision numbers.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 1d30800c0c0ae1d086ffad2bdf0ba4403370f132 upstream.
Those mitigations are very talkative; use the printing helper which pays
attention to the buffer size.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220809153419.10182-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e7862eda309ecfccc36bb5558d937ed3ace07f3f upstream.
The AMD Zen4 core supports a new feature called Automatic IBRS.
It is a "set-and-forget" feature that means that, like Intel's Enhanced IBRS,
h/w manages its IBRS mitigation resources automatically across CPL transitions.
The feature is advertised by CPUID_Fn80000021_EAX bit 8 and is enabled by
setting MSR C000_0080 (EFER) bit 21.
Enable Automatic IBRS by default if the CPU feature is present. It typically
provides greater performance over the incumbent generic retpolines mitigation.
Reuse the SPECTRE_V2_EIBRS spectre_v2_mitigation enum. AMD Automatic IBRS and
Intel Enhanced IBRS have similar enablement. Add NO_EIBRS_PBRSB to
cpu_vuln_whitelist, since AMD Automatic IBRS isn't affected by PBRSB-eIBRS.
The kernel command line option spectre_v2=eibrs is used to select AMD Automatic
IBRS, if available.
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Sean Christopherson <seanjc@google.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20230124163319.2277355-8-kim.phillips@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.271 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXof14ACgkQONu9yGCS
# aT4K1Q//Wt8oz/83saKdDP4Uo51NWuyLHCLzBotCKDP1f5g4gTZbvZzzDsC+jCPB
# Tavkw3BHPLfIpvDt5WV8eKTGrkbmw/xIyLqUyDxZDD7hx8p7YJ3lMBcSfZvP/YGm
# 1vmiQDmTp6ZIfh5Fl9aNjYDkS/HxRVHlZMJx2ERI480Zm7FbtbCVUYK1gkHGHXYD
# aVW3X7UKsZVYvK2I4jI5IGg/zP0PTfH9XnFRTm5WRvOLoRYF8eFZ2NiBHACkZyoh
# UWYc5Kl0rdurSkPEo8qN1KPDagbxyGhCVU2v+tpSNC3eeSF3WkNCvuCD7zX4LRkJ
# 3FSxB7oVmgKn95/BREwkcegzDD9ZwTaXFuQVelWF4+ajdjCEMkxOuUoFajSI83IG
# LXHHIn4WYkcSkokgdaYGTP6CbdqSvcuLJCfS/ANwFvdsBSUylBGHbUuc+53jD754
# sbNBLZnWIiERSx6mUy3/jGwMfncDEroouMZVL3YkXkDuWYryZEDvIdP7jMsZ2u6d
# GM6EmGbi7aWsxdaPr+B638ph58eFkvTdcLyAwp+Sn5AORK2569Gg0Rubhl+xX54X
# y8Wa7+93ohh59yifQll2OqDLN+Wlj6Sg1smvitjdyiK4Od7Id0plJ7Gzg1Wj97C+
# vGkD33vfH++tvZdsNU6Ynw4oY2mQ7fBOqhCm5XavDFXDUMOZI2s=
# =XlXs
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 06 Mar 2024 09:36:14 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 5.4.269 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmXYSHgACgkQONu9yGCS
# aT74ag/6AqWJBzK/2xvUCYjfBU5+4ApFWQt47Ly9MKFhFX7YBjQGXS6av1YFA9Kw
# i01R9SCpIv2eaDrM7/J0wvXGybemfvQ8VyNngG30QC/0jTc4ZAj0PEbtyHpUaz4F
# HWOFfAlHAYcLQWhmjhXitoGUfeyhchWnQZpn45mkT0i3DSAEFc5gsiMlO+jaM8No
# hOaAHEpGsd7zlH32NYpWrFI0i54HSCwlaHlQFJ7U+rbWyG935RdLjMAX+488R8oc
# KccOj+xb4zQyASdC7qdgPz02U7Tm3UB5s0lLrviDiBrYVxSe77vw2TBEeejF+7ZE
# oYqjsygRYmRbKuI55rxyxph7cT93ZctL48DZJ4fT4zVIT9kak3S/NtFs0Hyr3TkY
# N6ZlDnd10cj8QsnXXtTd9QgT7Ind+3KySv7sr4a/gLO/N39EYpztrMCc/lKfG/Bu
# MPDMXBrEtKkjMelcnISwac9QcOb/MAJaepCWtYgcXbEcaBP+/Or8OM0yZPOEk7SA
# 3CamE+ou0Ds/c6gnsBw6WDMTJd+sX6sw6+4cMEaWzaWiE12Ryc0gscCDJXjEAYzc
# +47PiPijNJ+iPjsos8ZaNnTQHALemgJ4cjolHivsEvAYU1s5cyKjVEgMB1MJN8ib
# y19D9L8T9BtG2ukWBxtIXMIt51VZ7B8fXodcYXbyqtV25JZj/k8=
# =cJfu
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 23 Feb 2024 02:25:44 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 6890cb1ace350b4386c8aee1343dc3b3ddd214da upstream.
MKTME repurposes the high bit of physical address to key id for encryption
key and, even though MAXPHYADDR in CPUID[0x80000008] remains the same,
the valid bits in the MTRR mask register are based on the reduced number
of physical address bits.
detect_tme() in arch/x86/kernel/cpu/intel.c detects TME and subtracts
it from the total usable physical bits, but it is called too late.
Move the call to early_init_intel() so that it is called in setup_arch(),
before MTRRs are setup.
This fixes boot on TDX-enabled systems, which until now only worked with
"disable_mtrr_cleanup". Without the patch, the values written to the
MTRRs mask registers were 52-bit wide (e.g. 0x000fffff_80000800) and
the writes failed; with the patch, the values are 46-bit wide, which
matches the reduced MAXPHYADDR that is shown in /proc/cpuinfo.
Reported-by: Zixi Chen <zixchen@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc:stable@vger.kernel.org
Link: https://lore.kernel.org/all/20240131230902.1867092-3-pbonzini%40redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 9f3b130048bfa2e44a8cfb1b616f826d9d5d8188 ]
Memory errors don't happen very often, especially fatal ones. However,
in large-scale scenarios such as data centers, that probability
increases with the amount of machines present.
When a fatal machine check happens, mce_panic() is called based on the
severity grading of that error. The page containing the error is not
marked as poison.
However, when kexec is enabled, tools like makedumpfile understand when
pages are marked as poison and do not touch them so as not to cause
a fatal machine check exception again while dumping the previous
kernel's memory.
Therefore, mark the page containing the error as poisoned so that the
kexec'ed kernel can avoid accessing the page.
[ bp: Rewrite commit message and comment. ]
Co-developed-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Link: https://lore.kernel.org/r/20231014051754.3759099-1-zhiquan1.li@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
The stable kernel version backport of the patch disabling XSAVES on AMD
Zen family 0x17 applied this change to the wrong function (init_amd_k6()),
one which isn't called for Zen CPUs.
Move the erratum to the init_amd_zn() function instead.
Add an explicit family 0x17 check to the erratum so nothing will break if
someone naively makes this kernel version call init_amd_zn() also for
family 0x19 in the future (as the current upstream code does).
Fixes: e40c1e9da1ec ("x86/CPU/AMD: Disable XSAVES on AMD family 0x17")
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.264 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmV5528ACgkQONu9yGCS
# aT7+DxAAl/t4oGT1Di8mIhCfqsezTj/SQ6HAMaAFpKjGXdgTBX9QavwTHp35qLpv
# xZtibdl611oEDT2B3//cvJu9Qs8sJGlDWxpJF8fkF/NED2EHLRwUAOmhc4fyBCBq
# 01GfPRefU9G5E0Nw2g3o07dD0otKQzENh74iAzUr/cyju5TBgS4NC7CljiD6GXP8
# DtCcbz2UMmHF5icyasjw7WoCqKaWUn7KLqU3RyQfmDgnh3z0vSXKs17CFoNk1+R6
# EAkZJkrUsIDO3N6aRkJGvwtbEFDws4S7onpcthckXt6IF/OQ+h8LcHvyTpblVeWH
# qVBXmj1QZD+SwfP5qVtM+RwHHTE3GVJI3+MVTInu0vzgEz6lhNPILzWwso+AIhHM
# +SBZkx4/pO2LbrSgqn+NYWRcBTn4fXNURPd+zLXNJ1ZSnhamWm7kuFK8B36lz0s8
# CB5ngLld1wg6m2NVPneqAeEcD54msGd18iNZvnxfx3c28sb27RgLqLJQKdSrtFMH
# tZj0+3KGkYHzWQmt07iLmg1DPAmZSNzMW7MDJRHlqDCKS2gBKO/LKxWiri2WPh+o
# IvgrfGzEJsyYXi5+JcGC9+RkoPcGaous4VA2kWFJSjXiXPrJC4jknQm3mtdMiTf3
# V9DEOMvot9ELGI9RODaNsk59C2RhOuVimm2XWV9n88UcX38reAQ=
# =gOna
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Dec 2023 12:18:39 PM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 9b8493dc43044376716d789d07699f17d538a7c4 upstream.
Commit in Fixes added an AMD-specific microcode callback. However, it
didn't check the CPU vendor the kernel runs on explicitly.
The only reason the Zenbleed check in it didn't run on other x86 vendors
hardware was pure coincidental luck:
if (!cpu_has_amd_erratum(c, amd_zenbleed))
return;
gives true on other vendors because they don't have those families and
models.
However, with the removal of the cpu_has_amd_erratum() in
05f5f73936fa ("x86/CPU/AMD: Drop now unused CPU erratum checking function")
that coincidental condition is gone, leading to the zenbleed check
getting executed on other vendors too.
Add the explicit vendor check for the whole callback as it should've
been done in the first place.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Cc: <stable@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20231201184226.16749-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.262 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVmGmUACgkQONu9yGCS
# aT4V7A//YzFdP4ANGVpZ7tBob7OxpgGgvEu32zCDx51LQ8n2uJRJ8WBWW6kVOBUZ
# YyUEXzjPPaS7JRS1O7TpCGYFWrH0ue9c/xzyvUQyyHEBZvZVj0P3O1iHlAk2FWSG
# pOTEfW1cFp8vtHwGn82rmIDETu56LMWd+aeVhg6psb2L6ho2LPipCkxN79kbBGSB
# DLfD71O2Pb3mw8ZYHVC5KKIlfODLqjq9N6T+3VsG4uQCEMHTVAHjjoIvYFeSi1cR
# MqPXS4/3GUyYUDTe2tjYznkSfPbdARfD1aKKPEXLuq1+q6WqvHCAG7nwgtPT/gd9
# JPCxm+9DPN9+YhmEsCJpMSq3pD2eTrD5ZXhYFNc5sOsNw0L4oFRLtrB782snerw+
# ogQ8DED4qATn1+x7jfRD7hwMzHih4nAL7zqy32s8knKHfp1+rOOkXfIohfc9qrUI
# svUjb1B+guuGHwFq6YDzxpUxmhdGqOo262cnU4jfH8lxH+w03vyNxxyQn0ZUUe2I
# gkvJ5wNpq4QhD/++B/DaCptw0l5AzfjOO+0xlp20xMzn5qW/BS8W26zUXhGeLOAd
# MHu+fv9DU0mzs3V1MxRvbBQ5gI9TngRWXJSIBCJx5YhZ8gGIhfrzoIzY+IeF6l3F
# idjruirbfujAQv0vQHuz7JmhHrTG+T90slQ/R8pPud73WGz5BMI=
# =A+DX
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 28 Nov 2023 11:50:45 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit ee545b94d39a00c93dc98b1dbcbcf731d2eadeb4 upstream.
Hygon processors with a model ID > 3 have CPUID leaf 0xB correctly
populated and don't need the fixed package ID shift workaround. The fixup
is also incorrect when running in a guest.
Fixes: e0ceeae708ce ("x86/CPU/hygon: Fix phys_proc_id calculation logic for multi-die processors")
Signed-off-by: Pu Wen <puwen@hygon.cn>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/tencent_594804A808BD93A4EBF50A994F228E3A7F07@qq.com
Link: https://lore.kernel.org/r/20230814085112.089607918@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.259 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmU45Z4ACgkQONu9yGCS
# aT4uQBAAwuF2OjLhBjrl9Kfanyd+lpB0rimvwjGVqo7CVfgkKAJ49gjY1aIsKc9f
# 1x58hIvIB6YZzmmyaYrPxO2+Jc8EJ1M5AY4v9/jIkzcT1tfLUKPt2xAt4N3ismQX
# To/Hi0lKhJYFXXBW1ht2apXYil+9Cm4FWrbx1HUMURybHmc9pSdPg5VGdfuLYrcu
# D1gdW6Vap++QG88IoYZWbiKaaJVV3C7lE1n5Brwn/sUxFpfUB8deOxPqx2ktW2sJ
# SAwA/lUSoUvm3/TXZs8FdJMCLyI7AN3DvQOJBDUs2yY59MyolQJ9T1Duq/XlHUSi
# ppoLBp/rtCjAsUx9ZBCsWnvXnYFFNLDKVSyl8yqBDkeLrg0XNNrkYlRWbMTgao5G
# 6X/qx8UjWiLt/Rvl2RlAKJJgZysoh3e8m2BF2HMgS8uWbt5YKX2P3cTuOZXordff
# aemw00dZr2ZZM0hcQvAG2bVmJI16QZuwhvyXbp+kU/sUbmTlCw7PnDuss+Tfka5g
# jfZKlF+/4zbU7WPcAcUkgrPNqyj7BptQGI16AIzFOoZngz4TmGlH5H6lR569NIbk
# aYkgus3Z5AX4Zwc/xhRQkBI99zZ3jggjNXi7i1nDZBATPT7o4nKGl9c5nq84GYVv
# DGKeYJ1C0Rig+WOrmZzPaR5ECtipUhMxMxCnZZ5YzjnxPl8enas=
# =SeME
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 25 Oct 2023 05:53:34 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit f454b18e07f518bcd0c05af17a2239138bff52de upstream.
Fix erratum #1485 on Zen4 parts where running with STIBP disabled can
cause an #UD exception. The performance impact of the fix is negligible.
Reported-by: René Rebe <rene@exactcode.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: René Rebe <rene@exactcode.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/D99589F4-BC5D-430B-87B2-72C20370CF57@exactcode.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.257 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOqSMACgkQONu9yGCS
# aT6xIg//SVVT7zeyVcdNSchMLT6N1sJKtnplNnhyM6oFPlnyRJbgm608p394osx9
# bMkz8QNPugdJz075nFt1blC2qqh2GqNkgaAM1bSKrVmUhBR3ouaO2vKfTamd1qkQ
# uHjE2+4NSlJu0zeqF+D+xmYYo3W32XXfDjn64p3dYiEVFtM4J0r633OpkNTZL3KR
# b8Ooj0sE6WtG5Lt4I64z74/p8QjK8ESW7N7hYUjADadoycn7ms5wwED6KbXwO+Ed
# 3piSteS8bddtx+s6pblRwHvRcOMU3NX0rVG8x3lBtdnjAk32/HEsUm7mAycqJdsJ
# TQ67UJ4gyqzrCtDfrbhZ9hKpaEHGuy6nnjKfXtnlSKZ+8h4uuxK0rIwFlZuS+sjH
# Xm99yiA6KK+CbdR9/ltgQyr5kaTcIqauA6VTjbqqJ3Fuj4OWEz3N2ALUpWeLPNpe
# Enl7b5/eQ4B0sDOYDVG4HsjRTt7ZgNVGFxRRp8ZulDKgX9G4M0K2khq/b3PM9aEQ
# gkgWDxLt3H0EO+6mRgCA0J3a/TSC6gPgV8t8iNcg5rzlXngJzAajdgi7HBMnhPdl
# 8y8JCfojtA+RuHWHOEmPXJG1AmwQ4df7szVxbv8WDuidIqv2tb09POo38s/UWHeN
# NGM5nh1WSCs4hQBfkx4wk58xSZ/jAh4/Uq6g3GasmqlknhA8TjQ=
# =dWOv
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 05:00:19 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit c9f4c45c8ec3f07f4f083f9750032a1ec3eab6b2 ]
The Gather Data Sampling (GDS) vulnerability is common to all Skylake
processors. However, the "client" Skylakes* are now in this list:
https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html
which means they are no longer included for new vulnerabilities here:
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
or in other GDS documentation. Thus, they were not included in the
original GDS mitigation patches.
Mark SKYLAKE and SKYLAKE_L as vulnerable to GDS to match all the
other Skylake CPUs (which include Kaby Lake). Also group the CPUs
so that the ones that share the exact same vulnerabilities are next
to each other.
Last, move SRBDS to the end of each line. This makes it clear at a
glance that SKYLAKE_X is unique. Of the five Skylakes, it is the
only "server" CPU and has a different implementation from the
clients of the "special register" hardware, making it immune to SRBDS.
This makes the diff much harder to read, but the resulting table is
worth it.
I very much appreciate the report from Michael Zhivich about this
issue. Despite what level of support a hardware vendor is providing,
the kernel very much needs an accurate and up-to-date list of
vulnerable CPUs. More reports like this are very welcome.
* Client Skylakes are CPUID 406E3/506E3 which is family 6, models
0x4E and 0x5E, aka INTEL_FAM6_SKYLAKE and INTEL_FAM6_SKYLAKE_L.
Reported-by: Michael Zhivich <mzhivich@akamai.com>
Fixes: 8974eb588283 ("x86/speculation: Add Gather Data Sampling mitigation")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.4.254 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTc9xQACgkQONu9yGCS
# aT4VrQ//aeDhl35R4kgB8ZYcv2EHa9DgE+cDkFYIUruQ029jPET1NkMuXMiWys2K
# trzC5VCAawfac8jHR4kAetP2W6ydHgSQprtUxjgjIwKlPgiFQOla5/DXNqMGTv9Y
# fFKcIfgpef9OkvPr46LHf1S4i3H8vaVu3pN40gEnIAPu4Rgz3wvbmi6BoSTszThI
# MrbOu70iRxVxF8+3HR8G3Ja6bly4dTl2Y36P6G+JPAQc8+X9RT1Yv39kiAg7TSzP
# i/SIn2G5pNu2+BMcxUn0SO13YXPYIGQTZ6xLX13QIDEuoqQRjDB9vZPaKoSm7170
# Nh1JjvUXy72/zvDJYJWzbrL/o4AfS2tHBNTUq5loXO4LPvbmg18g3Xysuk6vRBmG
# NjOpbG9PK3MCwWEQIdEAgtFF6hw74MF/UM7b1Tty3FAaWf4Ca75vY5acqSy4Fhbx
# KuBnNGZTaRJRCUFeEBtAz8sIeFCclfuSpBhrQzj8zCkDT59PuiWJ7wyW1yAizMtE
# VNvDJFxdQXtU06AHWJxp9msWiXYBZbFfk75MVTxnZLS3SDJuJ40fDjjGCM4WciMg
# gBLS+v4tO67KEuhj8t50WJW4Kk7P1Q0j3QkItHOMMRpsJQZF3z8rqEqthAacEaAH
# hVvB2OxpXicqpHwrFW3DZuxzgfJd6sofaKq85/2I7FullRyXVjg=
# =6G08
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 16 Aug 2023 12:19:32 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 6dbef74aeb090d6bee7d64ef3fa82ae6fa53f271 upstream.
Commit
522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
provided a fix for the Zen2 VZEROUPPER data corruption bug affecting
a range of CPU models, but the AMD Custom APU 0405 found on SteamDeck
was not listed, although it is clearly affected by the vulnerability.
Add this CPU variant to the Zenbleed erratum list, in order to
unconditionally enable the fallback fix until a proper microcode update
is available.
Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230811203705.1699914-1-cristian.ciocaltea@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b3607269ff57fd3c9690cb25962c5e4b91a0fd3b upstream.
This cannot work and it's unclear how that ever made a difference.
init_fpstate.xsave.header.xfeatures is always 0 so get_xsave_addr() will
always return a NULL pointer, which will prevent storing the default PKRU
value in init_fpstate.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210623121451.451391598@linutronix.de
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.252 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTSgdwACgkQONu9yGCS
# aT4tfg/9GUHbPrj8Eo7IRWoaPXmlDT6GCCtjwJm6l09BebEwNN3t7Rg8e+uPkrof
# dUdLwQbdYwwLcwjbvE/ZF9UxcYbH7dSWzfBYs1dkcY9oQ6gPl+8Qq1Ld3KvG9BmI
# 7hFdV4dpOv/0hPUmS9PNSOZhD1eiqdqKJxlvul3v7RJhSSV8Ppwiq23Q+gn9U8pR
# aMF9PDCHpfLvtR68jkl+gJb/VE9vwlWog0V2TCIovJxkbrmc3UWmA1KOjXFv6QnF
# fsfWEH4tCYOYWjYkYFGWyIcfdFT4VjSJQsOOVwzpZV7ttZW5q5I3YLXulIvi4uai
# 3kOewYbnGhRSO5abuarn/nxlXM1nukiyYU00PqA/p2kiQyNFyXEO8UeEDE9pnbZh
# GSwShxL+g++AEkP12wbQQajCGPYqWYFKIiEtOiVKY3SM7Twd2JHgmmA0xNa9TAQn
# cMFHklx2867ZQzOdVDLIrEkm9nC/pLxJRMGnKMkwyv6WMVga3tADmuXSxhkCLfNZ
# 6tUCrOi+b3c5teeWc1kQ1qc8uPFUDIE0TV+4LXK8tHd0C25bN8ws+ilTc7J1g9Ki
# W3KeTetOyeW39u4MH9l1WW2YOlAI3NL92XEJAhvPHCbB84lSTdO3YMvneiaHQ8/t
# NHavaEimMlw1krV1G8ko2YR+q8TN1rLMmSMAhLwyzxKKvCh+w20=
# =IU0F
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 08 Aug 2023 01:56:44 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
Stable-tree-only change.
Due to the way the GDS and SRSO patches flowed into the stable tree, it
was a 50% chance that the merge of the which value GDS and SRSO should
be. Of course, I lost that bet, and chose the opposite of what Linus
chose in commit 64094e7e3118 ("Merge tag 'gds-for-linus-2023-08-01' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
Fix this up by switching the values to match what is now in Linus's tree
as that is the correct value to mirror.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8415a74852d7c24795007ee9862d25feb519007c upstream.
Add support for CPUID leaf 80000021, EAX. The majority of the features will be
used in the kernel and thus a separate leaf is appropriate.
Include KVM's reverse_cpuid entry because features are used by VM guests, too.
[ bp: Massage commit message. ]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20230124163319.2277355-2-kim.phillips@amd.com
[bwh: Backported to 6.1: adjust context]
Signed-off-by: Ben Hutchings <benh@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fb35d30fe5b06cc24444f0405da8fbe0be5330d1 upstream.
Collect the scattered SME/SEV related feature flags into a dedicated
word. There are now five recognized features in CPUID.0x8000001F.EAX,
with at least one more on the horizon (SEV-SNP). Using a dedicated word
allows KVM to use its automagic CPUID adjustment logic when reporting
the set of supported features to userspace.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Link: https://lkml.kernel.org/r/20210122204047.2860075-2-seanjc@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 69372cf01290b9587d2cee8fbe161d75d55c3adc upstream.
On systems that do not have hardware enforced cache coherency between
encrypted and unencrypted mappings of the same physical page, the
hypervisor can use the VM page flush MSR (0xc001011e) to flush the cache
contents of an SEV guest page. When a small number of pages are being
flushed, this can be used in place of issuing a WBINVD across all CPUs.
CPUID 0x8000001f_eax[2] is used to determine if the VM page flush MSR is
available. Add a CPUID feature to indicate it is supported and define the
MSR.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <f1966379e31f9b208db5257509c4a089a87d33d0.1607620209.git.thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 360e7c5c4ca4fd8e627781ed42f95d58bc3bb732 upstream.
Add CPU feature detection for Secure Encrypted Virtualization with
Encrypted State. This feature enhances SEV by also encrypting the
guest register state, making it in-accessible to the hypervisor.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200907131613.12703-6-joro@8bytes.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 81ac7e5d741742d650b4ed6186c4826c1a0631a7 upstream
Gather Data Sampling (GDS) is a transient execution attack using
gather instructions from the AVX2 and AVX512 extensions. This attack
allows malicious code to infer data that was previously stored in
vector registers. Systems that are not vulnerable to GDS will set the
GDS_NO bit of the IA32_ARCH_CAPABILITIES MSR. This is useful for VM
guests that may think they are on vulnerable systems that are, in
fact, not affected. Guests that are running on affected hosts where
the mitigation is enabled are protected as if they were running
on an unaffected system.
On all hosts that are not affected or that are mitigated, set the
GDS_NO bit.
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-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>
|
|
commit 53cf5797f114ba2bd86d23a862302119848eff19 upstream
Gather Data Sampling (GDS) is mitigated in microcode. However, on
systems that haven't received the updated microcode, disabling AVX
can act as a mitigation. Add a Kconfig option that uses the microcode
mitigation if available and disables AVX otherwise. Setting this
option has no effect on systems not affected by GDS. This is the
equivalent of setting gather_data_sampling=force.
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-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>
|
|
commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream
The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.
Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.
Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.
This option will be ignored if cmdline mitigations=off.
This is a *big* hammer. It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration. Unfortunately, such userspace
does exist in the wild:
https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html
[ dhansen: add some more ominous warnings about disabling AVX ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-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>
|
|
commit 8974eb588283b7d44a7c91fa09fcbaf380339f3a upstream
Gather Data Sampling (GDS) is a hardware vulnerability which allows
unprivileged speculative access to data which was previously stored in
vector registers.
Intel processors that support AVX2 and AVX512 have gather instructions
that fetch non-contiguous data elements from memory. On vulnerable
hardware, when a gather instruction is transiently executed and
encounters a fault, stale data from architectural or internal vector
registers may get transiently stored to the destination vector
register allowing an attacker to infer the stale data using typical
side channel techniques like cache timing attacks.
This mitigation is different from many earlier ones for two reasons.
First, it is enabled by default and a bit must be set to *DISABLE* it.
This is the opposite of normal mitigation polarity. This means GDS can
be mitigated simply by updating microcode and leaving the new control
bit alone.
Second, GDS has a "lock" bit. This lock bit is there because the
mitigation affects the hardware security features KeyLocker and SGX.
It needs to be enabled and *STAY* enabled for these features to be
mitigated against GDS.
The mitigation is enabled in the microcode by default. Disable it by
setting gather_data_sampling=off or by disabling all mitigations with
mitigations=off. The mitigation status can be checked by reading:
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-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>
|
|
commit b81fac906a8f9e682e513ddd95697ec7a20878d4 upstream
Initializing the FPU during the early boot process is a pointless
exercise. Early boot is convoluted and fragile enough.
Nothing requires that the FPU is set up early. It has to be initialized
before fork_init() because the task_struct size depends on the FPU register
buffer size.
Move the initialization to arch_cpu_finalize_init() which is the perfect
place to do so.
No functional change.
This allows to remove quite some of the custom early command line parsing,
but that's subject to the next installment.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.902376621@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1f34bb2a24643e0087652d81078e4f616562738d upstream
Nothing in the call chain requires it
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.783704297@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 439e17576eb47f26b78c5bbc72e344d4206d2327 upstream
Invoke the X86ism mem_encrypt_init() from X86 arch_cpu_finalize_init() and
remove the weak fallback from the core code.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230613224545.670360645@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7c7077a72674402654f3291354720cd73cdf649e upstream
check_bugs() is a dumping ground for finalizing the CPU bringup. Only parts of
it has to do with actual CPU bugs.
Split it apart into arch_cpu_finalize_init() and cpu_select_mitigations().
Fixup the bogus 32bit comments while at it.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230613224545.019583869@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.251 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTCEMUACgkQONu9yGCS
# aT52vhAAr5fuA8n3nANC/iWrnV+tR7PS9+ncqxloumGgIPnFijlCpB7DBoK7KAPw
# cs83aMisxfvWkSPuQebqY2xO2dUX03DiySCNta0W81Iw2ndASLnA/OXYn+ZOXMbW
# xKYA37d5EmQ+JWIhh3+Gnxjb3Tui6vVEJAgqkC+4FD/sB60VwuGNIKirkYT58402
# NlYExg0Wcgye8Qc50JXH96Dy6opvX84qGnnmz3slfKk7Jykifqh3jm1bSIQrngWs
# mUb8cXOkQgMrAWz8IJ4FgHisA0X3B3SklaiEO0ClPWw4nwC9PtpnAxZRxIVf2LDC
# eXj0fsJcP6So2b2vDnmfn2V+1bM8jQFuyv6eqhxW6sz4uiQQuZ3GAqdw0UhhfUmL
# ExzlCWTzdy2ZP4oN440JvxnYDItCsK263G+6l+LH3owWEbwHYmUh2uZoiC31rIEk
# pzXpZYzpFpGweTGtKx0+mW90i8l0lyQojN4pJMUrHgjp7u+bQIY0BkFUTClMH59E
# TsArErG8YOUh3cb+JkiTuJfgpv/D1kW//p3t2uJEsZPUHjN9BDsn0rsMftLYZI1C
# IKXpi69yYjbSmYAz6gRzi7AmlxRxqM4BEdOOyqHMylyyK5K0EneXqpA1UMT+Fuel
# 5KXXVWjPu+C0I5x4MLnbBckJQHVsKY/sUE94ba4OFsTMbCJeNZ8=
# =Vm2g
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 27 Jul 2023 02:37:57 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 2997d94b5dd0e8b10076f5e0b6f18410c73e28bd ]
When writing a task id to the "tasks" file in an rdtgroup,
rdtgroup_tasks_write() treats the pid as a number in the current pid
namespace. But when reading the "tasks" file, rdtgroup_tasks_show() shows
the list of global pids from the init namespace, which is confusing and
incorrect.
To be more robust, let the "tasks" file only show pids in the current pid
namespace.
Fixes: e02737d5b826 ("x86/intel_rdt: Add tasks files")
Signed-off-by: Shawn Wang <shawnwang@linux.alibaba.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lore.kernel.org/all/20230116071246.97717-1-shawnwang@linux.alibaba.com/
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e6b2fac36fcc0b73cbef063d700a9841850e37a0 ]
rdtgroup_tasks_assigned() and show_rdt_tasks() loop over threads testing
for a CTRL/MON group match by closid/rmid with the provided rdtgrp.
Further down the file are helpers to do this, move these further up and
make use of them here.
These helpers additionally check for alloc/mon capable. This is harmless
as rdtgroup_mkdir() tests these capable flags before allowing the config
directories to be created.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lkml.kernel.org/r/20200708163929.2783-7-james.morse@arm.com
Stable-dep-of: 2997d94b5dd0 ("x86/resctrl: Only show tasks' pid in current pid namespace")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
This is the 5.4.250 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmS+sKEACgkQONu9yGCS
# aT4QxQ//WnGWHnz/6K7Ra/u04z0FICXjMN2W0Lw7M6bqFspWbR7cJMncbF09ZGHr
# v9feeI1RczZxFkrsPQJ3tDgZbl8BjJyPZ6Yzhr0OZs4LRzlTkYllFE6+ZQdUOaZh
# /YqB04m9PS1ifRwbZyIzxlGkXhmPnmeG2V44D6ZvlhweM9tlLIKf5yCDQo3PYmcn
# bjlTBMPtpXQXykPUOT6XN+xlSDGQfaGy3B6SfapiEpxg6PDu9CAWzkL7yhbVoWnL
# xof2yld0yyyTVO9FtSCoO8XHqGTxrNIdTqrrcozPDX30z9Pi71h/QMR2ZUc420e3
# 52Z3PMcImoTOKppP3+kbeL7cjlGUIrlDb8rQz0birABZjPHIuIKNwFvF4cUH5s3L
# g9z5NOd1g9qPYvh0JqSazZt9UyhhPmWKQGExO9f8IkcsZ5bXqFFeol/5UgB9UX+f
# fytrgS0D6vP3WGIRbXDu2F+DYhS6dIO5n1NH2FKILQbK4j0Hm/9Xdz19UpaSLsXF
# Ldus2WIzmPgXpsKPdb9dGYu+m2mGHRD0oEpP2XjF+GEFbFxyCGTj3UGKVCrnOLAa
# UJkxuub9KeGRzudOw0NAZC2hqNvHsdSKcZDzZz/X40ZJCnXV9jw25OO2zsRMDayj
# 1o8VvaxlNgpLsLGjnqh7unt3bRnbl1Ck4E1duQ5pjXsGNNbaU7A=
# =rg5U
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Jul 2023 01:10:57 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
Upstream commit: 522b1d69219d8f083173819fde04f994aa051a98
Add a fix for the Zen2 VZEROUPPER data corruption bug where under
certain circumstances executing VZEROUPPER can cause register
corruption or leak data.
The optimal fix is through microcode but in the case the proper
microcode revision has not been applied, enable a fallback fix using
a chicken bit.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Upstream commit: 8b6f687743dacce83dbb0c7cfacf88bab00f808a
Avoid new and remove old forward declarations.
No functional changes.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a32b0f0db3f396f1c9be2fe621e77c09ec3d8e7d upstream.
Do the same as early loading - load on both threads.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230605141332.25948-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.244 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmR14ZEACgkQONu9yGCS
# aT41Mw/+NyTg/nNT37u5X7l6TeoWkJTTpxJTFM+EIL0L/LZ8d+fPwvXRuSEfUH8X
# 7yLBaepbuGdtyMMCmJofxlNwMrx9L9M1xK03s9DnKGxVlkFZbJth/8L2FD/R939z
# 7IP06/uYL/YI8ZjJSSEf6bOLqvy0BdqSLRpn9NKK9eChK0aIVQ03TIrS1NarAzuQ
# lMD5CwaFqZCz8NaGfdpg01JDfMuvKdCD8dCkYE+bO9U/nQRr1dmKvHNsQMpecDte
# F/YXfbcv3CIh7vwfdw8UOFzwhyZWjWHsSWi0wRK8ZGy1ckDr3lZFgYj+jr0K/CWu
# mMRiEXUIphqwCb7mdi5doWyLD9ZFyU8Jx249vqWBeuL4Hb+74vqJVf1wKT0wOE8c
# F6LyxXkc7lfNIIWojn4MyvxtIu4SPo/NsTd9Qxz7kj4SZHmAJNJihFIEezMUB8Wr
# 7VZP8o75PJ4Kx0aKkFY2IyZuC/GJa7VD+9AnCyB93eWfkufzMV/1fdOR3WEukpOg
# cqRl2xRcQiRu7I1jkn09Ir6yHjR5zZ12QHT/MNZiapaXmnG/IwHGopkQKUlM3Cwz
# rbAg7gLb89mjHbbFq8TO1W7JIelLuejAk/P8tO1Uf9VEa/c0E0I7Q434posf0/Yk
# XJdV2V+meOG6qyGkW35yUgentd5+bcSxyaA9D1IarA0EC11UFjU=
# =hQuZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 30 May 2023 07:44:17 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit edc0a2b5957652f4685ef3516f519f84807087db upstream.
Traditionally, all CPUs in a system have identical numbers of SMT
siblings. That changes with hybrid processors where some logical CPUs
have a sibling and others have none.
Today, the CPU boot code sets the global variable smp_num_siblings when
every CPU thread is brought up. The last thread to boot will overwrite
it with the number of siblings of *that* thread. That last thread to
boot will "win". If the thread is a Pcore, smp_num_siblings == 2. If it
is an Ecore, smp_num_siblings == 1.
smp_num_siblings describes if the *system* supports SMT. It should
specify the maximum number of SMT threads among all cores.
Ensure that smp_num_siblings represents the system-wide maximum number
of siblings by always increasing its value. Never allow it to decrease.
On MeteorLake-P platform, this fixes a problem that the Ecore CPUs are
not updated in any cpu sibling map because the system is treated as an
UP system when probing Ecore CPUs.
Below shows part of the CPU topology information before and after the
fix, for both Pcore and Ecore CPU (cpu0 is Pcore, cpu 12 is Ecore).
...
-/sys/devices/system/cpu/cpu0/topology/package_cpus:000fff
-/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-11
+/sys/devices/system/cpu/cpu0/topology/package_cpus:3fffff
+/sys/devices/system/cpu/cpu0/topology/package_cpus_list:0-21
...
-/sys/devices/system/cpu/cpu12/topology/package_cpus:001000
-/sys/devices/system/cpu/cpu12/topology/package_cpus_list:12
+/sys/devices/system/cpu/cpu12/topology/package_cpus:3fffff
+/sys/devices/system/cpu/cpu12/topology/package_cpus_list:0-21
Notice that the "before" 'package_cpus_list' has only one CPU. This
means that userspace tools like lscpu will see a little laptop like
an 11-socket system:
-Core(s) per socket: 1
-Socket(s): 11
+Core(s) per socket: 16
+Socket(s): 1
This is also expected to make the scheduler do rather wonky things
too.
[ dhansen: remove CPUID detail from changelog, add end user effects ]
CC: stable@kernel.org
Fixes: bbb65d2d365e ("x86: use cpuid vector 0xb when available for detecting cpu topology")
Fixes: 95f3d39ccf7a ("x86/cpu/topology: Provide detect_extended_topology_early()")
Suggested-by: Len Brown <len.brown@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/all/20230323015640.27906-1-rui.zhang%40intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is the 5.4.237 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQUF8AACgkQONu9yGCS
# aT7Ivg/9HDcZ73/ntBZYD5TCbUl8yEEFqaqhb6vBdzC/Uba8CJNgeM91ti0GB0x0
# Zue4GNrlP7NQzYV+E9pnTXxagAKxtQfZJc/kJmBbbpXgisJWJlgQ4aqtoRoXnCE1
# 1NwRVQlyVjmPG/AvU7p1jGUdw6Or/OEhMz+kN89XtUiAI2uCuPxM7W02zWxCZtQy
# EHonZ4nqhE6mQpAvYpwJ9x11hnAmnJNMOJQI+S/aL6M2geZ6lIblOG7+D8F4Vbz6
# nsNQ9LguJ89ffuZe7W3kXvLwqDBZingURxh4r70hNwcmDSNw0o3VpDfL+znUmixw
# g1TfuFR4zBp4vB9WOFQBlZs7XQUE+InQXm79CL62l5b01JgvoGxPBwguBsjyuBJI
# 9b/bWOcgRsDNKjLwhql3yj8SIN5a7csjofN5BqsZqihXSdoKc1mmHQHzf8NzS+HU
# 5juQGDtvFGqXj6L0N/PDTBH8cOhjqyao+1FPdIWlL1XNI0XekCVncakrx0HNxiPv
# YTXnETEIf13bfIjY88UcoigGTz/4rULO2G2ykwZQdP+F+r3U1BFHaxM9nd7aQaS6
# LoabYP/mlIoYUN/Kc0FI+Pp6052+IU70LFAm0urYqJ7RBvRolWn/arpK2PbXdVO4
# Z5D2fGuX/E5ZCBm4l5PSIQgfOEdRqQr9roIN0tfVjSQn6y+n3ww=
# =nqJu
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 17 Mar 2023 03:33:20 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 5.4.235 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIyBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQModwACgkQONu9yGCS
# aT7W7A/1EyhortcaMdZXEkdl7kZYupASsOm2QgOzeRkK0ELtbYRTt1qXdZgl40hU
# binrh5Yib2avHTEAF9I6AKVXMirSUTtODe/zQ7icyxVNcXeanlIbobEVBzSWIBtC
# Wxj129KZyCQlucagWihngQ9D+66bvD5JCsJ3EHKJjpheSqmZI88KVnOSnvyoJArj
# yLDY21UgxRN4KASgB+tpLBT4x0yN9zk8VuCGpyJjO/nHzhj6Y6DkOcx2q7hAxdn+
# H1OBCQ2QBCODCMrpW4xBuwy2blBZsRytUdEy8JsfxjgXvUp8+TdxUsuxb16a31jW
# pVo9LYB0cdKVoAzNJ2pTD8rhaATSbq+2MYDEUYCz8Rr+dZ/Nt2nTKSYeJprLsTwx
# TzPRNErQMKxKoQUQU/seWx47ebwt+Z8Rk4FAoyQMxRITw/9bBGLWpDKrGjNsByz9
# A2Q9UU+uM+jyqZnjQMvkzKSznggwfJ+SgaeqDMjwyyCQysJS8DTXPr9nA+IC9cht
# Kz00QetNgvPvZPE/gg81XOcKtJVTmA4AITQ0PlxYJT0hHCHx02GxvdPH2XBspgUt
# aNbDgVsupq8ONvRZlEf9hJKltTUmIRvI9JSOXnuhaN2jCv88SNv1M0TKfAo0XDNK
# Z/prv3qCnugMZ0KB0TD7d09XqSlKbefOq8TdtbXoTcC0NzFQkw==
# =29jZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 11 Mar 2023 10:44:28 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit b0563468eeac88ebc70559d52a0b66efc37e4e9d upstream.
AMD Erratum 1386 is summarised as:
XSAVES Instruction May Fail to Save XMM Registers to the Provided
State Save Area
This piece of accidental chronomancy causes the %xmm registers to
occasionally reset back to an older value.
Ignore the XSAVES feature on all AMD Zen1/2 hardware. The XSAVEC
instruction (which works fine) is equivalent on affected parts.
[ bp: Typos, move it into the F17h-specific function. ]
Reported-by: Tavis Ormandy <taviso@gmail.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230307174643.1240184-1-andrew.cooper3@citrix.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|