RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
Results from Linaro’s test farm.
We are booting the i386 kernel on an x86 machine. With Spectre V2 patches merged into Linux mainline we have been noticing RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible! Please find the detailed boot log in the below link [1] and [2].
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
metadata: git_ref: master git_repo: https://gitlab.com/Linaro/lkft/mirrors/torvalds/linux-mainline git_sha: 4a57a8400075bc5287c5c877702c68aeae2a033d git_describe: v5.19-rc6-115-g4a57a8400075 kernel_version: 5.19.0-rc6 kernel-config: https://builds.tuxbuild.com/2Bu6unA4pJ0TotIOQ6jcNKfhmew/config build-url: https://gitlab.com/Linaro/lkft/mirrors/torvalds/linux-mainline/-/pipelines/5... artifact-location: https://builds.tuxbuild.com/2Bu6unA4pJ0TotIOQ6jcNKfhmew toolchain: gcc-11
boot log: --------- [ 0.000000] Linux version 5.19.0-rc6 (tuxmake@tuxmake) (i686-linux-gnu-gcc (Debian 11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38) #1 SMP PREEMPT_DYNAMIC @1657744061 [ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
<trim>
[ 1.275957] LSM: Security Framework initializing [ 1.275957] SELinux: Initializing. [ 1.275957] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 1.275957] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 1.275957] CPU0: Thermal monitoring enabled (TM1) [ 1.275957] process: using mwait in idle threads [ 1.275957] Last level iTLB entries: 4KB 128, 2MB 8, 4MB 8 [ 1.275957] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4 [ 1.275957] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization [ 1.275957] Spectre V2 : Mitigation: Retpolines [ 1.275957] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch [ 1.275957] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible! [ 1.275957] RETBleed: Vulnerable [ 1.275957] Speculative Store Bypass: Vulnerable [ 1.275957] L1TF: Kernel not compiled for PAE. No mitigation for L1TF [ 1.275957] MDS: Vulnerable: Clear CPU buffers attempted, no microcode [ 1.275957] TAA: Vulnerable: Clear CPU buffers attempted, no microcode [ 1.275957] MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode [ 1.275957] SRBDS: Vulnerable: No microcode
Full test log link, [1] https://lkft.validation.linaro.org/scheduler/job/5282509#L490 [2] https://qa-reports.linaro.org/lkft/linux-mainline-master-sanity/build/v5.19-...
Best regards Naresh Kamboju
-- Linaro LKFT https://lkft.linaro.org
On Thu, Jul 14, 2022 at 02:15:07PM +0530, Naresh Kamboju wrote:
Results from Linaro’s test farm.
We are booting the i386 kernel on an x86 machine. With Spectre V2 patches merged into Linux mainline we have been noticing RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
That's funny. I don't think that's a valid combination that should be cared about, but I'll leave it to Pawan to comment if it is something that is "real" to be concerned for.
thanks,
greg k-h
On Thu, Jul 14, 2022 at 11:01:12AM +0200, Greg Kroah-Hartman wrote:
On Thu, Jul 14, 2022 at 02:15:07PM +0530, Naresh Kamboju wrote:
Results from Linaro’s test farm.
We are booting the i386 kernel on an x86 machine. With Spectre V2 patches merged into Linux mainline we have been noticing RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
That's funny. I don't think that's a valid combination that should be cared about, but I'll leave it to Pawan to comment if it is something that is "real" to be concerned for.
Yeah, so far nobody cared to fix 32bit. If someone *realllllly* cares and wants to put the effort in I suppose I'll review the patches, but seriously, you shouldn't be running 32bit kernels on Skylake / Zen based systems, that's just silly.
On Thu, Jul 14, 2022 at 11:01:12AM +0200, Greg Kroah-Hartman wrote:
On Thu, Jul 14, 2022 at 02:15:07PM +0530, Naresh Kamboju wrote:
Results from Linaro’s test farm.
We are booting the i386 kernel on an x86 machine. With Spectre V2 patches merged into Linux mainline we have been noticing RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
That's funny. I don't think that's a valid combination that should be cared about, but I'll leave it to Pawan to comment if it is something that is "real" to be concerned for.
Intel is not aware of production environments that use 32-bit mode on Skylake-gen CPUs. So this should not be a concern.
Thanks, Pawan
On Thu, Jul 14, 2022 at 11:01:12AM +0200, Greg Kroah-Hartman wrote:
On Thu, Jul 14, 2022 at 02:15:07PM +0530, Naresh Kamboju wrote:
We are booting the i386 kernel on an x86 machine. With Spectre V2 patches merged into Linux mainline we have been noticing RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
That's funny. I don't think that's a valid combination that should be cared about, but I'll leave it to Pawan to comment if it is something that is "real" to be concerned for.
Alas, some people still run that because of not knowing any better. Until not so long ago, they were proposed with two install media, "32-bit" and "64-bit", but no explanation. Upgrades keep working, crossgrades are still only for the brave of the heart, and reinstalling might not appear to have a reason compelling enough. And for quite some tasks, halved word size (thus ~2/3 memory usage) can overcome register starvation and win benchmarks.
Thus I wonder: perhaps such combinations we consider to be invalid should refuse to boot unless given a cmdline parameter?
Meow!
On Saturday 2022-07-23 23:50, Adam Borowski wrote:
We are booting the i386 kernel on an x86 machine.
[..] And for quite some tasks, halved word size (thus ~2/3 memory usage) can overcome register starvation and win benchmarks.
So how many benchmarks does a 32-bit userspace with a 32-bit kernel win over 32-bit userspace with a 64-bit kernel?
On Sun, Jul 24, 2022 at 11:25:04AM +0200, Jan Engelhardt wrote:
On Saturday 2022-07-23 23:50, Adam Borowski wrote:
We are booting the i386 kernel on an x86 machine.
[..] And for quite some tasks, halved word size (thus ~2/3 memory usage) can overcome register starvation and win benchmarks.
So how many benchmarks does a 32-bit userspace with a 32-bit kernel win over 32-bit userspace with a 64-bit kernel?
Likely none or almost none. What we want is for people to run 64-bit kernel, there are no real issues with userland.
Valid uses to run 32-bit kernel: * ancient hardware (so much more prevalent than m68k we support!; non-hobbyists should upgrade to reduce power costs) * hardware to run that 100$k-1M ISA industrial control/medical imaging card (which, having ISA, is necessarily ancient too) * us devs testing the above
Only the last case will have a modern CPU, thus requiring an explicit override won't hurt less educated users -- while telling the latter to grab a 64-bit kernel if their hardware isn't ancient would have other benefits for them beside just vulnerabilities.
Meow!
-
Adam Borowski -
Greg Kroah-Hartman -
Jan Engelhardt -
Naresh Kamboju -
Pawan Gupta -
Peter Zijlstra