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 <[email protected]>
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
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!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ 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.
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!
--
⢀⣴⠾⠻⢶⣦⠀ 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.