Linux x86 32-bit Is Vulnerable To Retbleed But Don't Expect It To Get Fixed

[phoronix]

Phoronix: Linux x86 32-bit Is Vulnerable To Retbleed But Don't Expect It To Get Fixed

While relevant Intel and AMD processors have been mitigated for the recent Retbleed security vulnerability affecting older generations of processors, those mitigations currently just work for x86_64 kernels and will not work if running an x86 (32-bit) kernel on affected hardware. But it's unlikely to get fixed unless some passionate individual steps up as the upstream developers and vendors have long since moved on to just caring about x86_64...

https://www.phoronix.com/news/Linux-x86-Retbleed

[abu_shawarib]

Doesn't Intel still make 32 bit processors for embedded?

[AndyChow]

Doesn't Intel still make 32 bit processors for embedded?

I think you're talking about the Atom Elkhart Lake. They are 64 bit. But even if they were 32-bit, I doubt they have the special sauce required for this vulnerability.

[marlock]

At face value this seems like a simple enough decision, but a few questions come to mind...

Can this vulnerability affect 32bit kernels in VMs and on any sort of microsservice that has its own kernel?

If yes, can that be used to dig a hole into the host OS or into other VMs and microsservices on the same host machine?

VMs and microsservices are occasionally used to handle legacy applications, so it's likely to find a few that need to stay behing in 32bit-land... not to mention deploying a know-vulnerable guest on purpose to exploit a vulnerability (eg: on an agnostic cloud host that lets users do whatever they want as guests and where multiples guests are hosted on the same machine)

I'm confident that this has also been taken in consideration (and probably only the kernel running on bare metal matters), but those are things I'd feel more comfortable if seeing them explicitly addressed when communicating such decision.

[geearf]

Damn Michael, you finally updated the picture, I wasn't ready for the reminder that I've been here long enough, I'm getting quite old.

[NateHubbard]

I'm beginning to tire of the 32bit talk and the inevitable replies about how it should be supported.
It's been a couple of decades now. Maybe something like this will finally kill 32bit off.

[creative]

I would not expect them to fix it, I mean come on 32bit kernels, really? AMD came out with the 64bit CPU for a reason, shit needed to change.

[ferry]

There are some older x86_64 CPU's (Atom Silvermont, like Baytrail NUC, Edison, Cherrytrail tablets) around that might be faster running i686 code. The reason is that 64 bit instructions are longer and might have a "penalty" when executed. In most cases these computers have less then 4GB RAM. In the case of Edison, Intel did not even advertise 64 bit capabilities for Edison. i686 support for these systems should not be halted soon if you ask me.

Not sure if these Atom are affected by Retbleed though.

[DrYak]

VMs and microsservices are occasionally used to handle legacy applications, so it's likely to find a few that need to stay behing in 32bit-land...

Except that the kernel and the userland don't need to be on the same arch. Even on those installation, most of the time you'd be running a 64bit kernel to take advantage of the hardware and only use 32bits for the userland.

e.g.: That was a standard approach at some point once ARM embed systems shifted to Aarch64, as the 64bit kernel could leverage better memory management (and other goodies like more registers), but they could still run all the legacy 32bit proprietary blobs.

So your legacy 32bit application that you desperately need to run and can't recompile to 64bit for lack of available source is still likely to talk to a 64bit Linux kernel.

And in the modern age of LXC, Docker and other container, that 64bit kernel is likely the host kernel, with only the userland being separate.

I'm beginning to tire of the 32bit talk and the inevitable replies about how it should be supported.
It's been a couple of decades now.

Note that this time, the situation is different.

This isn't about somebody needing to run some old 32bits computer due to some legacy hardware and software (e.g.: some lab equipment whose data acquisition card is on an ISA bus and requires true ISA - can't even run on Pentium 4 with their somewhat ISA compatible PCI-to-ISA bridge that has only tested with a few popular sound cards).
This is about people purposefully buying the latest possible chips from Intel and AMD and then purposefully running ancient 32bit kernels (despite a modern 64bit one being also able to run legacy 32bit proprietary blobs) while this machine is plugged on the network. I don't think there are many machine running such configurations.

There are some older x86_64 CPU's (Atom Silvermont, like Baytrail NUC, Edison, Cherrytrail tablets) around that might be faster running i686 code. The reason is that 64 bit instructions are longer and might have a "penalty" when executed. In most cases these computers have less then 4GB RAM.

I was giving the exemple of ARM platform running Aarch64 kernel but keeping a 32bit userland for legacy (Raspberry Pi's introduction of 64bits in the 3 series and in some later 2), but embed intel boards are another example where only running the kernel on 64bits makes sense.

But regarding performance: on the other hand, x86_64 has double the registers which helps with performance. I'm not sure if real-world uses show that often a degraded performance when running 64bit code. Specially that only the pointers need to be extended to 64bit. The rest of the application can still use 32bit integers if that fits its use case better.

Not sure if these Atom are affected by Retbleed though.

Wait has Atom started to massively rely on out-of-order execution? I kind of understand that most of the advantage of Atom (low price, small size, low power) come from using much simpler design.

[ferry]

But regarding performance: on the other hand, x86_64 has double the registers which helps with performance. I'm not sure if real-world uses show that often a degraded performance when running 64bit code. Specially that only the pointers need to be extended to 64bit. The rest of the application can still use 32bit integers if that fits its use case better.

It's a mixed message. 64bit instructions are longer. I've tested crc32c which is like 2x slower on 64bit, while should have been 3x faster due to 64bit registers. But, base64 encoding using ssse3 is indeed faster on 64bits.