RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Naresh Kamboju]

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/587353280
  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-rc6-115-g4a57a8400075/testrun/10817056/suite/log-parser-boot/tests/

Best regards
Naresh Kamboju

--
Linaro LKFT
https://lkft.linaro.org

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Greg Kroah-Hartman]

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

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Peter Zijlstra]

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.

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Pawan Gupta]

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

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Adam Borowski]

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!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"?  I think acid is
⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ?  Judging from the behaviour of
⠈⠳⣄⠀⠀⠀⠀ those "based and redpilled", something nasty.

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Jan Engelhardt]

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?

Re: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!

[Adam Borowski]

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!
-- 
⢀⣴⠾⠻⢶⣦⠀ Aryans: split from other Indo-Europeans ~2900-2000BC → Ural →
⣾⠁⢠⠒⠀⣿⡁     Bactria → settled 2000-1000BC in northwest India.
⢿⡄⠘⠷⠚⠋⠀ Gypsies: came ~1000AD from northern India; aryan.
⠈⠳⣄⠀⠀⠀⠀ Germans: IE people who came ~2800BC to Scandinavia; not aryan.